[dev] suckless dns over http client

[Calvin Morrison]

In lieu of the recent 1.1.1.1 announcement, i was wondering if anyone
has written a suckless, simple, dns over http relay? Maybe it would be
a good thing to add to the wiki as potential ideas? The basic concept
of the tool would be to run as a daemon, listen on port 53 to
requests, and then make https requests and relay the information back
to the client.

Calvin.

[Quentin Rameau]

Post by Calvin Morrison
In lieu of the recent 1.1.1.1 announcement, i was wondering if anyone
has written a suckless, simple, dns over http relay?

haha ;)

[Laslo Hunhold]

On Mon, 2 Apr 2018 15:31:20 -0400
Calvin Morrison <***@gmail.com> wrote:

Hey Calvin,

Post by Calvin Morrison
In lieu of the recent 1.1.1.1 announcement, i was wondering if anyone
has written a suckless, simple, dns over http relay? Maybe it would be
a good thing to add to the wiki as potential ideas? The basic concept
of the tool would be to run as a daemon, listen on port 53 to
requests, and then make https requests and relay the information back
to the client.

implementing something like this would be really cool, however there is
one big blocker to this[0, Page 9]:

"The minimum version of HTTP used by DOH SHOULD be HTTP/2 [RFC7540]."

Given these circumstances, I see no elegant way to implement this in a
suckless way given HTTP/2 requires the server to do some pretty complex
connection-state-handling.

I have no idea why these guys were so keen to declare HTTP 1.1 dead so
fast.

With best regards

Laslo Hunhold

[0]:https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-04

[Calvin Morrison]

Post by Laslo Hunhold
Given these circumstances, I see no elegant way to implement this in a
suckless way given HTTP/2 requires the server to do some pretty complex
connection-state-handling.

curl kinda sucks, but, at least it's outside of our code base (see: surf, etc)

Calvin

[Calvin Morrison]

Presenting sdohd(1) - simple dns over https daemon [0]f

okay I wrote it see below. depends on curl, also i havent written C in
a long time so I didn't really have a good grasp on allocating stuff,
nor did i read the actual spec on dns so i hope bufsize = 256 is big
enough for any dns response, who knows, whatever, it kind of works.

It sucks, but I did something

https://github.com/mutantturkey/sdohd

Post by Calvin Morrison

Post by Laslo Hunhold
Given these circumstances, I see no elegant way to implement this in a
suckless way given HTTP/2 requires the server to do some pretty complex
connection-state-handling.

curl kinda sucks, but, at least it's outside of our code base (see: surf, etc)
Calvin

[Laslo Hunhold]

On Tue, 3 Apr 2018 00:12:01 -0400
Calvin Morrison <***@gmail.com> wrote:

Hey Calvin,

Post by Calvin Morrison
Presenting sdohd(1) - simple dns over https daemon [0]f
okay I wrote it see below. depends on curl, also i havent written C in
a long time so I didn't really have a good grasp on allocating stuff,
nor did i read the actual spec on dns so i hope bufsize = 256 is big
enough for any dns response, who knows, whatever, it kind of works.

I'm pretty sure DNS over HTTPS runs on top of a TCP stream and not a
UDP stream.

if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("cannot create socket\n");
return 0;
}

Taken from here[0].

With best regards

Laslo

[0]:https://github.com/mutantturkey/sdohd/blob/master/sdohd.c

[Calvin Morrison]

Post by Laslo Hunhold
On Tue, 3 Apr 2018 00:12:01 -0400
Hey Calvin,
I'm pretty sure DNS over HTTPS runs on top of a TCP stream and not a
UDP stream.

standard DNS requests are made via UDP on port 53. This tool relays
those requests over a regular https connection and responds on port
53.

If that makes sense

Calvin

[harry666t]

My take - if you don't mind Go...
https://github.com/rollcat/gdoh
No forking, no dependencies outside of stdlib, async
queries/responses, allows using multiple providers, 78 loc.

I'm pretty sure DNS over HTTPS runs on top of a TCP stream and not a UDP stream.

In Calvin's sdohd, it's curl doing all of the TCP+TLS+HTTPS heavy lifting.
The UDP socket accepts actual DNS requests from the local machine and
mangles them into DoH.

<3,K.

On Tue, 3 Apr 2018 00:12:01 -0400
Hey Calvin,

Post by Calvin Morrison
Presenting sdohd(1) - simple dns over https daemon [0]f
okay I wrote it see below. depends on curl, also i havent written C in
a long time so I didn't really have a good grasp on allocating stuff,
nor did i read the actual spec on dns so i hope bufsize = 256 is big
enough for any dns response, who knows, whatever, it kind of works.

I'm pretty sure DNS over HTTPS runs on top of a TCP stream and not a
UDP stream.
if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("cannot create socket\n");
return 0;
}
Taken from here[0].
With best regards
Laslo
[0]:https://github.com/mutantturkey/sdohd/blob/master/sdohd.c
--

