Various aspects of the operation of the DNS have already been repeatedly touched upon by the author in a number of posted on the blog. At the same time, the main emphasis has always been placed on improving the security of this key service for the entire Internet.
Until recently, despite the obvious vulnerability of DNS traffic, which, until now, for the most part, is transmitted in the clear, to malicious actions on the part of providers seeking to increase their revenues by embedding advertising in content, government enforcement agencies and censorship, as well as just criminals, the process , despite the presence of various technologies such as DNSSEC / DANE, DNScrypt, DNS-over-TLS and DNS-over-HTTPS, stalled. And if server solutions, and some of them have been around for quite a long time, are widely known and available, then their support from client software leaves much to be desired.
Fortunately, the situation is changing. In particular, the developers of the popular Firefox browser about plans to enable the mode support mode by default (DoH) coming soon. This should help protect the WWW user's DNS traffic from the aforementioned threats, but potentially introduce new ones.
1. DNS-over-HTTPS issues
At first glance, the beginning mass introduction of DNS-over-HTTPS in Internet software causes only a positive reaction. However, the devil, as they say, is in the details.
The first problem that limits the scope of the mass application of DoH is its focus exclusively on web traffic. Indeed, the HTTP protocol and its current version, HTTP/2, on which DoH is based, is the foundation of the WWW. But the Internet is not only the web. There are many popular services, such as email, all kinds of instant messengers, file transfer systems, multimedia streaming, etc., that do not use HTTP. Thus, despite the perception by many of DoH as a panacea, it turns out to be inapplicable without additional (and unnecessary) efforts, for anything other than browser technologies. By the way, DNS-over-TLS, which implements the encapsulation of standard DNS traffic into a secure standard TLS protocol, looks like a much more worthy candidate for this role.
The second problem, which is potentially much more significant than the first, is the actual rejection of decentralization inherent in DNS by design in favor of using a single DoH server specified in the browser settings. In particular, Mozilla offers to use the service from Cloudflare. A similar service was also launched by other notable figures on the Internet, in particular Google. It turns out that the introduction of DNS-over-HTTPS in the form in which it is currently proposed only increases the dependence of end users on the largest services. It is no secret that the information that DNS query analysis can provide can collect even more data about it, as well as increase their accuracy and relevance.
In this regard, the author was and remains a supporter of the mass introduction of not DNS-over-HTTPS, but DNS-over-TLS together with DNSSEC / DANE as a universal, secure and not conducive to further centralization of the Internet means to ensure the security of DNS traffic. Unfortunately, for obvious reasons, it is not necessary to expect a rapid introduction of mass support for DoH alternatives in client software, and enthusiasts of secure technologies remain its lot.
But, since we are now getting DoH, why not use it, having previously gone from potential surveillance by corporations through their servers to our own DNS-over-HTTPS server?
2. DNS-over-HTTPS protocol
Looking at the standard describing the DNS-over-HTTPS protocol, you can see that it is, in fact, a web API that allows you to encapsulate a standard DNS packet in the HTTP / 2 protocol. This is implemented through special HTTP headers, as well as binary format conversion of transmitted DNS data (see below). and subsequent documents) into a form that allows you to send and receive them, as well as work with the necessary metadata.
By standard, only HTTP/2 and secure TLS connections are supported.
Sending a DNS query can be done using the standard GET and POST methods. In the first case, the request is transformed into a base64URL-encoded string, and in the second case, through the POST request body in binary form. In this case, a special MIME data type is used when requesting and responding to DNS application/dns-message.
root@eprove:~ # curl -H 'accept: application/dns-message' 'https://my.domaint/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE' -v
* Trying 2001:100:200:300::400:443...
* TCP_NODELAY set
* Connected to eprove.net (2001:100:200:300::400) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=my.domain
* start date: Jul 22 00:07:13 2019 GMT
* expire date: Oct 20 00:07:13 2019 GMT
* subjectAltName: host "my.domain" matched cert's "my.domain"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x801441000)
> GET /dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE HTTP/2
> Host: eprove.net
> User-Agent: curl/7.65.3
> accept: application/dns-message
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< server: h2o/2.3.0-beta2
< content-type: application/dns-message
< cache-control: max-age=86274
< date: Thu, 12 Sep 2019 13:07:25 GMT
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< content-length: 45
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 45)
* stopped the pause stream!
* Connection #0 to host eprove.net left intactAlso note the title cache control: in response from the web server. In parameter Max-age contains the TTL value for the returned DNS record (or the minimum value if a set of them is returned).
Based on the foregoing, the functioning of the DoH server consists of several stages.
- Get an HTTP request. If it is GET then decode the packet from the base64URL encoding.
- Send this packet to the DNS server.
- Get response from DNS server
- Find the minimum TTL value in the received records.
- Return an HTTP response to the client.
3. Own DNS-over-HTTPS server
The easiest, fastest, and most efficient way to run your own DNS-over-HTTPS server is to use an HTTP/2 web server. , about which the author has already briefly written (see β").
This choice is supported by the fact that all the code of the server's own DoH can be fully implemented by means of an interpreter integrated into the H2O itself. . In addition to the standard libraries, the (mrbgem) Socket library is required to communicate with the DNS server, which, fortunately, is already included in the current developer version of H2O 2.3.0-beta2 in FreeBSD ports. However, it is not difficult to add it to any previous version by cloning the repository to catalog /deps before compiling.
root@beta:~ # uname -v
FreeBSD 12.0-RELEASE-p10 GENERIC
root@beta:~ # cd /usr/ports/www/h2o
root@beta:/usr/ports/www/h2o # make extract
===> License MIT BSD2CLAUSE accepted by the user
===> h2o-2.2.6 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by h2o-2.2.6 for building
===> Extracting for h2o-2.2.6.
=> SHA256 Checksum OK for h2o-h2o-v2.2.6_GH0.tar.gz.
===> h2o-2.2.6 depends on file: /usr/local/bin/ruby26 - found
root@beta:/usr/ports/www/h2o # cd work/h2o-2.2.6/deps/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # git clone https://github.com/iij/mruby-socket.git
ΠΠ»ΠΎΠ½ΠΈΡΠΎΠ²Π°Π½ΠΈΠ΅ Π² Β«mruby-socketΒ»β¦
remote: Enumerating objects: 385, done.
remote: Total 385 (delta 0), reused 0 (delta 0), pack-reused 385
ΠΠΎΠ»ΡΡΠ΅Π½ΠΈΠ΅ ΠΎΠ±ΡΠ΅ΠΊΡΠΎΠ²: 100% (385/385), 98.02 KiB | 647.00 KiB/s, Π³ΠΎΡΠΎΠ²ΠΎ.
ΠΠΏΡΠ΅Π΄Π΅Π»Π΅Π½ΠΈΠ΅ ΠΈΠ·ΠΌΠ΅Π½Π΅Π½ΠΈΠΉ: 100% (208/208), Π³ΠΎΡΠΎΠ²ΠΎ.
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # ll
total 181
drwxr-xr-x 9 root wheel 18 12 Π°Π²Π³. 16:09 brotli/
drwxr-xr-x 2 root wheel 4 12 Π°Π²Π³. 16:09 cloexec/
drwxr-xr-x 2 root wheel 5 12 Π°Π²Π³. 16:09 golombset/
drwxr-xr-x 4 root wheel 35 12 Π°Π²Π³. 16:09 klib/
drwxr-xr-x 2 root wheel 5 12 Π°Π²Π³. 16:09 libgkc/
drwxr-xr-x 4 root wheel 26 12 Π°Π²Π³. 16:09 libyrmcds/
drwxr-xr-x 13 root wheel 32 12 Π°Π²Π³. 16:09 mruby/
drwxr-xr-x 5 root wheel 11 12 Π°Π²Π³. 16:09 mruby-digest/
drwxr-xr-x 5 root wheel 10 12 Π°Π²Π³. 16:09 mruby-dir/
drwxr-xr-x 5 root wheel 10 12 Π°Π²Π³. 16:09 mruby-env/
drwxr-xr-x 4 root wheel 9 12 Π°Π²Π³. 16:09 mruby-errno/
drwxr-xr-x 5 root wheel 14 12 Π°Π²Π³. 16:09 mruby-file-stat/
drwxr-xr-x 5 root wheel 10 12 Π°Π²Π³. 16:09 mruby-iijson/
drwxr-xr-x 5 root wheel 11 12 Π°Π²Π³. 16:09 mruby-input-stream/
drwxr-xr-x 6 root wheel 11 12 Π°Π²Π³. 16:09 mruby-io/
drwxr-xr-x 5 root wheel 10 12 Π°Π²Π³. 16:09 mruby-onig-regexp/
drwxr-xr-x 4 root wheel 10 12 Π°Π²Π³. 16:09 mruby-pack/
drwxr-xr-x 5 root wheel 10 12 Π°Π²Π³. 16:09 mruby-require/
drwxr-xr-x 6 root wheel 10 12 ΡΠ΅Π½Ρ. 16:10 mruby-socket/
drwxr-xr-x 2 root wheel 9 12 Π°Π²Π³. 16:09 neverbleed/
drwxr-xr-x 2 root wheel 13 12 Π°Π²Π³. 16:09 picohttpparser/
drwxr-xr-x 2 root wheel 4 12 Π°Π²Π³. 16:09 picotest/
drwxr-xr-x 9 root wheel 16 12 Π°Π²Π³. 16:09 picotls/
drwxr-xr-x 4 root wheel 8 12 Π°Π²Π³. 16:09 ssl-conservatory/
drwxr-xr-x 8 root wheel 18 12 Π°Π²Π³. 16:09 yaml/
drwxr-xr-x 2 root wheel 8 12 Π°Π²Π³. 16:09 yoml/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # cd ../../..
root@beta:/usr/ports/www/h2o # make install clean
...The web server configuration is generally standard.
root@beta:/usr/ports/www/h2o # cd /usr/local/etc/h2o/
root@beta:/usr/local/etc/h2o # cat h2o.conf
# this sample config gives you a feel for how h2o can be used
# and a high-security configuration for TLS and HTTP headers
# see https://h2o.examp1e.net/ for detailed documentation
# and h2o --help for command-line options and settings
# v.20180207 (c)2018 by Max Kostikov http://kostikov.co e-mail: [email protected]
user: www
pid-file: /var/run/h2o.pid
access-log:
path: /var/log/h2o/h2o-access.log
format: "%h %v %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i""
error-log: /var/log/h2o/h2o-error.log
expires: off
compress: on
file.dirlisting: off
file.send-compressed: on
file.index: [ 'index.html', 'index.php' ]
listen:
port: 80
listen:
port: 443
ssl:
cipher-suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
cipher-preference: server
dh-file: /etc/ssl/dhparams.pem
certificate-file: /usr/local/etc/letsencrypt/live/eprove.net/fullchain.pem
key-file: /usr/local/etc/letsencrypt/live/my.domain/privkey.pem
hosts:
"*.my.domain":
paths: &go_tls
"/":
redirect:
status: 301
url: https://my.domain/
"my.domain:80":
paths: *go_tls
"my.domain:443":
header.add: "Strict-Transport-Security: max-age=15768000; includeSubDomains; preload"
paths:
"/dns-query":
mruby.handler-file: /usr/local/etc/h2o/h2odoh.rbThe only exception is the URL handler /dns-query for which, in fact, our DNS-over-HTTPS server is responsible, written in mruby and called through the handler option mruby.handler-file.
root@beta:/usr/local/etc/h2o # cat h2odoh.rb
# H2O HTTP/2 web server as DNS-over-HTTP service
# v.20190908 (c)2018-2019 Max Kostikov https://kostikov.co e-mail: [email protected]
proc {|env|
if env['HTTP_ACCEPT'] == "application/dns-message"
case env['REQUEST_METHOD']
when "GET"
req = env['QUERY_STRING'].gsub(/^dns=/,'')
# base64URL decode
req = req.tr("-_", "+/")
if !req.end_with?("=") && req.length % 4 != 0
req = req.ljust((req.length + 3) & ~3, "=")
end
req = req.unpack1("m")
when "POST"
req = env['rack.input'].read
else
req = ""
end
if req.empty?
[400, { 'content-type' => 'text/plain' }, [ "Bad Request" ]]
else
# --- ask DNS server
sock = UDPSocket.new
sock.connect("localhost", 53)
sock.send(req, 0)
str = sock.recv(4096)
sock.close
# --- find lowest TTL in response
nans = str[6, 2].unpack1('n') # number of answers
if nans > 0 # no DNS failure
shift = 12
ttl = 0
while nans > 0
# process domain name compression
if str[shift].unpack1("C") < 192
shift = str.index("x00", shift) + 5
if ttl == 0 # skip question section
next
end
end
shift += 6
curttl = str[shift, 4].unpack1('N')
shift += str[shift + 4, 2].unpack1('n') + 6 # responce data size
if ttl == 0 or ttl > curttl
ttl = curttl
end
nans -= 1
end
cc = 'max-age=' + ttl.to_s
else
cc = 'no-cache'
end
[200, { 'content-type' => 'application/dns-message', 'content-length' => str.size, 'cache-control' => cc }, [ str ] ]
end
else
[415, { 'content-type' => 'text/plain' }, [ "Unsupported Media Type" ]]
end
}Note that the local caching server is responsible for processing DNS packets, in this case from the standard FreeBSD distribution. From a security point of view, this is the best solution. However, nothing prevents the replacement localhost to the address of the other DNS you intend to use.
root@beta:/usr/local/etc/h2o # local-unbound verison
usage: local-unbound [options]
start unbound daemon DNS resolver.
-h this help
-c file config file to read instead of /var/unbound/unbound.conf
file format is described in unbound.conf(5).
-d do not fork into the background.
-p do not create a pidfile.
-v verbose (more times to increase verbosity)
Version 1.8.1
linked libs: mini-event internal (it uses select), OpenSSL 1.1.1a-freebsd 20 Nov 2018
linked modules: dns64 respip validator iterator
BSD licensed, see LICENSE in source package for details.
Report bugs to [email protected]
root@eprove:/usr/local/etc/h2o # sockstat -46 | grep unbound
unbound local-unbo 69749 3 udp6 ::1:53 *:*
unbound local-unbo 69749 4 tcp6 ::1:53 *:*
unbound local-unbo 69749 5 udp4 127.0.0.1:53 *:*
unbound local-unbo 69749 6 tcp4 127.0.0.1:53 *:*It remains to restart H2O and see what came of it.
root@beta:/usr/local/etc/h2o # service h2o restart
Stopping h2o.
Waiting for PIDS: 69871.
Starting h2o.
start_server (pid:70532) starting now...4. Testing
So, let's check the results by sending a test request again and looking at the network traffic using the utility Tcpdump.
root@beta/usr/local/etc/h2o # curl -H 'accept: application/dns-message' 'https://my.domain/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE'
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
...
root@beta:~ # tcpdump -n -i lo0 udp port 53 -xx -XX -vv
tcpdump: listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes
16:32:40.420831 IP (tos 0x0, ttl 64, id 37575, offset 0, flags [none], proto UDP (17), length 57, bad cksum 0 (->e9ea)!)
127.0.0.1.21070 > 127.0.0.1.53: [bad udp cksum 0xfe38 -> 0x33e3!] 43981+ A? example.com. (29)
0x0000: 0200 0000 4500 0039 92c7 0000 4011 0000 ....E..9....@...
0x0010: 7f00 0001 7f00 0001 524e 0035 0025 fe38 ........RN.5.%.8
0x0020: abcd 0100 0001 0000 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01 mple.com.....
16:32:40.796507 IP (tos 0x0, ttl 64, id 37590, offset 0, flags [none], proto UDP (17), length 73, bad cksum 0 (->e9cb)!)
127.0.0.1.53 > 127.0.0.1.21070: [bad udp cksum 0xfe48 -> 0x43fa!] 43981 q: A? example.com. 1/0/0 example.com. A 93.184.216.34 (45)
0x0000: 0200 0000 4500 0049 92d6 0000 4011 0000 ....E..I....@...
0x0010: 7f00 0001 7f00 0001 0035 524e 0035 fe48 .........5RN.5.H
0x0020: abcd 8180 0001 0001 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01c0 0c00 mple.com........
0x0040: 0100 0100 0151 8000 045d b8d8 22 .....Q...].."
^C
2 packets captured
23 packets received by filter
0 packets dropped by kernelThe output shows how the address resolution request example.com was received and successfully processed by the DNS server.
Now it remains to activate our server in the Firefox browser. To do this, you need to change a few settings on the configuration pages about: config.
Firstly, this is the address of our API by which the browser will query the DNS for information in network.trr.uri. It is also recommended to specify the domain IP from this URL for secure resolution to IP using the browser itself without recourse to DNS in network.trr.bootstrapAddress. And finally, the parameter itself network.trr.mode including the use of DoH. Setting the value to "3" will force the browser to use DNS-over-HTTPS exclusively for name resolution, while the more reliable and secure "2" will give priority to DoH, leaving the standard DNS lookup as a fallback.
5. PROFIT!
Was the article helpful? Then please do not be shy and support with money through the donation form (below).
Source: habr.com