Chris Appleyard

Let’s say you want to prevent people from knowing what websites you visit online, so you look into steps that you could use to stop people from snooping on your online activity encrypted DNS comes up and sounds like a great idea, but is it?

A DNS lookup happens every time your computer or smart phone needs to look up a DNS name to get data to help connect to the resource over the Internet using the Internet Protocol (IP). These look ups are anything from getting the IP address to use to connect to google.com or it could be to load elements on a website, like advertising.

The DNS data it self isn’t the end result of your daily Internet surfing, it’s the service your computer/smart phone uses to turn names into IP Addresses or data that helps your computer/smart phone to load the resources, think of it as a human-computer translator bridge.

So why encrypt the DNS data?

Encrypting the DNS data will further stop people from tapping your communications between you and the DNS resolver service you are using, the reason for encrypted DNS is to further stop Internet monitoring either by organisations or governments.

The website and data you load on the Internet is likely to be using HTTPS which is the HTTP (Hyper-Text Transport Protocol) application using SSL to encrypt the web data (HTTP data), so this prevents people from knowing what you have seen or read on the website you have connected too, however without encrypted DNS, people will know which website you have visited due to DNS being un-encrypted by default, so all the DNS names (google.com for example) will be able to get captured by organisations (like ISPs) or governments, the DNS data is one part of the “Meta data” that can build up your Internet usage profile.

This was true for years, until recently when DoH (DNS over HTTPS) and DoT (DNS over TLS) has been rolled out on mainstream web browsers, such as Mozilla Firefox.

Bundling Encrypted DNS into a web browser can significantaly help with your online privacy, as it makes sure the DNS lookups you do and the web application data (HTTP) is encrypted, meaning organisations/people/governments won’t be able to know what you are looking at or what you have visited, the only thing that they will know is that you have used the Internet using encryption.

However I would argue that most government agencies like GCHQ and NSA would probably have from their own intelligence or from third party providers a list of IP addresses that corrospond to common services on the Internet, like for example they probably know that if you are connecting to a website over port 443 (HTTPS) to 128.66.65.1 (example: RFC 5737 range) is used for google.com, so they know you’ve visited the page, in the same vein if you’re using What’s app or Signal which are common messaging platforms, their IP ranges are probably in a database somewhere so they will know you’ve used the services, regardless of the DNS requests you’ve made, so in my opinion in some cases, I don’t see the advantages of having encrypted DNS, it just adds complexity for no good reason.

In my opinion, encrypted DNS may help if the ISP or company you are working for (while connected to their network) doesn’t snoop on Internet activity and use third party tools to identify services you’ve been using, however the government will know! Also the DNS resolver service you are using will know because they will need to decrypt the DNS packet on their end to be able to deal with your request, further building on my argument that encrypted DNS solves nothing apart from catering to the needs of nerds that like to encrypt everything they can just because it’s cool.

When Cloudflare receives the packets back on their end, they will need to de-crypt the encrypted DNS data to be able to forward on the DNS request to then resolve the full query from their nameservers. So this means Cloudflare could be building up a profile if your Internet habits. It’s also possible that if required by law, Cloudflare could give this information/data to the police or governments.

Anyway.. let’s see what an encrypted packet looks like, just out of curiosity..

I’ve used an encrypted DNS client calleddoh-cli: https://github.com/libreops/doh-cli

Let’s perform a query for the A record for google.com

I am using DoH in this example (DNS over HTTPS)

doh-cli google.com
142.251.32.14

Using Wireshark to capture the packets we can see the transaction take place:

The first steps is to open up a TCP connection with the required Window and the typical TCP connection steps, then it sets up a TLS connection with the server with the servers required TLS settings etc.

Then you can see on packet #13 the actual data (DNS query) is sent to the server, here’s what this packet looks like:

Transmission Control Protocol, Src Port: 57756, Dst Port: 443, Seq: 598, Ack: 2910, Len: 262
    Source Port: 57756
    Destination Port: 443
    [Stream index: 0]
    [Conversation completeness: Complete, WITH_DATA (31)]
    [TCP Segment Len: 262]
    Sequence Number: 598    (relative sequence number)
    Sequence Number (raw): 681894599
    [Next Sequence Number: 860    (relative sequence number)]
    Acknowledgment Number: 2910    (relative ack number)
    Acknowledgment number (raw): 538379461
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x018 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Accurate ECN: Not set
        .... 0... .... = Congestion Window Reduced: Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······AP···]
    Window: 2048
    [Calculated window size: 131072]
    [Window size scaling factor: 64]
    Checksum: 0x30f0 [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
    [Timestamps]
    [SEQ/ACK analysis]
    TCP payload (262 bytes)

Transport Layer Security
    TLSv1.3 Record Layer: Application Data Protocol: Hypertext Transfer Protocol
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 257
        Encrypted Application Data: cda06749b06adb96a69513ae613895feeea283273f12de23042eb9230d17c8576bb55218…
        [Application Data Protocol: Hypertext Transfer Protocol]

You can see the TCP and TLS parts of the packet here, within the TCP section you can see it’s using port 443 HTTPS to transmit the DNS data and within the TLS section of the packet you can see the data, which is encrypted, so there’s no way to find out what the query is.

This packet is the one that will get seen by your ISP and anyone between you and the DNS resolver service you are using. The DNS resolver service will de-crypt this data and then perform the query on their resolvers and maybe even go through the full resolution process if they don’t have the answer in their cache.

Encrypted DNS is something I use just because NextDNS makes it easy and it doesn’t really slow down DNS resolution so it’s no biggie.. however by just using something like Cloudflare or NextDNS on your phone via their app, it might not provide that much privacy.. there’s always an argument with having your own local DNS resolver like Unbound so you can configure settings that meet your security and privacy needs, such as QName minimisation [https://www.rfc-editor.org/rfc/rfc7816], which provides some privacy when resolving DNS queries, it means that if the resolver has google.com cached, but it doesn’t have docs.google.com cache, instead of doing a full resolution, it will just ask the Nameservers for google.com where “docs” is, it cuts down on the number of queries and therefor stops the upstream DNS provider knowing exactly what you are resolving.

Anyway, I hope you found this somewhat useful, keep that tin foil hat on!

Am I wrong? happy to be proved wrong! please comment! 🙂