What DNS Is Not

Paul Vixie, Internet Systems Consortium

DNS is many things to many people—perhaps too many things to too many people.

DNS (Domain Name System) is a hierarchical, distributed, autonomous, reliable database. The first and only of its kind, it offers realtime performance levels to a global audience with global contributors. Every TCP/IP traffic flow including every World Wide Web page view begins with at least one DNS transaction. DNS is, in a word, glorious.

To underline our understanding of what DNS is, we must differentiate it from what it is not. The Internet economy rewards unlimited creativity in the monetization of human action, and fairly often this takes the form of some kind of intermediation. For DNS, monetized intermediation means lying. The innovators who bring us such monetized intermediation do not call what they sell "lies," but in this case it walks like a duck and quacks like one, too.

Not all misuses of DNS take the form of lying. Another frequently seen abuse is to treat DNS as a directory system, which it is not. In a directory system one can ask approximate questions and get approximate answers. Think of a printed telephone white pages directory here: users often find what they want in the printed directory not by knowing exactly what the listing is but by starting with a guess or a general idea. DNS has nothing like that: all questions and all answers are exact. But DNS has at least two mechanisms that can be misused to support approximate matching at some considerable cost to everybody else, and a lot of that goes on.

Stupid DNS Tricks

The first widespread form of DNS lie was to treat DNS lookups as mapping requests. CDNs (content distribution networks) such as Akamai and Web optimizer products such as Cisco Distributed Director treat incoming DNS lookups as opportunities to direct the activities of Web browsers. Using the IP source address of a DNS request, these products and services try to guess the proximity of the requester to each of many replicated content servers. Based on the measured load of each content server's system and network, and on an estimate of each content server's proximity to that requester, a DNS response is crafted to direct that requester to the closest or best content server for that URI domain.

Problems abound from this approach, but none affects the CDN operator's revenue. First and foremost it is necessary to defeat or severely limit caching and reuse of this policy-based data ("DNS lies"). Caching and reuse, which once were considered essential to the performance and scalability of DNS, would allow a policy-based response intended for requester A also to be seen by requester B, which might not otherwise receive the same answer—for example, when server loads have changed and there's a new balance. The effects of this noncaching are a higher DNS request rate (perhaps leading to higher revenue for CDNs that charge by the transaction) and more network load for access-side networks and a slightly higher floor for average transaction time.

Furthermore, it has never been wise to assume that a DNS request's IP source address gives any hint of an end-system Web browser's network location. This is because DNS requests heard by a CDN come from recursive DNS servers as a result of cache misses; they do not come from end systems themselves. Some ISPs regionalize their recursive name servers, allowing CDNs to encode rules improving the quality of their estimates. Many recursive name servers are per-country or per-continent or even per-hemisphere, however, so it's always necessary for a CDN to deploy well-connected supernodes, and these always end up hearing a lot of out-of-region requests.

The primary benefit of a CDN is the same as gimmick-free outsourcing: it gives a content owner somebody to sue if things don't go well. That DNS system performance and stability has to pay the price for such liability shielding is at best unfortunate. Given that a CDN still requires supernodes that will hear many out-of-region requests, a gimmick-free approach here would be to answer DNS truthfully and let existing pseudorandom distribution mechanisms do their work. Noting that there is no patent on the existing pseudorandomization technologies and that nobody ever got fired for buying a CDN, we can expect to see ever-more content distributed this way in the decades to come.

NXDOMAIN Remapping

Fairly often, as in millions of times per second worldwide, somebody looks up a domain name in DNS that isn't there. Maybe this is a user at a Web browser making a typographical error, or maybe there's a broken link on a Web site, or maybe a hardware or software error is causing nonexistent names to go into DNS requests. One way or another, the answer is generally supposed to be NXDOMAIN (sometimes written as RCODE=3). These negative answers are cacheable, as is any other kind of DNS information, since DNS is designed to express truth, not policy. A network application (perhaps a Web browser, or mail server, or indeed anything at all that uses TCP/IP flows to do its business) that gets back one of these negative responses is supposed to treat it as an error and reject its own underlying work item that led to this lookup. For a Web browser, rejection takes the form of an "error page." For a mail server, rejection takes the place of "bounced e-mail." Every TCP/IP application, large or small, new or old, knows how to cope with NXDOMAIN.

