DNS is one of the key services for TCP/IP based networks. It has been around a long time. It was first specified in RFC 882, “Domain Names – Concepts and Facilities”, November 1983 and RFC 883, “Domain Names – Implementation and Specification”, November 1983. RFC 883 was later replaced by RFC 1035, “Domain Names – Implementation and Specification”, November 1987, which is the current specification for basic DNS.
Without DNS we’d have to enter numeric addresses for all nodes we want to contact, or at best each manage our own /etc/hosts file to map symbolic names onto IP addresses. If we didn’t have DNS, we certainly would not be worrying about running out of IPv4 addresses now. There might be 100,000 people in the world that could figure out how to use the Internet without it. With DNS, there are literally billions. I recently told Paul Mockapetris, the inventor of DNS (tongue in cheek) that is was all his fault we are running out of IPv4 addresses now, because he made it so easy to use the Internet that now everybody can. He happily accepted the blame. Paul Mockapetris is one of the true fathers of the Internet.
DNS was originally designed to support only IPv4. It was later extended to also support IPv6 in RFC 1886, “DNS Extensions to support IP version 6”, December 1995. This was one of the orginial five RFCs that introduced IPv6. This RFC introduced the AAAA (“quad A”) resource record (IPv6 addresses are four times as long as IPv4 addresses, so the resource record name for IPv6 addresses is four times as long as the one for IPv4). It also introduced a 128 bit version of the PTR resource record (used for reverse lookups). It specified how to access a DNS server over IPv6 (both UDP for queries and TCP for zone transfers). DNS was flexible enough that a completely new protocol or design was not needed to extend support for IPv6. Most DNS server products today support IPv6.
The A6 resource record was added in RFC 2874, “DNS Extensions to Support IPv6 Address Aggregation and Renumbering”, July 2000. Later the A6 resource record was found to be problematic, and RFC 2874 was moved to “Experimental” status, in RFC 3363 “Representing Internet Protocol version 6 (IPV6) Addresses in the Domain Name System (DNS)”, August 2002. Nobody should be using the A6 record currently.
DNS forward resolution involves mapping domain names (e.g. alice.v6lab.net) onto IP addresses (both IPv4 and IPv6). The DNS server has a database with various forward zones (one for each domain name for which it is authoritative) that include A and AAAA records mapping names within that zone to IPv4 and IPv6 addresses.
In the diagram below, bob.v6lab.net makes a DNS query over UDP port 53 to the DNS Server (which is authoritative for v6lab.net) for the IP address of alice.v6lab.net. The DNS server looks in its zone file for v6lab.net, and finds two resource records there, an A record (with IPv4 address) and a AAAA record (with IPv6 address). It returns those to bob.v6lab.net over UDP port 53. If the DNS Server was not authoritative for v6lab.net, it would have to do a recursive query to the DNS server that is authoritative.
DNS reverse resolution maps IP addresses (e.g. 172.25.3.100) to domain names (e.g. alice.v6lab.net). This works for both IPv4 and IPv6, but unlike forward zones, reverse zones are either all IPv4 (PTR records) or all IPv6 (PTR-128 records). Its database contains various reverse zones, one for each subnet prefix for which it is authoritative. The IPv4 reverse zones are under “ip-addr.arpa”, while IPv6 reverse zones are under “ip6.arpa”.
In the diagram below, bob.v6lab.net makes a DNS query over UDP port 53 to the DNS Server (which is authoritative for 172.25.0.0/16) for the nodename associated with IP address 172.25.3.100. The DNS server looks in its reverse zone file for subnet 172.25.0.0/16, and finds a PTR resource record there for 172.25.3.100, with nodename alice.v6lab.net. It returns that to bob.v6lab.net over UDP port 53. If the DNS Server was not authoritative for 172.25.0.0/16, it would have to do a recursive query to the DNS server that is authoritative.
In the diagram below, bob.v6lab.net makes a DNS query via UDP/53 to the DNS Server (which is authoritative for 2001:db8:1000:2000::/64) for the nodename associated with IP address 2001:db8:1000:2000::3:100. The DNS server looks in its reverse zone file for subnet 2001:db8:1000:2000::/64, and finds a PTR resource record there for 2001:db8:1000:2000::3:100, with nodename alice.v6lab.net. It returns that to bob.v6lab.net via UDP/53. If the DNS Server was not authoritative for 2001:db8:1000:2000::/64, it would have to do a recursive query to the DNS server that is authoritative.
DNS clients (on every node) make “queries” to the DNS server you configured in the each node’s TCP/IP network configuration, on UDP port 53. Under some circumstances it may do a query on TCP port 53. DNS servers do zone transfers to each other on TCP port 53. There is no “DNS over SSL” security. There is something called DNSSEC that adds digital signatures to all DNS resource records, for End-to-End authentication (“this came from the real authoritative server”) and message integrity (“the information hasn’t been tampered with since it was stored on the authoritative server”). Without DNSSEC you can’t really trust the information in DNS anymore. Hackers have found ways to replace the real IP addresses in DNS with bogus ones, so you think your are connecting to www.mybank.com, but in reality you are connecting to a server that looks a lot like www.mybank.com in some hacker’s basement. You enter your credentials, and it says “sorry, site down for maintenance”. By the time you log back in, your bank account is empty.
You can think of DNS as the “telephone directory” for the Internet. It implements a hierarchical symbolic namespace for TCP/IP nodes that is mapped onto numeric IP addresses using a distributed database. Both the database engine and the data are distibuted, all over the world. There are perhaps 2 million DNS servers in the world. Every domain name in use (e.g. sixscape.com) has the resource records for every node in that domain (e.g. “www.sixscape.com”) hosted on DNS servers that are “authoritative” for that domain. You can find the authoritative server(s) for any domain using the nslookup or dig. For example:
C:\Users\lhughes>nslookup – 220.127.116.11
Default Server: b.resolvers.Level3.net
> set q=any
sixscape.com AAAA IPv6 address = 2001:470:3d:3000::21
sixscape.com internet address = 18.104.22.168
primary name server = dns21.infoweapons.com
responsible mail addr = it.infoweapons.com
serial = 17
refresh = 10800 (3 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 3600 (1 hour)
sixscape.com nameserver = ns2.sixscape.com
sixscape.com nameserver = ns3.sixscape.com
sixscape.com nameserver = ns1.sixscape.com
sixscape.com MX preference = 10, mail exchanger = aspmx2.googlemail.com
sixscape.com MX preference = 10, mail exchanger = aspmx3.googlemail.com
sixscape.com MX preference = 1, mail exchanger = aspmx.l.google.com
sixscape.com MX preference = 5, mail exchanger = alt1.aspmx.l.google.com
sixscape.com MX preference = 5, mail exchanger = alt2.aspmx.l.google.com
ns1.sixscape.com internet address = 22.214.171.124
ns1.sixscape.com AAAA IPv6 address = 2001:470:3d:100::21
ns2.sixscape.com internet address = 126.96.36.199
ns2.sixscape.com AAAA IPv6 address = 2001:470:3d:100::22
ns3.sixscape.com internet address = 188.8.131.52
ns3.sixscape.com AAAA IPv6 address = 2001:470:3d:100::23
This shows that the authoritative DNS servers for sixscape.com are ns1.sixscape.com, ns2.sixscape.com and ns3.sixscape.com. All three of those servers are accessible over both IPv4 and IPv6.
Most people don’t have direct access to the authoritative servers for sixscape.com for their clients to resolve nodenames like www.sixscape.com. However, you have a local DNS server that is probably “caching only” (it may be in your home, or at your ISP). It does recursive DNS queries on your behalf and caches the results locally for however long the TTL records say to cache them. It can contact the authoritative servers for sixscape.com through the worldwide DNS network.
If you use a browser on your node to surf to the domain name www.sixscape.com, the following steps happen (any of these queries can happen over IPv4 or IPv6, depending on which nodes support IPv6):
Step 1 – your browser will use the DNS client on your node (called a resolver) to look up the domain name www.sixscape.com.
Step 2 – your DNS client will first check in the local DNS cache (on your node) and if it finds the nodename www.sixscape.com there (along with the IP addresses), it will go directly to step 7. BTW, you can empty the local DNS cache on your node with the command “ipconfig /flushdns”.
Step 3 – your DNS client will ask your local caching DNS server (one of the addresses you configured as “DNS servers” during TCP/IP network configuration) to resolve the domain name www.sixscape.com. If that DNS server finds that nodename (along with the IP addresses), it will return it to your DNS client, and you go to step 7.
Step 4 – the information isn’t cached anywhere, so your local DNS server now needs to do a “recursive query”. It asks one of the root DNS servers “who is authoritative for .com”, and gets back the domain name and IP address of one of more servers that are.
Step 5 – your local DNS server will ask one of servers authoritative for .com “who is authoritative for sixscape.com”. It will get back the three nodenames and pairs of IP addresses above.
Step 6 – your local DNS server will ask one of those three servers “what is the IP address for www.sixscape.com”. It will get back two records, an A record with the address 184.108.40.206 and a AAAA record with the address 2001:470:3d:3000::21 (these addresses may have changed by the time you read this). Your local DNS server caches this information for future reference and returns those results to the DNS client on your node. Your node also caches that information locally, on your node, for future reference.
Step 7 – Your node now has both IP addresses for www.sixscape.com. If your node supports only legacy IPv4, it will use the IPv4 address (220.127.116.11). If it supports only IPv6, it will use the IPv6 address (2001:470:3d:3000::21). If it supports both, it will try IPv6 first, and if that doesn’t work, it will fall back to IPv4.
Do I Even Need To Be Able to Access DNS over IPv6?
From an IPv4-only network, or an IPv4-only node, you can’t access DNS over IPv6 at all. It doesn’t matter if it can also accept queries over IPv6, as no IPv4-only node will be able to access it that way.
In a Dual Stack network, if there is a DNS server that supports queries over IPv6, then you can configure IPv6 addresses of DNS on all your client nodes and use DNS over IPv6, just like you can use DNS over IPv4. You will get exactly the same information as you would over IPv4. You can obtain A and AAAA records from DNS no matter what version of IP you use to access it. In theory you can leave all of your dual stack clients using DNS only over IPv4 and everything will work fine. Windows XP does support IPv6 in many ways, but it is unable to access DNS over IPv6. It still works fine in a dual stack network (so long as there is a DNS server that supports IPv4).
From an IPv6-only network, or an IPv6-only node, you can’t access DNS over IPv4 at all. For your nodes to work, you will need a DNS server that can accept queries over IPv6. It doesn’t matter if it can also accept queries over IPv4, as no IPv6-only node will be able to access it that way. Windows XP will work in an IPv6-only network, but cannot access DNS, so all connections must use IP address literals. That’s pretty brutal, especially since all addresses will be IPv6. BTW, to surf to a numeric IPv6 address, you must enclose the address in square brackets, so that the URL will not confuse the colons in the address with the colon before a port number. It may be better to say that Windows XP just doesn’t work in an IPv6-only network. When I once asked the person at Microsoft in charge of IPv6 why they didn’t fix Windows XP to be able to access DNS over IPv6, he replied “We already did. It’s called Vista” (this was right after Vista was released).
If you are planning to seriously support IPv6 in your network, it is time to finally say goodbye to Windows XP and Windows Server 2003. Microsoft was still learning IPv6 when that was released. Good support for IPv6 started with Vista and Windows Server 2008. It was improved in Windows 7 and Windows Server 2008 R2.
You can configure Windows (Vista and later) to be IPv6-only, by disabling IPv4 (both IPv4 and IPv6 are enabled by default). You can configure FreeBSD or Linux to be IPv6-only by not configuring any IPv4 network information. If you do so, you had better have a DNS server that can accept queries over IPv6. You may be unable to connect to file shares or network printers as well, unless they support IPv6. You will also be able to surf only to web sites that support IPv6 (dual stack and IPv6-only sites). Many more content providers are supporting it today (Google, Netflix, YouTube, Facebook, etc). Even Akamai (the popular content distribution network) supports IPv6.
Sixscape has a product that will allow you to still surf to legacy IPv4 sites, even if your network is IPv6 only. It is SolidProxy, a Layer 7 translating web proxy. You enter the IPv6 address of SolidProxy as the outgoing proxy address in all of your browsers, and magically you will be able to access any legacy IPv4 site as easily as if you had IPv4 on your node. It also works the other way around (accessing IPv6-only sites from an IPv4-only network).
Caching DNS servers can access the worldwide DNS network over IPv4 or IPv6. Enough of the DNS root servers, and DNS servers that are authoritative for Top Level Domains (e.g. “.com”) support IPv6, that you can do full recursive DNS lookups over IPv6 from anywhere in the world. Any dual stack DNS server that has access to both the IPv4 and IPv6 Internets can actually proxy DNS queries between IPv4 and IPv6 as needed. It could accept an incoming query over IPv6 and relay it to legacy servers over IPv4, then still return the results to you over IPv6.
How Can My Node Learn the IP Addresses of My Local DNS Servers?
In IPv4, you can manually configure one or two IPv4 addresses for DNS servers. Your network administrator (or ISP) probably gave you two addresses and said “use these for DNS”. Those are local caching DNS servers. They probably aren’t authoritative for any domains. Their purpose in life is to resolve DNS queries for end users.
There is probably also a DHCPv4 server in your subnet that can provide your node with valid IPv4 addresses of DNS. You can have your node automatically configure these by choosing DHCPv4 configuration.
In IPv6, you can manually configure one or two IPv6 addresses for DNS servers, the same as in IPv4. Your network administrator (or ISP) probably gave you two IPv6 addresses and said “use these for DNS”. Again, those are probably local caching servers.
There may also be a stateless DHCPv6 server from which you can obtain IPv6 addresses of DNS servers, but only if your node has a good DHCPv6 client (not all operating systems support DHCPv6).
RFC 6106, “IPv6 Router Advertisement Options for DNS Configuration”, November 2010, specifies extensions to SLAAC that allow your node to obtain IPv6 addresses of DNS (and a DNS search list) along with all the other subnet information previously supported. This is supported in both the client side and server side (Router Advertisement Daemon) in FreeBSD 9.x and various versions of Linux. No version of Windows supports this yet. Once this is widely supported, this will be the easiest way for your node to automatically obtain IPv6 addresses of DNS servers.
The Sixscape Distributed Network Management System (DNMS) can provide all supported client nodes (currently only Windows, XP and later, and Windows Server, 2003 and later) with all necessary IPv4 and IPv6 configuration, including IPv4 and IPv6 addresses of DNS, from a centrally managed server in each subnet. The central Subnet Agent currently runs only on Windows Vista and later, and Windows Server 2008 and later. This product is currently still in prototype form.