Paul Vixie On What DNS Is Not
CowboyRobot writes "Paul Vixie (AboveNet, ARIN, ISC, MAPS, PAIX) has a fresh rant titled What DNS Is Not about the abuses of the Domain Name Server system. '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 ... a few years ago VeriSign, which operates the .COM domain under contract to ICANN, 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.'"
Well Paul, in this world it all depends on how much money you throw at it.
Many ISPs do it as well. Right now, my ISP does it, even though I've opted out. Maybe one of these days I'll sue them.
Maybe it's time that the Internet standards get a few clauses added that express these concepts explicitly. Like what Paul said about DNS. A clause like "a nameserver MUST responde truthfully, if technically possible. DNS responses MUST NOT be modified in any way for political, economic or business reasons."
Then these fucked up ISPs would at least be in violation of a standard, which might give me what I need for a violation-of-contract suit.
Remember: These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people.
Assorted stuff I do sometimes: Lemuria.org
You still expect your child to not murder, cheat and steal, and you still expect them to be punished if they do. Regardless of how much they've grown.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Maybe it's time for someone to set up a DNS system in competition to ICANN. I don't think it's impossible to change your root servers list.
Nullius in verba
Looks like this article is more about, "what DNS is becoming but I don't like." He may not like it, but that's what's happening with DNS.
Not that I particularly like it either, but then I wasn't too happy when the word 'hacker' changed to mean 'someone who breaks into your computer.' Nor was I particularly happy about masquerading becoming a popular routing technique, instead of switching to IPv6. And yet, that's what happened. Sometimes technologies are twisted in ways you don't intend or like.
Qxe4
Fuck you Bell! Give me my NXDOMAIN back.
So if this is the future...where's my jet pack?
So he must stop advising a board who makes decisions that he disagrees with? Yeah, that will solve problems. Everyone should only advise people who were going to make the decisions that the adviser was going to advise anyway. That way, all advisers are useless. And then ... what exactly is your end goal in making advisers useless?
Some people do resign from boards when the board repeatedly makes decisions that the adviser does not approve of. The rejection just gets to be too much for them, and so they quit. It is understandable, but the board suffers when the range of opinions decreases.
Basically, AC, people you work with will make decisions you disagree with. It is important that you put of with it, and not be a big baby.
Breaking the standards to implement policy is a good thing sometimes. Take SPF records for example: if they were to become widespread, then spam could very easily be reduced by probably 99%.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
While I totally agree that overriding NXDOMAIN responses is evil, returning different DNS responses based on the clients location or for load balancing purposes is an extremely useful technique for last companies serving a large amount of web traffic. For example, check out what www.google.com resolves to from different countries or even at different times - depending on where you look it up from and what network links are up, you will get a different set of IPs.
Sure, determining a browser's location from the DNS client source IP is not totally reliable .. but it is accurate enough to significantly improve user-visible responsiveness by avoiding un-necessary cross-planet network traffic. And even if google gets it wrong, they are no worse off than if they never implemented this in the first place.
I'll listen to Vixie once he justifies the Kaminsky bug.
I want to delete my account but Slashdot doesn't allow it.
Ok, we all agree that funneling NXDOMAIN responses to your advertising portal is wrong. It's evil, manipulative, blah blah, not going to defend it.
What really bothers me is his rationale for the first example -- using DNS responses to properly route content to the right node in your CDN. Sure, it increases the "floor" request time by eliminating cached response closer to the user, but it also greatly decreases the average request time by serving the content from the nearest node. It seems to me like it's a huge net win for the total amount of network traffic -- you lose by having a whole lot of extra (tiny) DNS requests and cache-misses but you win huge by having Microsoft's latest service pack (many MB) traverse the smallest possible number of hops.
His second complaint, that this is somehow lawsuit-fodder, is ridiculous on its face. Akamai works incredibly well for content providers that don't want to invest in lots of redundant distribution resources. They have every incentive to outsource it to a company that will provide the users with a much faster experience and virtually nothing to lose. Most users will give up on a website if it can't serve their requests in a reasonable amount of time and I don't see a revolution in user patience about to happen.
Finally, his "solution" -- that CDNs rely on dumb ("psuedorandom" is his fancy was of saying dumb) assignment of users to distribution nodes -- is a huge step backwards. It would mean more stress on the long-haul fiber for absolutely no good reason as requests were served geographically distance from their origin. By the way, it's interesting that he labels his dumb response "truthful", as if Akamai lied when they assign me to a different node than my Australian buddy because we live half a globe apart? That's ridiculous. We each asked for a server that can give us www.amd.com, we got a damn truthful answer. In fact, we each got the best possible answer we could. That's not lying, it's giving each of us a finer-grained optimal answer than we would have received under his lame suggestion.
Please don't confuse his (for the forgoing reasons, silly) rant against CDNs with his rightful indignation at NXDOMAIN redirects. They are totally different animals.
Running your own server doesn't get around the ISP's DNS, when the ISP is routing all customers' DNS requests to their own servers regardless of destination address. Before you ask, the same technique is already being done with transparent web cache/proxying.
Would DNSSEC help with this re-routing?
But /. philosophy states if the child murders, cheats, or steals it's due to bad parenting. So who should be punished? The child? The parents? Maybe the grand parents for failing to properly raise the parents?
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.
Which browsers actually do this? Is Mozilla actually participating in that nonsense?
Breaking the standards to implement policy is a good thing sometimes. Take SPF records for example: if they were to become widespread, then spam could very easily be reduced by probably 99%.
But SPF is not implementing policy; SPF is a form of "facts".
An SPF record is nothing more than an RR record (either TXT or type 99/SPF) in a particular format. The DNS client (mail server) goes out and asks 'please give me the TXT record for this domain'. DNS returns a fact: the record itself or 'does not exist'. What you do with that record is a matter of policy.
What various ISPs did/do is take the query and return whatever the hell they feel like, i.e., not return 'does not exist' but rather something else. This is not returning facts, but returning lies (the definition of a lie being 'a statement that you know is not true, but pretend that is').
Insufficient data.
You certainly punish the child, regardless of why the did it. If daddy puts a gun to your head and says kill this man or I kill you, you still committed a crime and have to be treated as such. The punishment does however take the parents into account in some limited cases, such as the parents still being the legal guardians of the child. When the child is no longer a child, but a consenting adult, then it really doesn't matter what the parents did. Adults are responsible for their own actions. PERIOD. Its not just about punishment, its about protecting the rest of the world as well.
If the child never had any direct interaction with the grandparents then they are clearly off limits.
If the parents were not involved after birth, and the grandparents were, they effectively become the parents and assume all responsibilities for that roll, they could have put the child up for adoption had they wanted to avoid those responsibilities.
You simply didn't not provide enough information.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Interesting echo from FAQ which I read the other night. The original contains a lot of italic I'm not going to replicate.
The closer one lives to the foundation, the stronger the argument for a fact-based architecture. DNS is about as foundational as one can get in internet security. Interesting, the architecture of monotone is highly cryptographic, and somewhat reminiscent of DNSSEC from the 40,000 foot view.
The people who don't see the problem with mixing fact and policy are likely the same people who don't regard it as a big problem that your credit card numbers is widely distributed in plain text: to every vendor you do business with, many of their employees, the trash collectors out back, and their governing union.
Why is it that some guy on the GPS thread complained that the police are free to criminalize driving under the age of 18 (to collect more revenue) and effectively act as their own judge, jury, and executioner (in the corrupt towns where this practice becomes established), but there is generally less complaint about VISA architecting themselves the same powers?
If the police collected a 2% slice of gasoline revenues and awarded bonus points for trips to Hawaii in any year where you keep your license clear and generally found other clever ways to rebate unpenalized drivers the 2% (with enough hidden strings attached it doesn't ultimately cost them much), would they be as loved as the VISA company? Just asking.
Dan Ariely asks, Are we in control of our own decisions?
Turns out it depends on how you frame the question. If the question is: do you want the DNS system to become so badly abused it might as well have been designed by a bank, you might get one answer. If the question is: do you want DNS optimized so your porn streams with ten seconds less delay between clips, you probably get the other answer.
I vote for facts. That said, I will say one thing in defense of Akamai: one can construe CDN as a fact based system, if the factoids you are dealing in that "this IP address can deliver the content you want". Ideally, you already have a secure hash signature of the file you're seeking so it can't play too many games with the notion of "the file you want".
I don't see why DNS needs the facts to be so low level as "this is the same IP address everyone else gets for the same query". There could be a good reason, but Vixie's excellent article fell short of providing it.
Ideally, the CDN problem would have been solved with another layer of delegation: the content you are seeking can be obtained from a vast array of different places, here's an authoritative address for a highly overloaded server; if you're in a hurry go talk to xxx.xxx.xxx.xxx to find a location near you. Then the caching proxy can send a request with the header "I represent a client in the Pacific Northwest" rather than sending back to the client the name of the video store where client's attorney rents his own porn.
But he has a point. DNS is very good at what it does, but when companies start mucking about with it, it's reliability becomes much more questionable. In the .com fiasco we had the DNS clearly abused with severe repercussions for general wide-scale network stability.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Is everyone here forgetting IP over DNS? How else would I get free internet at paid wifi access points??
Besides in the dream world where you apparently live a great deal of your life ? I can see why you post as an AC.
errr....umm...*whooosh* *whoosh* Is this thing on ?
Just in the first paragraph:
DNS (Domain Name System) is a hierarchical, distributed, autonomous, reliable database.
How is it autonomous? Or at least, how is it more autonomous than any other database, certainly any database which meets the other three criteria?
The first and only of its kind,
Sorry, no. Maybe the first, but it's certainly not the only. There are many other databases which offer distributed, reliable storage, and at least one I can think of which is hierarchical.
it offers realtime performance levels
Realtime? Are you sure?
I mean, aside from slow DNS servers, there's the fact that while reads may be realtime, updates are anything but. Just try changing IPs and watch how long it takes the change to propagate. Real databases measure this kind of thing in seconds or minutes -- DNS measures it in days.
Every TCP/IP traffic flow including every World Wide Web page view begins with at least one DNS transaction.
Bullshit. Want proof? Buy a Linksys router and hit http://192.168.1.1/ to configure it. Well, look at that! No DNS needed!
There are indeed people who run webpages off of IPs.
Alright, I didn't have to rip it apart that much, and maybe I'm nitpicking. But come on, the number of things which are simply wrong is staggering -- the BS-to-word-count ratio is quite high.
Do I want to read the rest of the article?
Maybe. It seems much cleaner and more accurate than that first paragraph, but it wouldn't have been that hard, especially for a guy with those credentials, to get it right.
Don't thank God, thank a doctor!
I met Vixie some number of years ago in Vegas and he blew my mind away with his insight. He's spot on once again in this article.
Wonderful post
Protocols evolve and to new stuff that the original designers didn't think of. That is just the way it is. DNS does not have to be inline to be able to enforce a policy. This makes it inexpensive for service providers to implement "value added services" in DNS. The alternative is to do it with DPI boxes from Allot, Procera or Cisco and sit inline. I rather have some NXDOMAIN responses that I can opt out from, than somebody that sniffs on all my traffic.
Mr Vixie should know that service providers don't listen to what the hell IETF, ARIN and other non profit organizations have to say. And I agree with other comments here as well, him sitting on the Advisory Board for Nominum is disturbing. I have never heard anybody saying anything good about Nominum since they helped with the development of Bind 9 about 10 years ago. /Mr.75
That metaphor you have there is almost as inappropriately overextended and overreaching as modern DNS technologies.
Boot Windows, Linux, and ESX over the network for free.
I see too many organizations using DNS as an inventory system (e.g prtsertor01) resulting in host names more difficult to remember than IP addresses.
UNIX/Linux Consulting
don't forget that web browsers are not the only dns clients.
When you have a thousand people, what should you name them?
It all comes down to thrust. If my ISP changes the answers of the root server for non existing adresses how do I know they don't do it for other adresses, too ? And if they use something like deep packet inspection to select my DNS requests and redirect them to their server, it's actually a man in the middle attack. Also known as DSN spoofing and used by many criminals to collect all sorts of information.
Seriously, we have to stop taking crap from those return of investment and cash flow management idiots, who think they can change the way everything works, because they own the infrastructure.
As slashdotters seem to like car analogies, would anyone of you use a navigation system which would give you any directions for not existing streets ? I would throw it out of my car.
Probably I should write a script which just asks for a bogus URL every ms. Also it would follow every link on this site. Let's see for how long this practice is being used if every DNS request is answered by a web site and all their advertisement contractors have to pay for "clicks" by a stoopid script ?
This is a classic "closed stacks library problem"
The correct answer is that, where today there is one DNS request, in order to cope with this level of fraud there will need to be dozens/thousands of requests by resolvers to name servers. From these many duplicate requests, a most likely answer will be selected (and returned to the client) and name servers that disagree will be referred to a public reputation sharing system as "Liars". All caching will become local - a preemptive resolving daemon if you will.
additional levels of "consumer fraud detection" daemons can be layered on top this kind of service - I expect any ISP with a bad rep to suffer an immense amount of traffic from it's clients trying to determine whether the service they were sold is actually being provided.
oh, and sorry about all that extra traffic ISP - but it's your f^ckup - you deserve it.
Maybe it's time that the Internet standards get a few clauses added that express these concepts explicitly. Like what Paul said about DNS. A clause like "a nameserver MUST responde truthfully, if technically possible. DNS responses MUST NOT be modified in any way for political, economic or business reasons."
I invite you to write the RFC. It's easy to do, and basically, anybody can write an RFC. There's the infamous evil bit for example. But here's the thing... RFCs are just that: Requests For Ccomment. They don't have any teeth, even if they are frequently referred to. For example, I looked directly at the RFCs in order to develop an SMTP handler a few years back...
There IS an "Internet Standards Organization" or three, and they do often "adopt" an RFC to be an "Internet Standard", but if you look, you'll find that there's no enforcement arm whatsoever! It's up to you, the Internet participant, to require/enforce these standards. And just like the explosion in unregulated 802.11 networking, the Internet's power comes from this completely open, unregulated nature.
Sure, there's a wart or ten. Sorry, that's just how it is. I can name a few others:
1) Large ISPs often ignore the TTL values in name servers and set them to as long as 48 hours. This makes moving servers from location A to location B fraught with hacks, such as putting in a NAT router at the old location to forward traffic to the old "wrong" address to the new "right" one.
2) Mail servers that often don't bounce undeliverable messages, just passing them to /dev/null.
3) "Tricks" played by IE to make it seem "faster" by not negotiating a proper connection to the webserver.
Yes, all of these, (and more!) are highly annoying, but the truth is that violations of standards can't be all that flagrant, or the system breaks and people get upset. So overall, the system works remarkably well.
Can you imagine what would have happened if the Internet didn't happen and we ended up going with AOL's proprietary network?
(shudder)
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Oh, right, they can't tell you're trying to open an https connection instead of an http connection because they're hijacking the DNS query, not the browser query. That's why it's called *broken*.
And where do they put the opt-out button on ssh connections? Unlike email, where I'm usually not emailing to a www.* address, I fairly often want to ssh to a web server (admittedly, that's usually inside my own network, but not always), and they shouldn't be fraking with it - and they can't tell whether they are or not.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
They're not redirecting you to a web page - they're redirecting you to a different IP address, which has a web server on it. What if you weren't running http? Besides dig, there's also https (are they only serving http?), and ssh, and email (less common on www.x.x, admittedly), but they're still fundamentally breaking it.
It's not unreasonable to expect that my machine might have a web browser on it - but if that's not the application I used, they need to know not to break it, and they *can't* know that, because they don't know what application asked DNS to send the DNS query. Furthermore, the browsers I'm most likely to be using already know how to redirect queries to my favorite search engine, so they're also breaking that application.
There's one case where it's usually ok for them to break DNS, which is where you're trying to query a DNS name for a known Evil Website, typically a phisher or malware site. There are some people who really want to check out what's being served from evil.impostor.paypa11.com, but those people are expected to know what they're doing, and 99.999% of the queries to those sites are due to phishing or other evils.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I'm not saying there aren't lots of reasons to be upset with just about any phone company, but which one are you upset at?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I don't know about his ISP, but there are ISPs out there that not only hijack NXDOMAIN queries, but also transparently hijack *all* DNS queries. DNSSEC may help, and anti-Kaminsky-spoofing may help, but it's basically evil.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
You're blaming the wrong Paul. The Kaminsky bug works because DNS usually uses UDP and only has a 16-bit query ID field, so it's easy to overwhelm at current network speeds (it was a bit tougher when the ARPAnet backbone was 56kbps...) and because you can birthday-attack the stuff if you're clever.
I've only waded as far back as RFC883 today, so it's possible that somebody other than Paul Mockapetris and presumably Jon Postel was responsible for picking the query id field size, but I doubt it was Paul Vixie. If you want to blame him for how long it took to put query port randomization into BIND, I won't stand in your way, but even that's only a stopgap.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Ah good point. Fuck you Bell Canada!
So if this is the future...where's my jet pack?