The World Wide Web has changed the rules. Though the Web is young—and though the Internet was here before the Web and will be here after the Web and is much larger than the Web—the fact remains that the Web is what end users are looking at. Advertisers have a whole language to describe the value of end users, with words such as "impressions," "click-throughs," and "eyeballs." Why on earth, these advertisers ask, would you ever send back an NXDOMAIN if an impression was possible? So it is, increasingly, that in place of the NXDOMAIN your application knows how to handle, if you ask for a name that does not exist, you'll get a positive (deceptive; false; lying) answer that your application also knows how to handle.

For example, if I ask my own recursive name server for a name that does not exist, it will tell me NXDOMAIN. If I ask OpenDNS's recursive name server for a name that does not exist, it will send me a NOERROR response with an answer pointing at an advertising server. Note that I'm using OpenDNS as a convenient example; it did not invent this technique. Indeed, Nominum and other DNS vendors now sell an add-on to their recursive name service products to allow any ISP in the world to do this, and a growing number of ISPs are doing it. Why so many? Simply because whoever remaps these NXDOMAIN responses gets the impression revenue. There are unverified claims that some ISPs are blocking access to OpenDNS and/or all non-ISP name servers in order to force their customers to use the ISP's own name server. I say unverified, but I find the claims credible—ISPs have wafer-thin margins and if they see this kind of manna going out the door, they can't just let it happen.

To demonstrate the extreme desire to capture this revenue, a true story: a few years ago VeriSign, which operates the .COM domain under contract to ICANN (Internet Corporation for Assigned Names and Numbers), added a "wild card" to the top of the .COM zone (*.COM) so that its authoritative name servers would no longer generate NXDOMAIN responses. Instead they generated responses containing the address of SiteFinder's Web site—an advertising server. The outcry from the community (including your humble narrator) was loud and long, and before ICANN had a chance to file a lawsuit to stop this nonsense, many people had patched their recursive name servers to remap any response from a .COM name server that was not a delegation (for example, telling how to find the GOOGLE.COM name servers) back into an NXDOMAIN. Some ISPs put logic into their policy-based routers to turn SiteFinder responses into pointers to the ISP's own advertising server instead.

Damage Control

NXDOMAIN wasn't designed to be a revenue hook—many applications depend on accurate error signals from DNS. For example, consider the "same origin trust model" used for Web cookies. If you're holding a cookie for GOOGLE.COM and you can be fooled into following a link to KJHSDFKJHSKJHMJHER.GOOGLE.COM, and the resulting NXDOMAIN response is remapped into a positive answer to some advertising server, then you're going to send your cookie to that advertising server when you send your HTTP GET request there. Not such a bad thing for a GOOGLE.COM cookie, but a real problem for a BANKOFAMERICA.COM cookie. (Thanks to Dan Kaminsky for telling me about the "same origin trust model" problem.)

Remapping could also cause e-mail to be captured if an MX (mail exchanger) request is captured in this way. Many NXDOMAIN remappers try to avoid this by triggering only on A (address) requests, but to make this work they have to turn off caching, since NXDOMAINs are not type specific and since an SMTP initiator will fall back to type=A if it gets no answer from type=MX. Similar protections (designed to keep lawsuits away while still 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. 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 which 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), which 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 committee-based horror in its inelegance 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 doesn't 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 answers to the same question based on requester identity and policy, and have the signatures all be perfectly valid.

DNSSEC will also complicate life for sysadmins and application developers. We (ISC—the BIND people) are doing what we can to improve on that in BIND9 9.7 (due out by December 2009), and there are plenty of other service and technology providers in the space as well. The killer app for DNSSEC will be a Web browser and Web server that can authenticate to each other without using X.509 (volunteers are hereby encouraged to get together and try to make that happen).

