Handicapping New DNS Extensions and Applicationsby Cricket Liu
Back in May, Paul Vixie and I presented a webinar in which we discussed five new extensions to and uses of the Domain Name System: the Sender Policy Framework (SPF), IPv6 support, Internationalized Domain Names, ENUM, and the DNS Security Extensions. These subjects represented most of the new topics in the fifth edition of O'Reilly's DNS and BIND, released in April 2006. At the end of the webinar, we gave our assessment of the future of each of these technologies. Six months later, after conducting a survey of the Internet's namespace, consulting experts, and generally keeping an ear to the ground, it's already time to update our original assessment.
Perhaps the best news comes from SPF. SPF is a means of storing data that authorizes certain mail servers to send email from a domain name. DNS administrators authorize mail servers to send email from a particular domain name by adding specially formatted TXT records to that domain name. For example, to authorize the hosts cerberus.infoblox.com and daneel.infoblox.com to send mail from infoblox.com email addresses, the Infoblox DNS administrator could add this TXT record to the infoblox.com zone:
infoblox.com. IN TXT "v=spf1 +a:cerberus.infoblox.com +a:daneel.infoblox.com -all"
Mail servers that support SPF will check this TXT record when they receive email from infoblox.com addresses. If the mail sender sending the infoblox.com email isn't one described in the record, the server can subject the email to additional checking.
We suggested in the webinar that there was no reason not to implement SPF: it's easy to set up, and there are no disadvantages to publishing a list of mail servers that are allowed to send email from your domain names. In our recent survey of the Internet's namespace (PDF), testing about 2 million subzones of .com and .net, we found that roughly 5 percent of those zones published SPF information. That's an impressive figure, given that a DNS administrator needs to take the initiative to learn at least a little about SPF and then manually enter the TXT records that enumerate his mail servers. With a little help--the inclusion of SPF wizards in DNS management products to make publishing SPF data simpler, for example--we believe the adoption rate could see double digits. Given that some proportion of the 2 million zones we sampled don't send email at all, an adoption rate over 10 percent could make it possible to authenticate a large share of inbound email.
Another email authentication mechanism that's gaining traction is Domain Keys Identified Mail (DKIM). DKIM is the product of the merger of Yahoo!'s DomainKeys and Cisco's Identified Internet Mail specifications, and while we neglected to cover it in the webinar, it shows a lot of promise. SPF operates at the level of domain names and hence can only tell you, for example, whether the mail server that sent you my mail is authorized to send mail from infoblox.com email addresses. DKIM, on the other hand, can tell you whether a particular message actually came from for instance, and can also prove that the message wasn't modified since it was sent.
The same survey also looked at IPv6 adoption. We checked to see how many of the subzones of .com and .net had at least one name server with an IPv6 address. Now, that result is probably lower than it should be; organizations in .com and .net are disproportionately North American, and adoption of IPv6 in North America has been slower than in other parts of the world, where address space isn't as abundant. Also, many registrars for the .com and .net zones don't support specifying an IPv6 address for a name server, so an administrator running a name server that speaks IPv6 often can't even get the full benefit of that connectivity.
Nonetheless, we found that 0.2 percent of the zones under .com and .net have at least one name server with an IPv6 address. That's an impressive number given the circumstances. Had we been able to sample the children of a country code top-level domain in Europe or particularly Asia, the proportion surely would have been higher.
When covering Internationalized Domain Names, we mentioned that the forthcoming Internet Explorer 7 would include support for IDNs. IE 7 was released, of course, back in October, and allows you to enter domain names that include non-ASCII characters. Per the IDN specs, labels of domain names that include non-ASCII characters are translated into ASCII-armored equivalents before being passed to a DNS resolver. With IE 7, almost all modern browsers now provide support for IDNs, including Firefox and Opera.
Many top-level domains now allow registration of subdomains whose names include non-ASCII characters--though most restrict the allowable characters to a small subset of Unicode. For example, the German DENIC publishes a list of those Unicode characters it allows Other registries, such as the .org top-level domain's restrict characters by language. The ITU publishes a list of those country code top-level domains and generic top-level domains that support IDNs.
According to Richard Shockey, co-chair of the IETF's ENUM Working Group, adoption of ENUM is huge. However, it's not the traditional variety of ENUM--mapping telephone numbers to URIs using the e164.arpa domain--that seems to be taking off. Instead, carriers are adopting ENUM as a next-generation signaling system to facilitate direct interconnection of their networks, without using the public switched telephone network or the Internet as a transit network.
Traditional ENUM is mired in conflicts over ownership of subdomains of the e164.arpa namespace and concerns about publishing what amounts to private, personal contact information where it is accessible by anyone on the Internet.
The laggard among these technologies is the DNS Security Extensions (DNSSEC). While providing source authentication and a guarantee of data integrity in DNS is enormously valuable, DNSSEC just isn't taking off. Our survey showed a paltry 16 signed zones among the 2 million sampled. The DNSSEC Monitoring Project reports only 279 signed zones Internet-wide.
There are a several reasons DNSSEC's adoption has been so slow. It's hard to administer a signed zone. The only tools widely available for generating keys and signing zones are command-line-based and not particularly user-friendly. Documentation of common procedures (for example, key rollover) is scarce. Signed zones place a greater burden on both recursive and authoritative name servers, increasing the size of zones and responses as well as the computational load involved in recursive query processing.
DNSSEC is also a moving target. The standard has already undergone one overhaul, and it may face another revision to address concerns about a new type of record DNSSEC introduces, the NSEC record. If the IETF undertakes that change, we'll have to wait months for the corresponding modifications of the few name server implementations that bother to support DNSSEC at all.
If DNSSEC is ever to fulfill its mission of helping to secure the Internet's DNS namespace, it needs a swift kick in the pants. This might come in the form of government regulation, such as a NIST requirement that U.S. government agencies sign their Internet-facing zones, or a mandate that contractors working with the U.S. Department of Defense do the same. DNSSEC also needs serious work in the area of usability. Most administrators would find managing a signed zone with the existing tools and available documentation very challenging.
Still, with four new developments in DNS advancing--some fairly rapidly--we DNS administrators have plenty to keep us busy. A prudent administrator would do well to stay on top of these technologies by reading the relevant RFCs and documentation and by following the related newsgroups. And, of course, by reading the fifth edition of DNS and BIND, which addresses each of these topics in-depth.
My thanks to Matt Larson of VeriSign and Richard Shockey of NeuStar for their contributions to this article.
Cricket Liu is the co-author of all of O'Reilly's Nutshell Handbooks on the Domain Name System, "DNS and BIND," "DNS on Windows NT," "DNS on Windows 2000," "DNS on Windows Server 2003," and the "DNS & BIND Cookbook," and was the principal author of Managing Internet Information Services.
Return to ONLamp.com.