How’s that for a confuding title? In a recent email discussion, a colleague compared the Decentralized Identifier framework to DNS …suggesting they were similar. I cautiously tended to agree but felt I had an overly simplistic understanding of DNS at a protocol level. That email discussion led me to learn more about the deeper details of how DNS actually works – and hence, this article.
On the surface, I think most people understand DNS to be a service that you can pass a domain name to and have it resolved to an IP address (in the familiar nnn.ooo.ppp.qqq format).
domain name => nnn.ooo.ppp.qqq
- If you click on Google DNS Query for microsoft.com, you’ll get a list of IP addresses associated with the Microsoft’s corporate domain name microsoft.com.
- If you click on Google DNS Query for www.microsoft.com, you’ll get a list of IP addresses associated with the Microsoft’s corporate web site www.microsoft.com.
NOTE: The Google DNS Query page returns the DNS results in JSON format. This isn’t particular or specific to DNS. It’s just how the Google DNS Query page chooses to format and display the query results.
DNS is actually much more than a domain name to IP address mapping. Read on…
DNS Resource Records
There is more to the DNS Service database than these simple (default) IP addresses. The DNS database stores and is able to return many different types of service-specific IP addresses for a particular domain. These are called DNS Resource Records. Here’s a partial list from http://dns-record-viewer.online-domain-tools.com:
Most APIs only support the retrieval of one Resource Record type at a time (which may return multiple IP addresses of that type). Some APIs default to returning A records; while some APIs will only return A records. Caveat emptor.
To see a complete set of DNS Resource Records for microsoft.com, click on DNSQuery.org query results for microsoft.com and scroll down to the bottom of the results page …to see the complete response (aka authoritative result). It will look something like this:
Figure 1. DNS Resource Records for microsoft.com: Authoritative Result
NOTE: The Resource Record type is listed in the fourth column: TXT, SOA, NS, MX, A, AAAA, etc.
UPDATE: The complete list of allowable value ranges for RR (resource record) types (QTYPEs) can be found here: IANA: Resource Record (RR) TYPEs.
The most interesting new information/learnings is about the DNS protocol. It’s request/response …nothing new here. It’s entirely binary …to be expected given its age and the state of technology at that time. Given how frequently DNS is used by every computer on the planet, the efficientcy of a binary protocol also makes sense. The IETF published the original specifications in RFC 882 and RFC 883 in November 1983.
The new part (for me) is that an API typically doesn’t “download” the entire authoritative set of DNS Resource Records all at once for a particular domain, the most common API approach is to request the list of IP addresses (or relevant data) for a particular Resource Record type for a particular domain.
The format of a sample DNS request is illustrated in the following figure:
Figure 2. Sample DNS Request [CODEPROJECT]
It’s binary. The QTYPE (purple cells on the right side) defines the type of query. In this case 0x0F is a request for an MX record; hence, this is a request for the data that describes microsoft.com’s external email server interface.
NOTE: The “relevant data” isn’t always an IP address or a list of IP addresses. For example, response may include another domain name, subdomain name, or, in some cases, simply some unstructured text (as far as the DNS specification is concerned).
Here is a typical response for the above sample request:
Figure 3. Sample DNS Response [CODEPROJECT]
The response in turn is also binary. In this case, DNS has responded with 3 answers; that is, 3 subdomain names: mailc, maila, and mailb – each with a numerical preference (weight).
The ANY Resource Record Type
There is also a “meta” Resource Record Type called ANY that, as you might guess, requests a collection of all of the different Resource Record type records. This is illustrated in Figure 1 above.
Michael Herman (Toronto/Calgary/Seattle)