Handicapping New DNS Extensions and Applications
by Cricket Liu01/11/2007
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.
SPF
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.
IPv6
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.
IDN
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.
ENUM
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.
DNSSEC
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.
Summary
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.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 4 of 4.
-
DNSSEC: insecure and illegal to use
2007-01-16 06:03:20 dwheeler [Reply | View]
The fundamental problem with DNSSEC is that its original design is insecure - so much so that in many countries it's illegal to use DNSSEC. DNSSEC's original design only worried about authentication of integrity. That's fine, but its design required that ALL DNS data had to be public (i.e., it forbid data confidentiality). This was an explicit bad decision years ago by the DNSSEC developers. The problem was, the people who deploy DNS have generally agreed that you should NEVER expose all DNS data to the world - indeed, they view confidentiality as really important, MORE important than authentication. Check out any book on DNS, and you'll read all about how to deploy DNS while ensuring that most data doesn't reach the outside. DNSSEC breaks that. The DNSSEC developers ignored this issue, claiming that that it didn't matter, until the Europeans explained to them that it would be ILLEGAL to deploy current DNSSEC due to European privacy laws. Non-European governments and most large companies also decided that they didn't want to hand that information to attackers. DNS security is still really needed, but no one should be surprised that a fundamentally flawed protocol isn't implemented widely. The lack of tools is simply an outgrowth, not a cause -- nobody wants to deploy DNSSEC as it is, so there's no reason to build nicer tools for it. There's hope; the fundamental flaw in DNSSEC (enumeration) is correctable, and improvements like NSEC3 may finally make DNSSEC actually useful. I think there's a reasonable chance that DNSSEC will be widely deployed, once its fatal flaws are corrected. See http://en.wikipedia.org/wiki/DNSSEC for more information.
-
SPF is broken
2007-01-12 15:16:47 elanthis [Reply | View]
There's a perfectly good reason to not use SPF. It breaks many, many valid mail setups. For example, any system that does any kind of mail forwarding.
Email is not a direct communication link. Email does not go directly from the sender's SMTP agent to the receiver's SMTP agent. It can, and often does, go through quite a few intermediary hosts. Some of those are internal network hosts which should be exempt from SPF, and some of those could be general "wild 'net" hosts... which also need to be exempt from SPF. Except there's no way to do that last bit.
DomainKeys avoids that problem. DomainKeys was designed with a little bit of a clue as to how the Internet and email/SMTP works. With DomainKeys, it doesn't matter which hosts a message goes through, as it doesn't try to do hostname/IP address validations like SPF. Instead, all it does is guarantee that the message has the correct authorization for the From: address domain.
There are issues with DomainKeys with any service that _alters_ mail, such as many mailing lists, that will cause false negatives like SPF. These, at least, have a possible means of being fixed (most mail list software needs only a slight config tweak to make work with DomainKeys) unlike SPF's issues.
When it comes to mail, guys, you can't just evaluate it form a "good DNS usage" standpoint. Mail also uses SMTP. From an SMTP standpoint, SPF is horrendously broken. -
SPF is broken
2007-05-27 23:23:43 ale2006 [Reply | View]
I cannot figure out what's a "wild 'net" host. Therefore it is absolutely not clear to me why it should be exempt from SPF.
SMTP provided a Return-Path for bounces assuming users to be polite enough to set it to the real address of the sender. Since spammers are not polite, SPF corrects just that. What's broken?
What remains overlooked by SPF proponents is that although there is a limit of 10 SPF mechanisms, each mechanism may invoke 10 queries targeting a victim for a total of 100 transactions per name resolved. In addition, the local-part macro can be employed to randomize subsequent queries where none of the spammers resources are then consumed. This means any and all such traffic represents an infinite gain DNS amplification attack.
SPF libraries represent a new and growing hazard.