This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DNS Encryption disappointment: DNS over TLS and DNS over HTTPS

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:

  1. The connection from the client device to the internal DNS server, and
  2. 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.
  • Douglas, thank you for sharing your thoughts.

    BR
    Alex

    -

  • Great article.  Protecting DNS is not the next security frontier.  It's a need today.  More functionality in the UTM might be too much to ask. 

    Rich Wenger,

    Point Broadband

  • Minor update

    With additional reading and additional testing, I have concluded that UTM is behaving in accordance with standards.

    Scenario 1:   

    An office PC forwards to Active Directory or UTM as its local DNS Server, but the DNS server does not have DNS SEC enabled.   
    In UTM, this means that the DNS SEC checkbox is off.   
    In Active Directory, this means that the DNS Server is not configured to download Trust Points.

    What happens if there is a DNS entry with a bad signature:

    • Client forwards request to local DNS server.
    • Local DNS sever forwards to any configured forwarders, such as 8.8.8.8 or 1.1.1.1 or 9.9.9.9.
    • Because of the signature error, all of these forwarders will return a ServFail error.
    • After all forwarders are exhausted, the local DNS server uses root-hints or cache to resolve the query without using the forwarders.
    • Since it is not configured to check signatures, it will accept any result that it obtains.

    The only way to ensure that the bad signature is detected will be to enable DNS SEC in the local DNS Server.   Remember that a DNS SEC signature only matters if the answer is non-authoritative.  If the query is resolved by the domain's name server, any answer is considered correct.    The DNS signature is only intended to detect errors that were introduced during DNS replication.

    Scenario 2:

    Assume a personal laptop floats between home and restaurants and hotels:

    • If the laptop is configured to always use 8.8 .8.8 or 9.9.9.9 or 1.1.1.1, a bad signature will cause the client to receive a ServFail eror, at which point the query will fail because the laptop has no other options.
    • If the laptop is configured to accept a DNS setting from DHCP, the results will depend on the recursive resolver that is currently in use.