Fortunately, DNS integrity problems seem to be rare, but as Network Security administrators, we are not paid to assume that the Internet is a nice place filled with nice people.
This Mozilla link is a great explanation of why DNS encryption is important.
https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/
In short, when traffic is not encrypted, you have no assurance that your reply arrived at your intended server, or that the reply you received actually came from that server.
In the typical network environment, client devices obtain an IP address and a DNS configuration from a DHCP server. The client device is typically a DNS "stub resolver", meaning that it will ask an adjacent "recursive resolver" to do whatever is needed to obtain a complete answer to any DNS query. In the home environment, the DNS server, the DHCP server, and the Firewall are likely to be the same box.
Given this environment, there are two types of connections to consider:
- The connection from the client device to the internal DNS server, and
- The connection from the internal DNS server to various DNS servers on the Internet.
I am relatively less concerned about connections that are internal to my network, but I was eager to encrypt the Internet-bound connections, so I began trying to determine how to do so.
I focused on DNS-over-TLS, because as network administrator, I have no need to hide my DNS traffic from myself. Besides there was an RFC already published: https://tools.ietf.org/html/rfc7766
Reading it was a disappointment. Their scope is specifically limited to the first connection, from stub resolver to recursive resolver. I looked for software solutions, and found that they all involved installing a gateway module to act like a DNS server, then the gateway module creates the TLS or HTTPS session to ship the DNS request to a matching gateway device on the other end. None of the solutions that I found could be called well integrated, and none would support the needs of a recursive resolver to access multiple other servers.
Then I checked to see if TCP/853 could be used on the Internet:
- Root servers: TCP/853 closed
- Cloudflare: TCP/853 closed
- Quad9: TCP/853 open
- Google: TCP/853 open
- Neustar DNS: TCP/853 closed
So there are a few resources available, but not a complete set.
There are also certificate verification issues with TLS to the Internet -- how do you know the correct certificate name of your intended server if all that DHCP gave you was an IP address? RFC 7766 assumes the use of HPKP to pin a particular certificate key, rather than the normal method of matching the received name to the expected name, but this does not extrapolate well to the Internet.
I can believe that TLS support on a root server would be difficult to implement with acceptable performance, so maybe it was unrealistic to imagine a near-term state where all DNS traffic could be encrypted.
DNS over TLS is a bust for the use where it is most needed, and where I had hoped UTM would provide a turnkey solution.
DNS over HTTPS is no better. It is intended for client devices that have no need to communicate with their internal network, and also want to bypass their DHCP-assigned server, using Google or Quad9 instead as their recursive resolver. UTM might be useful for a network administrator to block that traffic, but it has no role in helping such connections happen.
Bummed out, but that's the way it seems to be.
This thread was automatically locked due to age.