Directory Services

Browser implementers including Microsoft and Mozilla have begun doing DNS queries while collecting URIs from their graphical front end in order to do fancy "auto-completion." This means that during the typing time of a URI such as http://www.cnn.com/, the browser will have asked questions such as W, WW, WWW, WWW.C, WWW.CN, WWW.CNN, and so on. It's not quite that bad, since the browsers have a precompiled idea of what the top-level domains are. They won't actually ask for WWW.C, for example, but they are now asking for WWW.CN, which is in China, and WWW.CNN.CO, which is in Colombia.

Although one simple-sounding solution is for Microsoft and Firefox to buy some name-server hardware and network links for China and Colombia (and no doubt many other affected top-level domain operators), that won't stop the information leak or remove this stupid and useless traffic from the rest of the network. Since the truly best solution is, as usual, stop doing this stupid thing—and we all know that isn't going to happen—perhaps this behavior can be made optional, and then we can just argue about what the default (opt-in vs. opt-out) should be. This is the first time in the history of DNS that someone has used it prospectively, to find out if what has been typed is or isn't a valid domain name, in order to support something like auto-completion. As in so many other novel uses of DNS, this is not what it was designed for.

Had DNS been designed with this kind of thing in mind, one of the ways we would be able to tell is that domain names would be written from highest- to lowest-order term (COM.CNN.WWW). This would allow partial name completion just as happens in graphical file system browsers. Absent a complete redesign, which won't happen in our lifetime because of the size and usefulness of the installed base, all we can do is ask browser implementers to be smarter and prepare for more DNS traffic on our networks.

Conclusion

What DNS is not is a mapping service or a mechanism for delivering policy-based information. DNS was designed to express facts, not policies. Because it works so well and is ubiquitous, however, it's all too common for entrepreneurs to see it as a greenfield opportunity. Those of us who work to implement, enhance, and deploy DNS and to keep the global system of name servers operating will continue to find ways to keep the thing alive even with all these innovators taking their little bites out of it.

These are unhappy observations and there is no solution within reach because of the extraordinary size of the installed base. The tasks where DNS falls short, but that people nevertheless want it to be able to do, are in most cases fundamental to the current design. What will play out now will be an information war in which innovators who muscle in early enough and gain enough market share will prevent others from doing likewise—DNS lies vs. DNS security is only one example.
Q

LOVE IT, HATE IT? LET US KNOW

feedback@queue.acm.org

PAUL VIXIE is president of Internet Systems Consortium (ISC), a nonprofit company that operates the DNS F root name server and that publishes the BIND software used by 80% of the Internet for DNS publication. He is also chairman of American Registry for Internet Numbers (ARIN), a nonprofit company that allocates Internet number resources in the North American and Caribbean regions. Previously, Mr. Vixie was a founder and president of PAIX, the first neutral commercial Internet exchange; SVP/CTO of AboveNet; and founder of the first anti-spam company (MAPS LLC) in 1996.

Originally published in Queue vol. 7, no. 10—
see this item in the ACM Digital Library

Comments

John Stracke | Fri, 06 Nov 2009 14:27:34 UTC

"a higher DNS request rate (perhaps leading to higher revenue for CDNs that charge by the transaction)" -- I used to work on Akamai's DNS server, and I can assure you we did not consider DNS requests to be a revenue stream.  In fact, if anybody had suggested trying to increase DNS traffic, we would've laughed at them, because we were already working hard to keep up with the traffic we had.

(I can agree with you on the rest of it, though.  I never did get comfortable with the Akamai attitude that DNS was just another request/response protocol, which we could manipulate to get the client to do what we wanted.)

Alex Besogonov | Sat, 07 Nov 2009 20:00:26 UTC

I'm curious, why do you hate CDNs so much? 

They solve a real problem - requirement to push data as fast as possible from a source as close to the consumer as feasible. Like not downloading file from a server in Japan to a node in Germany.

