Home / Blogs

The Design of the Domain Name System, Part VI - Overloaded Record Types

In the five previous exciting installments, we’ve been looking at aspects of the design of the DNS (see part I, II, III, IV and V). Today we look at records types, and how you can tell what a DNS record means.

All the records in the DNS are strongly typed. Each record includes an RRTYPE, a small number, which defines both the format of the record and what the record means. It is possible and common to have different record types with the same format, but different meanings. For example, the NS (name server), CNAME (canonical name), and PTR (name pointer) records all contain a single domain name, but their semantics are quite different.

The original plan was that as people came up with new kinds of data to store store in the DNS, they’d define and add new RRTYPEs. But for a variety of good and bad reasons, many DNS applications have reused existing RRTYPEs rather than registering new ones. Until it becomes a lot easier to add new types to DNS servers and provisioning systems, this seems unlikely to change.

When an RRTYPE is reused, there are two ways to tell the new use from the original use, by name and by value. The most common technique is to put the RRs with reused types at names where they are unlikely to collide with the original usage. For example, DNSBLs reuse A records, but they are in their own branches of the namespace where host names never occur, so in theory there should be no collision. In practice, collisions occur all the time, when the domain name of an abandoned DNSBL is re-registered by someone else who parks it with a wildcard A record, thereby causing the abandoned DNSBL to appear to list everything. Well written DNSBL client code can defend against this by making the recommended checks in RFC 5782 intended to detect inappropriate wildcards, but it remains a problem.

A variant of this approach is to put reused records at prefixed names. The data for an attribute of example.com is stored at _attribute.example.com, for a suitable attribute. This approach has been reasonably successful in DKIM and VBR, putting TXT records at prefixed names, where the contents have a format defined by the DKIM or VBR application. But they are still subject to collisions due to unwise wildcards, and suffer from the related name problem I’ll address in the next installment.

The other way to manage reused records is by value, most often by putting a specified string at the beginning of a reused TXT record. For example, DKIM records usually start with “v=DKIM1” and SPF records with “v=spf1”. This also works reasonably well as a way to deal with inappropriate wildcards, and allows multiple applications to coexist at the same name, but at the cost of extra application logic to check the records and ignore the ones without the string the application expects. It also scales poorly. A request for the TXT records at a name always returns all of the TXT records, so the responses will be cluttered with unrelated records as more applications add them. (The design of the DNS anticipated this problem, which is why requests normally ask for a particular record type rather than for all records at a name.)

In the next installment we’ll look at the ways the DNS does and doesn’t handle names that are related to each other.

By John Levine, Author, Consultant & Speaker

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign

Domain Names

Sponsored byVerisign

New TLDs

Sponsored byRadix