The Modern Internet requires only two things of the internet user:
DNS (Domain Name Service)
What is DNS? A globally distributed and resilient database of names to IP addresses (both v4 & v6).
Why do we need it? Because the sheer number of websites and other services on the internet is too large for humans to memorize. It is much easier to name, than an IP address (this is especially true for IPv6).
In this article, we’ll pose questions, and provide answers to the following:
How does a host get DNS? DHCP/RA
What is DNS Search List, and how does it help?
Captive Portals, redirecting DNS requests, how IPv4 and IPv6 are different
Where is DNS resolved? Problems with DoH
Using DNS on SOHO rather than IP addresses
How to use local DNS and DoH?
Where does the address(es) for DNS server(s) come from?
We’ll assume you have an internet address (v4 and/or v6), but where does DNS come from?
Of course there is nothing stopping you from manually entering in an IP address for a DNS service. But in a larger environment, entering DNS manually gets to be about as much fun as entering IP addresses manually.
Since the late 1990’s there has been an easier way than manual entry of not only IP addresses, but also the addresses of DNS servers, using DHCP (Dynamic Host Configuration Protocol). Not only will the DHCPv4 server provide good IP address info, but via the DHCP options, a plethera of other info can be conveyed to the requesting client, including the address of a DNS server.
In 2003, DHCPv6 was patterned from DHCPv4. Naturally somethings had to be changed (e.g. the default gateway does not come from DHCPv6) because IPv6 made improvements over the old IPv4. But the concept of options remained, although the option numbers are different from DHCPv4. So it is possible for a DHCPv6 client to receive the IPv6 address of a DNS server via DHCPv6 options.
Router Advertisements (RAs)
Although getting an IPv6 address via SLAAC (Stateless Auto Address Coniguration) has been with IPv6 from the beginning (1998), the ability to convey a DNS server address was added later to the RA (2007). It became a standard in 2010, and was again revised in 2017 with wider deployment.
As part of the RA, the RDNSS option is transmitted, which has one or more IPv6 addresses of DNS servers the SLAAC client can use.
What if your host gets multiple DNS servers from different methods?
So it is possible to get a DNS server address from three different sources, DHCPv4, DHCPv6, SLAAC/RA. What if the DNS servers in each are different? How does a host determine which DNS server to use?
RFC 6731 mentions that the client must create a list of DNS resolvers, and consider trust in prioritizing them. And RFC 8106 states that DHCP should be preferred over RAs for DNS information. But how do Operating Systems (implementations of this standard) really behave?
|Windows 10||Mac OS X||Linux||BSD||Android/Chrome OS|
And of course, it is good practice to announce (via DHCP or RA) the same DNS service. But what happens if your Pi-Hole announces itself (over DHCPv4) as the DNS server, but your router announces itself (over DHCPv6) as the DNS service? You ad-blocking service may seem flakey or not working at all. It is important to know how your OS will respond to different DNS services being announced to your host.
PvDs (Provisioning Domains) architecture (RFC 7556) is designed to help, in creating a single network-based configuration mechanism.
DNS Search List (DNSSL)
DNS Search List is a shortcut, or a method to save on typing long FQDNs (Fully Qualified Domain Names). For example, if I have servers in my house which have DNS names: nas.example.com, router.example.com, and music.example.com, without search lists I would have to type in the FQDN each time I wanted to access each server.
But with a search list of example.com, the DNS client will automatically append example.com to each of my queries. With this, I only have to type nas and the DNS client will do a query for nas.example.com
Getting a DNSSL
Like the address of the DNS service, DNSSL is distributed by similar methods, using DHCPv4, DHCPv6, and RA DNSSL option (RFC 8106 Sect 5.2 ).
Unlike the RDNSS option, having different search lists (from different sources) is less of an issues, since the DNS client will merely do multiple searches, appending the separate search list names looking for a response.
Unfortunately, not all hosts support DNSSL in the RA at this time. For example, ChromeOS ignores RA DNSSL option, and FQDNs must be typed.
Captive Portals and DNS
Captive portals are used in Airports, and coffee shops to ensure users accept the terms of the service before proceeding.
Have you ever given thought to how your device is redirected to a Captive Portal page, no mater what hostname you have entered? Again, it comes down to DNS. The Captive Portal advertises itself as the DNS server. Any request is replied to by one answer, the website of the captive portal.
Once the agree button has been tapped, then and only then will DNS answer requests with the real IP address of the requested host.
But what if you had a manually entered DNS server? Would you be able to bypass the Captive Portal? No, Captive Portals also have a forwarding table, and it isn’t populated until you “agree” to the terms.
DNS Redirection using IPv4 & man-in-the-middle-attack
Captive portals not only give one DNS answer in response to any DNS request, but they often also use Firewall rules and NAT to forward your DNS requests to their DNS server, regardless to what you have manually set your DNS server to be. It does this by creating a NAT rule, which is a man-in-the-middle attack on your DNS request. It allows the Captive Portal to pretend to be your preferred DNS server. This is part of the evil of NAT.
DNS Blocking using IPv6
Because NAT is Evil and is not used in IPv6, we can’t use the man-in-the-middle attack method of IPv4. But we can create firewall filters which block all DNS requests except to our IPv6 DNS server. In the IPv6 network, we distribute our DNS server address via DHCPv6 or RA RDNSS. If the end user attempts to use their own DNS server, the request will be blocked.
This is a simpler solution which does not require spoofing the users DNS server.
Getting around DNS redirection/blocking with DoH
DoH (DNS over HTTPS, RFC 8484) is a recent addition to the DNS landscape. Why would you want to use DoH? From RFC 8484
These use cases are preventing on-path devices from interfering with DNS operations
However DNS involves a certain amount of trust. Trust that you will receive an unbiased and correct response to a DNS query. As you have seen DNS Redirection breaks that trust by masquerading the Captive Portal DNS server as the one you thought you were using.
By using a DoH service, such as Cloudflare or Google, you are trusting that that corporation will always provide an unbiased and correct answer. Since they are private corporations, this may not always be the case (imagine Google providing you a better website for the info you are seeking than the one you requested)
DoH and local DNS
The difficulty with DoH is that it is a direct connection to the service and bypasses any opportunity to have your local names resolved. This means you can’t get to your NAS by name, which is a step backwards.
This can cause confusion as to the exact nature of the problem, since many confuse the lack of a DNS response with broken network connectivity.
SOHO: Using local DNS names rather than IP addresses
With the addition of more devices on the local network, and the addition of IPv6, it is time to start thinking about using DNS in the SOHO (Small Office, Home Office). As mentioned earlier, humans remember names more readily than numbers. Therefore assign names to your devices, and reference them by name rather than by number.
There are a couple of methods to creating DNS in the SOHO.
The old fashioned way, manual entry into a DNS Zone file
Automatic Dynamic DNS record creation (preferred)
Most modern SOHO routers have a DNS server built in. Using OpenWrt, DNS names will be created when the device does a DHCP request (with the name option). For those hosts which support DHCPv6, Dynamic DNS names will also be created.
There is even software which runs on OpenWrt which will automatically assign names to your SLAAC-only (think: Android/IoT) devices.
With local DNS, you can now access your network storage by name nas or your printer printer. When you upgrade your printer, you only need update the DNS entry, and all your computers will be able to print to it.
Local DNS + DoH = OpenWrt
What happens if you are concerned about DNS privacy, and want to run DoH and have the convenience of Local DNS? If you run OpenWrt on your SOHO router, you can do both!
OpenWrt can serve as your local DNS server, and will make any external DNS requests via DoH to your preferred provider (e.g. Cloudflare, Google, etc).
DNS, it is a good thing
DNS is an abstraction layer that was created in the 1980s to allow the internet to grow and expand beyond our limited memory of IP addresses. Much has changed in how a host gets the address of a DNS server, but the usefulness of DNS, even on the local network (including IPv6) has made the internet easy.
Orignally posted on makiki.ca