It's not like there's a lot more alternatives for region-based DNS. You can also do Stupid BGP Routing Tricks for load-ballancing, but is it much better? It's also possible to do load balancing on upper levels (like, using HTTP redirects to a regional server) but it has its own drawbacks.

Bill Bogstad | Sat, 07 Nov 2009 20:59:25 UTC

As a general rule, your suggestion that CDNs' unusual usage of DNS increases transaction time MIGHT be true for the DNS portion of the conversation.   (Some CDNs regionalize DNS by using sub-domains which is why I say MIGHT.) However, I think you are paying way to much attention to DNS vs. all associated network traffic.  Even you start this article by pointing out that almost every DNS transaction results in another TCP transaction.  That TCP transaction typically takes many orders of magnitude more time and bandwidth to complete then even an uncached CDN based DNS transaction.  Regionalizing that TCP transaction saves way more time/bandwidth-miles then the more expensive DNS transaction costs.  At least that's what figures out of Internet performance companies like Keynote Systems seem to indicate.
As for using pseudo-random methods (DNS round robin?), my (now dated) experience is that it doesn't even come close to working as well as active load management.

cs | Sat, 07 Nov 2009 21:05:39 UTC

As far as policy goes, wouldn't views in BIND be considered policy?

Blake | Sat, 07 Nov 2009 21:07:36 UTC

"Stupid BGP Routing Tricks" ?

Anycast rouing has been in use for a very long time and has proven to be a sound way of handling client traffic with the closest servers.

Notably by the root-zone DNS servers...

Elin F. | Sat, 07 Nov 2009 21:10:39 UTC

Another problem with using DNS this way is it also affects split-tunnel VPN's which will first check your ISP DNS before checking with your VPN's DNS to resolve an internal address. Very frustrating to deal with as the way to opt out is different by ISP.

mr | Sat, 07 Nov 2009 21:42:43 UTC

You have an interesting view point.  I guess your point is that DNS should only be used for what it was originally intended for in a strict way.

I believe that innovating and figuring out other uses for a wide variety of things makes sense not only for DNS, but for tons of other items.  Can you imagine where the world would be if inventions were only used in the limited way that the inventor intended?  Ouch!

Gaige B Paulsen | Sat, 07 Nov 2009 22:06:11 UTC

Re: CDN's. I think that what Paul is getting at here is not a dislike of CDNs, but an inappropriateness of using DNS tricks to try and determine where data should be coming from.

Although it's true that DNS has been used (misused?) to do some pretty amazing things, it has also been used as a crutch for shady operators to do things like watch people's traffic, steal information, redirect users away from legitimate sites, and generally make determining where packets are going more difficult and less reproducible than would otherwise be the case.

I'm a big fan of the free market, but a free market works best when costs are associated with the revenue they generate. In the case of DNS, the costs are disproportionately borne by organizations other than those who are generating revenue. Let's take CDN's for example:

If you are a CDN and you couldn't try and switch around DNS, how could you achieve the same basic effect? You could have a large system of front ends somewhere that would accept incoming HTTP connections and use 301 redirects to point the user's browser at a 'more appropriate' local server. This way, your determination would be based on the actual origin of the traffic and DNS results could be relatively static for your content. Might not be your favorite solution, since it would cost you money and you'd have to figure out how to make sure those servers don't get inundated, but it certainly would work, and arguably be more effective. And, guess what, when your traffic goes up, you need to provision more servers, but the DNS information remains cached, so the intermediate DNS resolvers don't have to do any more work.

For those of you who missed the point and thought that Paul's complaint here was with using CDNs, please go back and re-read. The complaint is with using DNS determine where the CDNs should be sending their traffic.

Anthony Bryan | Sat, 07 Nov 2009 22:12:31 UTC

We're working on solutions to CDN providers using Stupid DNS Tricks with the Link header in 
http://tools.ietf.org/html/draft-bryan-metalinkhttp

   Link: ; rel="duplicate"; pri=1; geo="gb"

Jeff | Sun, 08 Nov 2009 00:13:12 UTC

