How DNS Works
To properly understand the various DNS services and features available in Azure, it is first necessary to understand how the domain name system works. In particular, it is important to understand the different roles played by recursive and authoritative DNS servers, and how a DNS query is routed to the correct DNS name servers using DNS delegation.
First, it’s important to understand the distinction between a domain name, and a DNS zone. The internet-facing domain name system is a single global name hierarchy. A domain name is just a name within that hierarchy. Owning a domain name gives you the legal right to control the DNS records within that name and any subdomains of that name.
You purchase a domain name from a domain name registrar. The registrar then lets you control which name servers (NS) receive the DNS queries for that domain, by letting you configure the NS records for the domain.
A DNS zone is the representation of a domain name in an authoritative DNS server.
It contains the collection of DNS records for a given domain name. The service hosting the DNS zone lets you manage the DNS records within the zone and hosts the data on authorita- tive name servers, which answer DNS queries with DNS responses based on the configured DNS records.
In Azure, you can purchase domain names using the App Service Domains service. DNS zone hosting is provided by Azure DNS.
The DNS settings on the user’s device point to a recursive DNS server, also sometimes known as a local DNS service (or LDNS) or simply as a DNS resolver. The recursive DNS service is typically hosted by your company (if you’re at work) or by your ISP (if you’re at home). There are also public recursive DNS services available, such as the Google public DNS (8.8.8.8) service. The recursive DNS service doesn’t host any DNS records, but it allows your device to off-load most of the work associated with resolving DNS queries.
To understand the role of recursive and authoritative DNS servers, consider Figure 4-45, which describes the DNS resolution process for a single DNS query, www.contoso.com.
FIGURE 4-45 The DNS resolution process
This resolution process is described here:
- Your PC makes a DNS query to its locally configured recursive DNS server. This query is simply a packet sent over UDP port 53, although TCP can also be used (typically when responses are too big to fit in a UDP packet).
- Assume the recursive DNS server has just been switched on, so there is nothing in its cache. It passes the query to one of the root name servers (the addresses of the root name servers are preconfigured). The root name servers are authoritative name serv- ers—they host the actual DNS records for the root zone. A zone is simply the data representing a node in the DNS hierarchy.
- The root name servers don’t know anything about the contoso.com DNS zone. They do, however, know where you can find the com zone. So, they return a DNS record of type NS, which tells the recursive DNS server where to find the com zone.
- The recursive server tries again, this time calling the com name servers. Again, these are authoritative name servers, this time for the com zone.
- These name servers don’t recognize “www.contoso.com,” but they do have NS records
that define where the contoso.com DNS zone can be found. - The recursive server tries again, this time calling the authoritative contoso.com name servers.
- These servers are authoritative for the contoso.com DNS zone. And there is a record on these servers matching the www record name. The server does recognize the www. contoso.com query name and returns the A record response that maps this name to an IP address.
- The recursive server then returns this result back to the client.
The recursive DNS server can also follow a chain of CNAME records (which map one DNS name to another name). And the recursive DNS server also caches the responses it receives, so that it can respond more quickly next time. The duration of the cache is determined by the TTL (time-to-live) property of each DNS record.
The domain name system is a distributed system, where one set of servers can refer que- ries to another set using NS records. The process you’ve just seen to map a query name to a result—perhaps via a long chain of authoritative DNS servers—is called DNS name resolution.
The NS records tell clients on the internet where to find the name servers for a given DNS zone. The NS records for a DNS zone are configured in the parent zone, and a copy of the records is also present in the child zone. Setting up these NS records is called delegating a DNS domain.
A fully qualified domain name (FQDN) is a domain name containing all components all the way up to the root zone. Strictly speaking, a fully qualified name ends with a “.” (for example, www-dot-contoso-dot-com-DOT), which represents the root zone, although by convention, the trailing period is often omitted.
Reverse DNS is the ability to map an IP address to a name (as opposed to map a name to an IP address, which is what normal DNS provides). Some applications use reverse DNS as a weak form of authentication. For example, it’s commonly used in email spam-scoring algorithms.
Reverse DNS lookups use a DNS hierarchy that is completely independent of the forward lookups. The reverse lookup for “www.contoso.com” does not sit in the contoso.com zone. Instead, it sits in a separate DNS zone hierarchy based on reversed IP addresses. For example, suppose “www.contoso.com” resolves to IP address 1.2.3.4. Typically, the reverse lookup for the IP address 1.2.3.4 will be a record named 4 in the DNS zone 3.2.1.in-addr.arpa, giving a FQDN of 4.3.2.1.in-addr.arpa (notice the reversed IP address.)
Reverse DNS lookup zones are controlled by whomever owns the IP subnet. The reverse DNS lookup zone for an IP block you own can be hosted in Azure DNS. Public IP addresses in Azure reside in Microsoft-owned IP blocks, which means the reverse DNS lookups use Microsoft-managed reverse DNS lookup zones.
There’s nothing in the domain name system to ensure the reverse lookup maps to the same name as was used in the forward lookup. That’s achieved simply by the correct configuration in both forward and reverse lookup zones.