attracting revenue) include the idea of triggering the remapping logic only if the query domain begins with WWW.— but as far as I know there are a lot of typographical errors beginning WW., or ending with .CM, so I do not hold out a lot of hope for it long term. Too much money is involved, and nobody wants to leave it on the table (where, in this case, it belongs).

Standard Bad Practices

There is at the time of this writing an IETF draft (think: proto-RFC) on the recommended configuration and use of DNS redirect by service providers ( http://tools.ietf.org/html/draft-livin- good-dns-redirect-00). The goal of this document is to present some rules for how DNS lies should be delivered in order to give all the vendors and operators in this growing market a common frame of service. Some Luddites may feel that the “standard best practice” in this area is simply not to do it at all, but this being unrealistic, we now face standards action. As a standard feature of DNS technology we can expect a day to come when all DNS services are delivered this way and our kids think of end-to-end DNS the way they think of eight-track tapes.

This document makes a substantial contribution to the debate around this feature area by suggesting that opt-out for this service should be a network layer attribute (in other words, associated with one’s Ethernet [MAC] address or equipment port number) and not a transport layer attribute. Noting

that as with any other kind of information, spam opt-out is not as good for the economy as opt-in, it’s valuable to the debate that this IETF draft’s authors have said that Web cookies aren’t good enough. Others may disagree but at least this point is now on the table. This document also talks about “legally mandated” DNS redirection, which is exactly the nightmare it sounds like it is and that we can all hope becomes a historical curiosity as rapidly as possible.

The absolutely best part of this IETF draft is Section 10—DNSSEC Considerations—that ends as follows: “So the only case where DNS security extensions cause problems for DNS Redirect is with a validating stub resolver. This case doesn’t have widespread deployment now and could be mitigated by using trust anchor, configured by the applicable ISP or DNS ASP, that could be used to sign the redirected answers. As noted above in Section 9. 7, such improper redirection of valid responses may also cause DNSSEC trust verification problems.

 

a Rescue Being thought of Fifteen years ago a bunch of ivory tower theoreticians got together at IETF and said, “Let’s secure DNS.” The threat model has evolved over time, and now this set of protocol enhancements (DNSSEC) is more or less ready for deployment and more or less allows for the possibility that DNS liars will be caught and ignored. Noting that DNSSEC has taken too long and is a com-mittee-based horror in its inelegance

Looking for CaCm? Should an inquiry inadvertently ask for cacm.com rather than cacm.org, the response will be redirected to this advertising scene as enabled by nxDomain remapping.

and complexity, here’s how it’s supposed to work and how it may help curtail the current market in DNS lies.

In DNS, data producers are the authoritative name servers, each of which is the delegated authority for one or more zones. For today, think of a DNS zone as everything at or below a certain name, so, for example, www.google. com is in the Google.com zone. DNSSEC allows these zones to be signed and verified using public-key cryptography. The private (signing) key is used by the editor of the zone to generate signature records for each set of real records. The public key is used by recursive name servers to verify that the data they receive was signed by the holder of the corresponding private key. Public (verification) keys are published using DNS itself, by including each zone’s key in the zone’s parent zone—so the public key for the Google.com zone is published in the COM zone and so on. I’m deliberately skipping a long and unpleasant story about where the public key for COM is supposed to be published, since it’s not germane to this article.

In theory, an end-system owner who does not like being lied to can work cooperatively with zone editors who don’t like their zones getting lied about if each of them deploys DNSSEC. An application that is supposed to receive an NXDOMAIN but that today receives a pointer to an advertising server would in a DNSSEC world receive a “ signature not present” error. This would be an error because DNSSEC has a way to inform a validator that a signature should have been present. Note that in the vast majority of cases zone editors don’t care whether their zones are being lied about, and, therefore, DNSSEC will remain silent most of the time. Consider also that this was not the original DNSSEC threat model; we really thought we had to stop on-the-wire corruption such as that discovered by Dan Kaminsky in 2008, and the idea of stopping in-the-middlebox corruption such as NXDOMAIN remapping really is just gravy.

DNSSEC will complicate life for CDN providers using Stupid DNS Tricks, but it won’t end that war since it’s still possible to sign every policy-based answer and keep all the answers and signatures available, and still send different