Interesting how every single post here shows that the technical discussion above has escaped them, and all the commenter sees is an attack on their own revenue model or activity.  Some quite obviously ignore or intentionally misrepresent the arguments presented... lying indeed!

Matt Taggart | Sun, 08 Nov 2009 01:51:08 UTC

I wonder what vixie thinks of using DNS infrastructure for RBLs. Is this something "DNS is not"?

Director of Stunt | Sun, 08 Nov 2009 04:56:47 UTC

"Cisco Distributed Director" ? That was end of life'd around 2002. Vixie, get with the program.

Also, I believe Keyboard Cat was summoned at your NANOG keynote (good job with the 6 point font on a giant screen). You and Randy should move on. The "you kids get off my lawn" thing is getting a bit old.

Director of Front | Sun, 08 Nov 2009 04:58:54 UTC

Also, how come ISC secretly purports itself to be "infrastructure" to the Internet, yet gives free transit to archive.org? Yet, archive.org besides its obvious web site, seems to have a ton of warez boxes sitting behind it. So, peering with ISC seems to serve some sort of an agenda.

Paul Wall | Sun, 08 Nov 2009 08:17:21 UTC

DNS is a tool, not your personal protocol. It has grown to encompass tasks that it was not originally designed for, and this is a good thing, not a misuse.

Heikki | Sun, 08 Nov 2009 11:16:54 UTC

So what is the alternative to the DNS hack in the case of CDN? 

HTTP redirects (including the already mentioned metalink/Http) simply do not work for everything because that is a per request thing. Let's say you have 100 1kB images on your web page. Were you using HTTP redirects, you would have to make 100 of them, each already as big as the resource it self. Not very efficient and adds a lot of latency to page loading.

The only good solution is to get different clients to make their requests directly to different sites. The only way to do this is that a) they are given a different URL in the first place to load the content from or b) the DNS gives a different server IP address to each client or c) the IP address, given by the DNS, routes to a different for each client. 

Solution 'a' is what we had a few years back (www1.myservice.com, www2.myservice.com,etc). The reason we don't want it is that it breaks URLs (the URL starts to contain load-balancing state). Alternative 'c' would be cool, but AFAIK very hard to implement since it requires control over the way ISPs route. That leaves us with what's currently being done, alternative 'b', the DNS hack.

So Paul, before saying a working solution is a solution from hell please give your 5c on how you would do it.

Disclaimer: I have no affiliation with any CDN.

Heikki

Daniel Torrey | Sun, 08 Nov 2009 11:53:03 UTC

"They solve a real problem - requirement to push data as fast as possible from a source as close to the consumer as feasible."

Wrong.  There may be a requirement to push the data as fast as possible, but source proximity to the consumer isn't a requirement at all, unless you believe that the internet is a bunch of pneumatic tubes.  

A fast server on a fat pipe in Japan is much more likely to meet the "fast as possible" requirement than a slow server down the block from the consumer.

Myatu | Sun, 08 Nov 2009 13:31:44 UTC

Apart from the CDN paragraph, I agree with what's being said. Especially when it comes to NXDOMAIN mappings. However, there's no way to enforce it in its current form as the DNS system is open (RFC or not).

APK | Sun, 08 Nov 2009 23:18:57 UTC

Mr. V:

Your thoughts on this are appreciated (since it is somewhat related): 

Question, on the use of 0 as a domainname/hostname blocking "ip address":

The use of "0" (zero), as a "blocking IP Address" in a HOSTS file, vs. the larger & slower 0.0.0.0 or worse yet, the std. "loopback adapter" address of 127.0.0.1, produces far faster read & smaller HOSTS files on disk, than do those that use the larger & slower 0.0.0.0 or worst of all, the 127.0.0.1... 

Yes, or no will do. 

Thanks. 

APK

P.S.=> Microsoft first introduced the smaller & faster 0 blocking address for a HOSTS file in a service pack for Windows 2000 (not its original version model build, which @ best, could only do as well as a 0.0.0.0, vs. 127.0.0.1), and? 

