Home / Blogs

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

John Levine

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. More blog posts from John Levine can also be read here.

Related topics: DNS


Don't miss a thing – get the Weekly Wrap delivered to your inbox.


To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Dig Deeper

Mobile Internet

Sponsored by Afilias Mobile & Web Services

IP Addressing

Sponsored by Avenue4 LLC

DNS Security

Sponsored by Afilias


Sponsored by Verisign

Promoted Posts

Buying or Selling IPv4 Addresses?

Watch this video to discover how ACCELR/8, a transformative trading platform developed by industry veterans Marc Lindsey and Janine Goodman, enables organizations to buy or sell IPv4 blocks as small as /20s. more»

Industry Updates – Sponsored Posts

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Don't Gamble With Your DNS

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

How Savvy DDoS Attackers Are Using DNSSEC Against Us

Radix Adds Dyn as a DNS Service Provider

Dyn Partners with the Internet Systems Consortium to Host Global F-Root Nameservers

Is Your TLD Threat Mitigation Strategy up to Scratch?

Domain Management Handbook from MarkMonitor

What Holds Firms Back from Choosing Cloud-Based External DNS?

Computerworld Names Afilias' Ram Mohan a Premier 100 Technology Leader

Protect Your Privacy - Opt Out of Public DNS Data Collection

Measuring DNS Performance for the User Experience

Introducing Verisign Public DNS: A Free Recursive DNS Service That Respects Your Privacy

Internet Grows to 296 Million Domain Names in Q2 2015

Protect Your Network From BYOD Malware Threats With The Verisign DNS Firewall

Introducing the Verisign DNS Firewall

Verisign Named to the Online Trust Alliance's 2015 Honor Roll

3 Key Steps for SMBs to Protect Their Website and Critical Internet Services

Key Considerations for Selecting a Managed DNS Provider