[Martin Tournoij]

Post by harry666t
My take - if you don't mind Go...
https://github.com/rollcat/gdoh
No forking, no dependencies outside of stdlib, async
queries/responses, allows using multiple providers, 78 loc.

There is a small bug on line 34: if the statuscode isn't 200 then the
response body is never closed. You should move the "defer
r.Body.Close()" to above the "if r.StatusCode != 200 {" check.

Probably not a huge deal since this is a command line client, but in
long-running servers this will cause file descriptor leaks.

[harry666t]

Post by Martin Tournoij
There is a small bug on line 34: if the statuscode isn't 200 then the
response body is never closed.

Thanks Martin. Fixed.

Post by Martin Tournoij
Probably not a huge deal since this is a command line client, but in
long-running servers this will cause file descriptor leaks.

It is a huge deal. If I can't get a small program right, who would
ever trust me to write a big one correctly?

<3!K.

Post by Martin Tournoij

Post by harry666t
My take - if you don't mind Go...
https://github.com/rollcat/gdoh
No forking, no dependencies outside of stdlib, async
queries/responses, allows using multiple providers, 78 loc.

There is a small bug on line 34: if the statuscode isn't 200 then the
response body is never closed. You should move the "defer
r.Body.Close()" to above the "if r.StatusCode != 200 {" check.
Probably not a huge deal since this is a command line client, but in
long-running servers this will cause file descriptor leaks.

[Calvin Morrison]

Post by harry666t

Post by Martin Tournoij
There is a small bug on line 34: if the statuscode isn't 200 then the
response body is never closed.

Thanks Martin. Fixed.

Post by Martin Tournoij
Probably not a huge deal since this is a command line client, but in
long-running servers this will cause file descriptor leaks.

It is a huge deal. If I can't get a small program right, who would
ever trust me to write a big one correctly?

What was the motivation behind this line?

endpoint := c.Endpoints[rand.Int()%len(c.Endpoints)]

[harry666t]

Post by Calvin Morrison
What was the motivation behind this line?
endpoint := c.Endpoints[rand.Int()%len(c.Endpoints)]

Round-robin load-balancing. As it is, non-uniform, if the amount of
endpoints is not a power of 2, but hey, quick and dirty.

Also privacy, to an extent. If one day more public DNS providers offer
similar services, this would be a way of ensuring no single provider
sees all of your DNS traffic.

Post by Calvin Morrison

Post by harry666t

Post by Martin Tournoij
There is a small bug on line 34: if the statuscode isn't 200 then the
response body is never closed.

Thanks Martin. Fixed.

Post by Martin Tournoij
Probably not a huge deal since this is a command line client, but in
long-running servers this will cause file descriptor leaks.

It is a huge deal. If I can't get a small program right, who would
ever trust me to write a big one correctly?

What was the motivation behind this line?
endpoint := c.Endpoints[rand.Int()%len(c.Endpoints)]

[Laslo Hunhold]

On Tue, 3 Apr 2018 22:12:02 +0200
harry666t <***@gmail.com> wrote:

Hey Harry,

Post by harry666t
In Calvin's sdohd, it's curl doing all of the TCP+TLS+HTTPS heavy
lifting. The UDP socket accepts actual DNS requests from the local
machine and mangles them into DoH.

that's very interesting. Thanks for clearing that part up!

With best regards

Laslo Hunhold

[Calvin Morrison]

Post by harry666t
In Calvin's sdohd, it's curl doing all of the TCP+TLS+HTTPS heavy
lifting. The UDP socket accepts actual DNS requests from the local
machine and mangles them into DoH.

I am now thinking we might be able to work this thing entirely as a
script. socat provides a forking solution for incoming requests, now
all i need to do is write the script.

Calvin

[Joshua Haase]

Calvin Morrison (2018-04-02 15:31):

| In lieu of the recent 1.1.1.1 announcement, i was wondering if anyone
| has written a suckless, simple, dns over http relay? Maybe it would be
| a good thing to add to the wiki as potential ideas? The basic concept
| of the tool would be to run as a daemon, listen on port 53 to
| requests, and then make https requests and relay the information back
| to the client.

Isn't that what [axfrdns](https://cr.yp.to/djbdns/axfrdns.html ) from
djbdns is made for?

[harry666t]

Post by Joshua Haase
Isn't that what [axfrdns](https://cr.yp.to/djbdns/axfrdns.html ) from
djbdns is made for?

It's the "S" in "HTTPS". The whole point of the exercise is to have
end-to-end encryption and server authentication between you and the
DNS server. Otherwise it's dumb, it just adds overhead. If you trust
the path between yourself and your DNS server (e.g. because it's on
your home router), just use plain old DNS-over-UDP.

<3,K.