Well, MS left it operating with 0 as a legit IP address to block known bad servers or sites with (ping'ing such a blocked site using 0 prefixing the domain/hostsname, returns 0.0.0.0 on Windows 2000/XP/Server 2003 & did even with VISTA for a long while) even into VISTA until 12/09/2008 on that "Microsoft Patch Tuesday", which removed it... 

Personally - Well... I don't get it, like "why make a good thing not as good, in other words?"

Hey - If there is a GOOD SOLID LOGICAL TECHNICAL REASON? Then, I'd like to know it.

OR, even maybe "here are the tradeoffs we made and WHY" or "We will issue a patch" etc. et al - instead of evasions... I say that, because that's all I've seen & directly from MS themselves, on their blogs or forums etc. or other forums online.

So, that said, I'd like your thoughts on it all, as it is name resolution related (many folks like myself use HOSTS files for both added security AND FAR MORE SPEED online, & I need only point to mvps.org or SpyBot "search & destroy" users, & many more such as these HOSTS files @ WIKIPEDIA -> http://en.wikipedia.org/wiki/Hosts_file  )  apk

Stuart Gathman | Mon, 09 Nov 2009 03:36:55 UTC

I've found that ISP resolvers are so full of cruft that they are useless.   They ignore TTLs, so that users don't see timely updates to their own company DNS.  Users are unable to access essential business sites because the DNS redirection is screwed up at their ISP.  Sometimes NXDOMAIN is broken (lied about and redirected) - screwing up checks like SPF.  Our ISPs were very slow patching the cache poisoning vulnerability.  As a result, I always install a caching name server as part of every site.  It wastes DNS traffic that might have been cached on the ISP server - but it works.  I dread the day when ISPs start altering DNS packets not directed at their servers.

Boris Zbarsky | Mon, 09 Nov 2009 14:59:09 UTC

Paul, I really wish you'd done your fact-checking before accusing people of doing stupid things.  Mozilla (whether Firefox or Seamonkey) does not now do and has never done any DNS queries based on the string in the URL bar until the user hits enter.  At that point, of course, the user-typed string is treated as a URL and DNS resolution does have to be performed to fetch the data.  I'd be very interested in finding out what gave you the idea that it performs such DNS queries.

Neal Murphy | Tue, 10 Nov 2009 07:31:58 UTC

Perhaps one solution is to require DNS providers to include in the response whether the returned IP address actually matches the domainname sent or if it is guess because the sent domainname does not exist. Then let the end user decide if he wants to allow such misinformation, convenient though it may be, to get through.

Perhaps another solution is to create one's own root server and maintain a 'private' network that never references the 'official' internet DNS services. DNS on the world-wide internet can only be like a carnie barker doing his best to get you to visit *his* booth or attraction, despite everyone's best efforts to the contrary. So set up your own DNS DB with your own TLDs and include from the 'standard' DNS DB only those domains you want to access. Be on the internet, but don't be part of the 'InterNet".

Terri | Tue, 10 Nov 2009 13:47:46 UTC

If we don't push things to their limits we will never evolve.  Closing ones mind to innovation is an invitation for extinction.

Dave Piscitello | Tue, 10 Nov 2009 18:22:33 UTC

Compliments to Mr. Vixie for putting a broad set of DNS uses into context and exposing the misuses with clarity and conviction.

Additional reading on issues and concerns related to misuses of DNS can be found in an ICANN SSAC report, SAC 032: Preliminary Report on DNS Response Modification (20 June 2008), found at http://www.icann.org/en/committees/security/sac032.pdf

Nosce Te Ipsum | Wed, 11 Nov 2009 04:41:09 UTC

Would this rant be authored by the very same individual who claimed that anycast DNS requests were a veritable abomination?  [I'm paraphrasing, as I wasn't privy to the actual conversation.]  As I recall, the only root server (at the time) that DID support anycast, was in fact the only root server that was still operational during the DDOS that occurred, thereby obviating why anycast was in fact a good idea.  I would submit that in the pantheon of galatically stupid presumptions or statements, that would be right up there with IBM's projection of the market for personal computers.

With regard to validly signing geographical DNS requests, and other so called lies, this issue in particular is an issue that actually requires applying some massively scalable signature generation capabilities for DNSSEC in order to make it viable for large variant response zones.  In that context, would not such a mechanism ultimately be a positive for the adoption of DNSSEC as a whole, or is profiting from a differentiation in service capabilities some how a bastardizing of the internet and DNS in general?

Josh Goodall | Wed, 11 Nov 2009 12:13:39 UTC

DNS is critical neutral infrastructure the integrity of which needs constant advocacy from the likes of Vixie until the day comes that a credible and equally neutral (or better) global-scale shared distributed mechanism for unique and repeatable identifier resolution can arise. And no I don't mean Google, very funny. And all that is solely because the single strategic flaw in the DNS architecture is that it has a root that is managed by a single entity, currently a country.

CDNs should either do redirection at the HTTP layer, where such behaviour has been designed in (and also enabling user agents to nominate their own preferences or other sophisticated policy behaviour), or using anycast, which is simplicity itself in observing that the network takes care of the shortest path. Or, heck, why not both? Small-sized Anycast HTTP requests with a redirect to a locally optimized content server for the object. Surely someone thought of it already.

John Stracke | Fri, 13 Nov 2009 15:13:59 UTC

"Small-sized Anycast HTTP requests with a redirect to a locally optimized content server for the object. Surely someone thought of it already." -- Yes, of course it's been thought of.  Only problem is, it doesn't work.  You can't do TCP to an anycast address, because you can't be sure that all your packets will go to the same host.

Andrea Costantino | Mon, 16 Nov 2009 18:36:45 UTC

About policies, they are not bad as they are smart.
BIND itself have a concept of proximity and topology, so it had already hardcoded the basic idea of policies.
What it sound so bad are the CDN GSLB used by most Content Distributor.
If you're going to ping the DNS just to reply with the A response for the WWW main site is quite a stupid thing. It's also prone of errors for those doing it unintentionally or without enough knowledge (as any other feature, of course).
Basically, the best solution should be the simplest one:
1) Anycasting for the root DNS (already widely used)
2) CDN in the need for balancing, should have a redirected behaviour on (for istance) customer region or ASN (most of the network allocated can be simply mapped to Europe or US or south america etc.) for the A question to the right DNS server in the right country (or region or whatever). And this can be distributed among all regions.
3) Local DNS receive redirectes and maps to the local CDN distribution point.

