30.11.2020 How can you make your DNS set up more secure when traversing the internet? And why is it so important in the current climate? SureCity Networks’ Lewis Kellar shares his knowledge about all things DNS and provides a detailed look at common exploits as well as privacy concerns of unencrypted DNS queries.
Types of DNS security
There are a few different types of DNS security which achieve different objectives in different ways.
Normal DNS requests run on port 53 and are all in plain text so if you can sniff or inspect the traffic in transit you can also see the domain name that was queried and the IP address that the DNS server replied with.
DNS Exploits
DNS hijacking is one of the most common DNS exploits and usually rely on either rogue DNS servers which either legitimate servers that have been compromised or servers owned and operated by malicious parties. The other option for DNS hijacking is man in the middle MITM attacks where a third party intercepts the DNS communication between a client and a DNS server.
Both of these attacks are usually designed to send the client a fake DNS response to direct them to a malicious site or return an NXDOMAIN response for denial of service.
Once redirected to a malicious site a malicious actor can the deploy any number of attacks such as phishing or auto-fill attacks to gather credentials or other sensitive info, serving malware downloads or browser add-ons, or running web-based crypto miners.
It should be noted that DNS hijacking can and is actively used by ISPs across the world. The most notable of which is returning NXDOMAIN responses for queries to popular torrent site thepiratebay.org. Returning NXDOMAIN when the domain definitely does exist violates the RFC2308 standard. However, more often than not this NXDOMAIN response is simply served from the ISP DNS servers and switching to a different DNS provider will allow you to reach a site that an ISP is trying to block. However, some other ISPs have been doing the opposite where instead of returning an NXDOMAIN response when the domain doesn’t exist it will return a response for a service website that the ISP has partnered with to provide web search services for their customers, along with serving advertisements.
In this instance which has now been resolved, the ISP Earthlink redirected their customers to Barefruit instead of service NXDOMAIN responses, and since the Barefruit website was vulnerable to a cross-site scripting attack it potentially put all their customers privacy at risk: https://www.wired.com/2008/04/isps-error-page/
There’s also a lot of issues that DNS hijacking causing from a service perspective and the Wikipedia article on the subject goes into details on a few of them: https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_ISPs
ISP snooping
There have been numerous reports of ISPs, mainly those in the United State, that have been caught harvesting and selling the location and browsing data of their customers to advertising firms. https://arstechnica.com/tech-policy/2019/11/isps-lied-to-congress-to-spread-confusion-about-encrypted-dns-mozilla-says/
So now that we’ve covered why DNS security is important, let’s look into some of the option available to secure DNS queries over the Internet.
Domain Name System Security Extensions (DNSSEC)
The first thing to point out when looking at DNSSEC is that it doesn’t encrypt the payload, so anyone snooping on your DNS queries can still see what you’re querying and the DNS response to it.
The main point for DNSSEC is to prevent those hijacking exploits we mentioned earlier. What DNSSEC does do is sign the record you’re receiving to validate that it’s the same as the one that is published on the authoritative name server.
The problem with DNSSEC is that it requires all devices in the chain to support it or it doesn’t work end to end. Now this might not be a big deal depending on what your security goals are, it also will depend on what part of the DNS chain your managing.
You can see this by running dig on a DNSSEC enabled domain such as verisignlabs.com.
This probably isn’t super important for SMBs, but if you’re running a DNS resolver at an ISP or a large corporation you’ll probably want to make sure all your recursive lookups of top level domains are being returned auth the correct responses. You’ll only need to enable it on the resolvers you have control over, you can then provide non-authoritative responses to your DNS clients that don’t have DNSSEC enabled. You can then have confidence that the DNS responses you’re providing are legitimate.
DNS over HTTPS (DoH)
DoH does what is says on the box, instead of DNS queries going out to the internet unencrypted, they are sent as either a secure HTTP GET or POST method. A typical DoH GET request for www.example.com looks like the below, as shown in RFC8484: https://tools.ietf.org/html/rfc8484
:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message
The DNS record being queried is encoded with Base64URL which is the code you see passed as the value for variable ?dns= and this is how the data is formatted before it is encrypted and sent to the DNS server.
This is a great way to secure DNS queries against prying eyes of governments and corporations alike. So much so that when Mozilla tried to implement it for Firefox users in the UK they were called out by the Internet Service Providers Association (ISPA) who falsely claimed that it would bypass their government mandated site blocking and parental controls. They later apologised after Mozilla called them out on it, but still Mozilla ended up not enabling DoH for UK users.
You can read a bit more about it here: https://www.zdnet.com/article/uk-isp-group-names-mozilla-internet-villain-for-supporting-dns-over-https/
DNS over TLS (DoT)
DNS over TLS is similar to DoH, but doesn’t format the request as a HTTPS packet, but instead keeps it formatted as a normal DNS request by encrypts it in transit to the DNS server. One other notable difference is that DoT uses port 853 which can be used to easily pick it out from other traffic on the network, whereas DoH uses the standard HTTPS port of 443 and so this traffic can easily blend into other web traffic.
DoH is seems to be one of the more commonly adopted implementation of DNS security measures with a large number of browsers and applications explicitly supporting it, however NETSCOUT did an analysis on traffic for DoH vs DoT and they found there was 7 times as much DoT traffic than DoH in the networks they monitored: https://www.securitymagazine.com/articles/91674-disappearing-dns-dot-and-doh-where-one-letter-makes-a-great-difference
DoH vs DoT
Both DoH and DoT are similar in what they were designed to accomplish which is to encrypt DNS traffic between the client and the server to ensure that it’s not inspected or hijacked by a third party.
The fact that DoT uses port 853 can be an advantage to DoH because a number of firewalls won’t have TCP 853 open outbound, but they will have TCP 443 open outbound for web traffic. This is of course if they are still using port-based firewall rules instead of application based.
iOS 14 and macOS 11 DNS changes
In iOS 14 and macOS 11 Apple have enabled DoH and DoT by default so that iPhones and MacBook will try to resolve using these secure DNS methods before trying standard DNS resolution. They’ve also enabled IPv6 record lookups by default.
In addition, they’ve also made the following three changes:
- Users will be able to specify a system wide DoH resolver that will override the DNS resolver set by DHCP or RA
- Domain owners will be able to designate DoH resolvers that will override the DNS resolver set by DHCP or RA for queries made for their domain
- Apps will be able to specify a DoH resolver that will override the DNS resolver set by DHCP or RA for queries made from their app.
The reddit post that inspired me to look into this issue a bit more reported a 10% increase when iOS 14 was released in late September: https://www.reddit.com/r/networking/comments/izie8l/anyone_seeing_an_increase_in_dns_traffic/
It’s worth noting that the increase in DNS traffic is anecdotal It hasn’t been conclusively tied to iOS14, there are also reports of it being the result of a Chrome feature called the Intranet Redirect Detector which generate DNS queries to randomly generated domains to see if they receive a response when they shouldn’t. This is used to detect if the DNS servers used are responding to domains with valid responses when they should be returning NXDOMAIN  https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-enormous-load-on-global-root-dns-servers/
https://bugs.chromium.org/p/chromium/issues/detail?id=1090985
Looking at trends from Akamai, DNS traffic has been trending upwards for the last 4 years and will probably continue on the same trajectory in the coming years:
Source: https://www.akamai.com/us/en/why-akamai/dns-trends-and-traffic.jsp
Corporate DNS security
It seems a little counterintuitive to have DNS security and firewall security working against each other, but sometimes that can be the case. There are a number of different opinions on what the best way to ensure data and network security and all of them seem to have merit to their arguments.
Like it or not DNS queries from corporate networks out to the public internet are often blocked for a number of reasons (security, privacy, bandwidth, etc.), as companies want to preference using internal corporate DNS servers, and blocking is usually performed on the edge firewall connecting the corporate network to the internet.
This is where DNS security, particularly DoH (as DoT can easily be identified by port), causes issues as this traffic can easily blend into normal web traffic, and with Chrome and Firefox increasingly trying to use secure DNS traffic by default, with Chrome for Android supporting it soon. Plus, with the addition of Apple devices using it by default, it comes as a potential blind spot for administrators trying to keep their endpoints secure.
This was seen in the Godlua malware which used DoH to connect to its command and control servers which helped it avoid passive DNS monitoring: https://www.zdnet.com/article/first-ever-malware-strain-spotted-abusing-new-doh-dns-over-https-protocol/
SSL/TLS decryption is a large part of corporate network security in terms of enforcing what traffic is and isn’t allowed to traverse the network. SSL/TLS decryption allows full inspection of traffic to detect malware, vulnerability signatures, phishing attempts, and much more, without this a majority of traffic would just show up in the logs as SSL traffic on port 443. This policy of decrypting SSL/TLS traffic to the internet also allows the decryption of DoH traffic so that it can be identified and blocked is great for administrators, but could be seen as a bit a step back for DNS security if new methods introduced to help with security are not implemented by the corporate IT community.
However, even after SSL/TLS decryption application identification may not always be 100% accurate, so even if DoH traffic is decrypted it may still show up as SSL or web-browsing applications, or even just as incomplete.
Conclusion
Overall, these methods of DNS security, and especially the push by browser and OS developers is invaluable to everyone using the internet.
It’s also worth noting that DoH/DoT are not the only methods of encrypting DNS traffic, there’s also DNSCrypt and DNSCurve which are worth looking into if you’re interesting.
DoH/DoT and DNSSEC can work well together with DoT/DoH and DNSSEC combining to secure recursive lookups to authoritative name servers and DoT/DoH securing user browsing.
However, it’s important that the corporate IT community, especially those in larger corporations and ISPs, work to enable DNS security methods such as DoH/DoT and DNSSEC so that we can work towards more secure networks, both public and private.
Lastly, if you haven’t already it’s probably a good idea to switch from using your ISP provided DNS servers for your home internet.
