Various aspects of the operation of DNS have been repeatedly addressed by the author in a number of articles published as part of the blog. Moreover, the main emphasis has always been on improving the security of this key service for the entire Internet.

Until recently, despite the obviousness of the vulnerability of DNS traffic, which, for the most part, is still transmitted in the clear, for malicious actions by providers seeking to increase their income by embedding advertising in content, state law enforcement agencies and censorship, as well as just criminals, the process of enhancing its protection , despite the presence of various technologies, such as DNSSEC / DANE, DNScrypt, DNS-over-TLS and DNS-over-HTTPS, skidded. And if server solutions, and some of them have existed for quite some 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 announced plans to enable the default support mode for DNS-over-HTTPS (DoH) in the near future. This should help protect the DNS traffic of the WWW user from the aforementioned threats, but it can potentially cause new ones.

1. DNS-over-HTTPS Issues

At first glance, the beginning of the massive introduction of DNS-over-HTTPS in software running on the Internet causes only a positive reaction. However, the devil, as they say, is in the details.

The first problem that limits the scope of mass use of DoH is its focus solely on web traffic. Indeed, the HTTP protocol and its current version of 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 e-mail, all kinds of messengers, file transfer systems, multimedia streaming, etc. that do not use HTTP. Thus, despite the perception by many DoH as a panacea, it turns out to be inapplicable without additional (and unnecessary) efforts, for nothing other than browser technology. By the way, DNS-over-TLS looks like a much more worthy candidate for this role, which implements encapsulation of standard DNS traffic into a secure standard TLS protocol.

The second problem, which is potentially much more significant than the first, is the actual rejection of the inherent DNS by design decentralization for the sake of using the 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 prominent figures of the Internet, in particular Google. It turns out that the implementation of DNS-over-HTTPS in the form in which it is proposed now, only increases the dependence of end users on the largest services. It is no secret that the information that analysis of DNS queries can provide is able to 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 contributing to further centralization of the Internet means for ensuring the security of DNS traffic. Unfortunately, to expect the rapid introduction of mass support of DoH alternatives in client software for obvious reasons, it is not necessary and enthusiasts of safe technologies remain its destiny.

But since we are now getting DoH, why not use it after having gone away from potential surveillance by corporations through their servers to your own DNS-over-HTTPS server?

2. DNS-over-HTTPS

If you look at the RFC8484 standard describing the DNS-over-HTTPS protocol, you can see that it, in fact, is a web API that allows you to encapsulate a standard DNS packet into the HTTP / 2 protocol. This is implemented through special HTTP headers, as well as converting the binary format of the transmitted DNS data (see RFC1035 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 a secure TLS connection are supported.

A DNS query can be sent using standard GET and POST methods. In the first case, the request is transformed into a base64URL-encoded string, and in the second, through the body of the POST request in binary form. In this case, when querying and responding to DNS, a special MIME data type application / dns-message is used .

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 intact
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Also note the cache-control: header in the response from the web server. The max-age parameter contains the TTL value for the returned DNS record (or the minimum value if their set is returned).

Based on the foregoing, the functioning of the DoH server consists of several stages.

• Receive an HTTP request. If it is GET then decode the packet from base64URL encoding.
• Send this packet to the DNS server.
• Get a response from the DNS server
• Find the minimum TTL value in the received records.
• Return HTTP response to the client.

3. Own DNS-over-HTTPS server

The easiest, fastest and most effective way to start your own DNS-over-HTTPS server is to use the HTTP / 2 H2O web server, which the author already briefly wrote about (see " High-performance H2O web server ").

In favor of this choice is the fact that all the code of your own DoH server can be fully implemented using the mruby interpreter integrated into the H2O itself . In addition to standard libraries, to communicate with the DNS server, you need the Socket library (mrbgem), which, fortunately, is already included in the current development version of H2O 2.3.0-beta2 present in the FreeBSD ports. However, it is not difficult to add it to any previous version by cloning the Socket library repository into the / deps directory before compilation.

 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: max@kostikov.co 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-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 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.rb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

The exception is the URL / dns-query handler, for which our DNS-over-HTTPS server, written in mruby and called through the mruby.handler-file handler option, is responsible .

 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: max@kostikov.co 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 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Please note that the local caching server is responsible for processing DNS packets, in this case Unbound from the standard FreeBSD distribution. From a security point of view, this is the best solution. However, nothing prevents replacing localhost with the address of another DNS that 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 unbound-bugs@nlnetlabs.nl 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 tcpdump utility.

 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 kernel
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

The output shows how the request for resolving the example.com address 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 several about: config settings on the configuration pages.

Firstly, this is the address of our API at which the browser will query the DNS information in network.trr.uri . It is also recommended that you specify the domain IP from this URL for secure resolution in IP using the browser itself without accessing DNS in network.trr.bootstrapAddress . And, finally, the network.trr.mode parameter itself, which includes the use of DoH. Setting the value to "3" will force the browser to use exclusively DNS-over-HTTPS for name resolution, and the more reliable and secure "2" will give DoH priority, leaving the standard DNS access as a fallback.

5. PROFIT!

Was the article helpful? Then please do not be shy and support the money through the donation form (below).