If a major fault cut the site, or region, no answering is performed and the DNS client will perform request to another region, and download the content from there.
If the local DNS works, but the CDN goes out, is simple as to shut also the DNS or reconfiguring it.
If the CDN works, but the DNS goes out (strange, given the robustness of the DNS structure itself), that region will be simply not used even if available.
If the CDN operator is wise enough to put two different ISP-based service points in an area a balance among them, it becomes stronger and stronger.

This works perfectly even if:
1) You don't put ping probes. You don't need to, Europe is Europe and is probably better connected inside it than to Asia etc. Partial exception could be US with some low develop sites (Africa), they could be better connected with US than in the same area, but they are a tiny fraction compared to other, developed, areas.
2) You don't have a service policy at all at 2nd level, it must just answer plain A,MX,whatever response
3) If allow caching for a reasonable time (6-24h), given you answer with at least 2 IP (or MX or whatever) into different ISP service points.

No need for GSLB anymore then.

My 2 cents.

bobel | Mon, 16 Nov 2009 21:51:53 UTC

I think DNS was a big mistake.  It's been responsible for all sorts of intellectual property and other problems that would have been avoided had DNS never happened.  

What's the matter with using IP addresses?   We have used numerical addresses for the phone system for years w/o any problems.  Our phones all have the capability to build our own phone books with names meaningful to us.  All browsers have bookmark capabilities.  Most people access what they call the Internet via search engines any way.

DNS - just say no
DNS - consider harmful