Home

Podfeet Podcasts

Chit Chat Across the Pond Lite logo Two interlocking ribbons, one red, one blue. The word Lite is across the logo in a playful font. The podfeet (two little bare feet) are in the upper right. The background is dark blue with Chat and Chat in the upper left and lower right corners with "across the pond" in thin letter across the bottom. Sounds more confusing than it is!

CCATP #606 — Bart Busschots on DoH and DoT

  • by podfeet

    • CCATP #606 for August 31, 2019, and I’m your host, Allison Sheridan. This week our guest is Bart Busschots with a non-Programming By Stealth episode of Chit Chat Across the Pond.

    In this “Lite” version of Chit Chat Across the Pond, Bart answered Scott Fairclough’s request to explain DoH and DoT. It’s super nerdy and really interesting. First Bart gives us a full refresher on exactly what DNS is (and I needed that refresher.) Then he explains the problems with DNS from a security and privacy point of view. Then he walks us through how DoH, aka DNS over TLS and DoH, aka DNS over https (which is actually http over TLS) will start protecting us in the future (and in some cases the present.)

    mp3 download

    Listener Scott Fairclough AKA @scottf2016 tweeted @bbusschots https://twitter.com/scottf2016/status/1153388851274092545:

    Hi Bart, any chance you can talk about DoH (DNS over http) and DoT (DNS over TLS), I know Firefox has added DoH and my ASUS router (using Merlin custom firmware) now supports DoT, but I’d love to hear your take on it all please, may[be] on Security Bits?

    Quick DNS Refresher

    • DNS is the Domain Name System (more info — en.wikipedia.org/…)
    • DNS translates between human-friendly domain names like www.podfeet.com and information needed by computers:
      • A Records map domain names to IPv4 addresses
      • AAAA (pronounced quad A) Records map domain names to IPv6 addresses
      • MX Records (for Mail Exchanger) map domain names to email server domain names
      • CNAME records map domain names to domain names to produce aliases
      • PTR Records (often referred to as reverse DNS records) map IPv4 and IPv6 addresses to domain names
      • TXT Records map domain names to arbitrary text strings — often used for security checks when registering TLS/SSL certs and to publish policies for spam-prevention protocols like SPF and DKIM.
      • And much more …
    • Without DNS the internet simply would not function!
    • Domain names are hierarchical (from right to left).
      • The Root DNS Servers are vital internet infrastructure that act as the entry point for the entire DNS system.
      • The Root DNS Servers delegate authority to Authoritative DNS Servers for each top-level domain (TLD) like .com, .ie etc..
      • The Authoritative DNS Servers for each TLD delegate authority to Authoritative DNS Servers for each registered domain under that TLD, e.g. the .com servers delegate authority to servers under Allison’s control for podfeet.com and the .ie servers delegate authority to servers I control for barb.ie.
      • The owners of registered domains can then choose to delegate authority to yet more Authoritative DNS Servers for sub-domains under their domain, e.g. I could delegate control of can.bartb.ie to a CDN provider like CloudFlare.
    • DNS Clients send DNS Queries to DNS Resolvers to query Authoritative DNS Servers for DNS Records.
      • DNS Clients are software like apps or OSes.
      • DNS Resolvers (often referred to as DNS Servers) do the work of finding answers to DNS queries by starting at the root DNS servers and working their way down through the domain hierarchies until they reach an authoritative server that can give an authoritative answer to the query. An authoritative answer
        • DNS Stub Resolvers AKA DNS Forwarders (also often referred to as DNS Servers) are resolvers that accept queries from clients and then forward them on to another resolver rather than resolving the query themselves. The resolvers in most of our OSes and most home routers are actually stub resolvers.
      • Authoritative DNS servers (totally different to Resolvers but also often referred to as DNS Servers) host records on behalf of domain owners, and can authoritatively say that a given sub-domain over which they have authority does not exist.
      • For example, when I type www.podfeet.com into Safari on my Mac, this is what really happens:
        • Safari constructs a DNS query requesting an A record for the domain www.podfeet.com and hands it to macOS which is a stub resolver.
        • macOS forwards the query to the DNS resolver it is configured to use (via DHCP) which happens to be my home router.
        • My router is also a stub resolver, so it forwards the query to the resolver it has been configured to use, which is 1.1.1.1
        • The resolver at 1.1.1.1 then does the hard work of finding an answer to Safari’s query.
          • The resolver starts by sending the query to one of the root servers.
          • The root server will reply with a delegation response telling the resolver it needs to ask one of the authoritative servers for the .com TLD the root servers which reply that they don’t know the answer, but that you should ask the authoritative servers for the .com TLD by replying with a delegation response listing their IPs.
      • Note that in reality, all resolvers, including stub resolvers, can cache DNS responses, so in reality the resolution process is often short-circuited.
        • In the above example:
        • If I had already been to www.podfeet.com recently macOS would answer Safari from its cache and never even ask my router.
        • If I had not recently visited www.podfeet.com on my Mac, but I had on my iPhone while it was on m home network then macOS would have passed the query to my router, but it would have the answer cached from when my phone asked, so it could reply to macOS without the need to forward anything to 1.1.1.1
        • If no one in my house had recently visited www.podfeet.com then my router would have passed the query on to 1.1.1.1. If anyone else using 1.1.1.1 had recently visited www.podfeet.com then it would have the answer cached and could reply without having to do the hard work of resolving the answer.
    • DNS is an old protocol (first spect published in 1983), so it was designed in a much more innocent world where the concept of malicious internet users just didn’t occur to anyone!
    • DNS use plain-text UDP packets

    What’s Wrong With DNS?

    • Because DNS uses UDP rather than TCP (for efficiency reasons), the source address of any packet can be spoofed (there’s no way to tell if a packet that claims to have come from 1.1.1.1 really did come from 1.1.1.1 and not the person next to you in the coffee shop!).
    • Because the DNS protocol is plain-text, every query and every response is visible to every device it passes through. This means your ISP sees the contents of all your DNS queries, as can anyone who shares your Wifi/LAN. It also means that if you are in a country where all internet traffic is routed through government owned or controlled routers can do the same.
    • Because the DNS protocol does not implement any kind of message authentication, there is no way to tell whether or not the contents of a DNS packet was altered in transit. I.e., there’s no way to know that an answer that really did come from 1.1.1.1 still contains the same information it did when they sent it!
    • Formally, DNS is missing:
      • Authenticity (verification of the source)
      • Integrity (what was sent is what arrived)
      • Confidentiality (privacy)

    Solving the Authenticity & Integrity Problems (DNSSEC)

    • Authenticity and integrity are closely related, and they were treated as a single problem to be solved by the industry.
    • A number of possible solutions were explored, but in the end, DNSSEC (more info — en.wikipedia.org/…) was the winner and is in the process of being (slowly) implemented.
    • DNSSEC uses a public & private keys to digitally sign the DNS responses from authoritative DNS servers.
      • Authoritative DNS Servers that support DNSSEC publish their public keys and digitally sign all their records.
      • DNS Clients that support DNSSEC validate the signatures before accepting any signed DNS response as valid.
    • Assuming both the authoritative server and the client support DNSSEC, DNS responses will be authentic and have integrity — i.e. provably from an authorised authoritative server, and un-altered in transit.
    • DNSSEC provides no confidentiality.

    Solving the Confidentiality Problem (DoH & Friends)

    • Historically, the internet had many insecure protocols, and they have been brought into the future by simply wrapping them in a layer of encryption, often using TLS/SSL (more info — en.wikipedia.org/…), e.g.:
      • HTTPS is just HTTP wrapped with TLS/SSL
      • FTPS is just FTP over TLS/SSL (SFTP is a new protocol and transfers files over SSH)
      • Secure IMAP is just IMAP wrapped with TLS/SSL
      • Secure POP is just POP wrapped with TLS/SSL
    • As things stand there’s no clear winner when it comes to providing DNS privacy. I.e. there is no de facto standard for privacy like DNSSEC has become for providing authenticity and integrity.
    • There are two front-runners, and since they’re both optimised for different scenarios, they may well emerge and joint-de-facto standards:
    • Taking that same idea, two approaches for DNS security are gaining traction:
      • DNS over TLS, or DoT (more info — en.wikipedia.org/…)
      • DNS over HTTPS, or DoH (more info — en.wikipedia.org/…)
        • DoH is optimised for use by browsers. The idea is that the browser would always keep an open HTTPS connection to a DoH server and send all its DNS queries through that one connection. This is both secure and efficient. Browsers use HTTPS all the time, so they have a well tested and optimised HTTPS implementation already.
    • Both DoT & DoH are close to breaking through, but have not quite done so yet — unless you consider yourself a hobbyist or unless it’s your job to experiment with up-coming technologies, it’s too early to start using either of these. That could very well change within the next year though!

    DNS over TLS (DoT)

    • Simply wraps DNS queries with TLS/SSL.
    • Well suited to use by DNS resolvers.
    • Now appearing as a feature on more modern/advanced home router firmwares.
    • Supported in the Linux OS, so Linux computer can be directly configured to use DoT for all DNS queries made via the OS.
    • Supported by many commonly used DNS Resolver implementations. The Open-source stunnel project provides a DNS proxy that can be used to add DoT support to just about any DNS resolver.
    • Supported by many public DNS resolvers, including big names like:
      • Cloud Flare (1.1.1.1)
      • Google (8.8.8.8)
      • Quad9 (9.9.9.9)

    DNS over HTTPS (DoH)

    • Optimised for use by web browsers (HTTPS is core functionality for browsers, so they have robust and well optimised implementations).
    • Web browsers would maintain an HTTPS connection to a DoH server and send all DNS queries through that connection, removing the over-head of making a new connection for every query.
    • Supported, or soon-to-be-supported in the following browsers:
      • FireFox — Supported (can be enabled in settings)
      • Chrome — Soon-to-be Supported (can be enabled via a CLI command ATM, but not yet via the GUI)
      • (Neither Safari nor Edge seem to have support now, and I could find no evidence that it’s in the works for either)
    • Supported by many public DNS resolvers, including big names like:
      • Cloud Flare (1.1.1.1)
      • Google (8.8.8.8)
      • Quad9 (9.9.9.9)
    • Cloud Flare have released and open-source DNS proxy (stub resolver) that runs on Windows, Linux & Mac — developers.cloudflare.com/…

    Experimenting with DoT (DNS over TLS)

    To experiment with DoT you’ll need two things:

    1. Access to a DNS resolver that supports DoT.
    2. A stub resolver that can be configured to forward queries over DoT.

    Possible Scenarios:

    1. Install a stub resolver that supports DoT on your computer and configure your computer to use that stub resolver for all DNS queries made by your computer’s OS.
      • Your stub resolver will listen on some port on 127.0.0.1 (localhost), so configure your DNS Server in your network settings to point to that port on 127.0.0.1.
      • This will protect all DNS queries made through your OS (note that apps are free to make their own DNS queries without using the OS, so any such apps won’t be affected, but those are few and far between)
    2. If your home router supports it, configure it to act as a stub resolver for your LAN, and forward all queries to a DoT-supporting resolver over DoT
      • Configure the DNS Server setting in your router to point to the DoT-supporting resolver and to use DoT.
      • Configure your router to advertise itself as the LAN’s DNS server via DHCP (most probably the default)
      • This will protect all DNS queries from all apps that use the OS for DNS queries on all devices that take their DNS settings from DHCP (in reality this probably means every DNS request from every device on your LAN)

    Experimenting with DoH (DNS over HTTPS)

    To experiment with DoH you’ll need two things:

    1. Access to a DNS resolver that supports DoH.
    2. A browser that supports DoH, or, a stub resolver that supports DoH.

    Possible Scenarios

    1. Configure your browser to use DoH.
      • This will only protect DNS queries made by your browser.
      • Note that this is an example of an app not using the OS as a resolver, and hence by-passing the OS’s DNS settings!
    2. Any of the scenarios above for DoT.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Scroll to top