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.