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.'"
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.
by Anonymous Coward
on Saturday November 07, @02:49PM (#30016310)
If your ISP does this, then there's a fairly good chance that the software they are using to do it is Nominum's CNS product.
Paul Vixie is on the Advisory Board for Nominum, who also make various other products which conflict with the views that Vixie has stated in this article.
Vixie - you can't have it both ways. If these are your real feeling then I call on you to resign your position on the Advisory Board at Nominum.
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.
There is something to be said for not wasting your advice on a company that refuses to take it, especially when someone else can put your time to better use.
If the company is going to sink with or without your help, you may as well jump ship and rescue someone else instead of going down with them.
If I'm a consultant, I'm aware that my knowledge, and consequently, time, is a valuable resource. I'm not going to take a lot of crap from a company that pays me well just to have the privilege of ignoring me. Th
So he must stop advising a board who makes decisions that he disagrees with? Yeah, that will solve problems.
The problem is that a lot of these boards never listen to the advice of experts, they only want the presence of experts in order to confer legitimacy on their decision. These boards and committees have only the interests of industry at heart, not those of the public. they're not interesting in the facts, or how things should be done. They're interested in giving money and control to private companies.
And that's why a cheap, low-power computer or hackable router is awesome. Just run your own nameserver.
My ISP isn't horrible, but they hijack DNS with a "friendly" error message when there is more than a little network congestion, which sticks until the cache is flushed. That was enough to get me to stop using their server.
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.
Well, I suppose a workaround to that would be to set up an encrypted tunnel to some machine outside their network and running your own DNS server there, depending on your work IT policies you could even use your employer's VPN to run "private" DNS requests while still using your own internet connection for actually accessing the net.
That said I sure wish ISPs wouldn't do dumb shit like this, it pretty much breaks DNS.
Correct me if I'm wrong, as I'm no DNS expert here, but wouldn't running a caching DNS server pointed at OpenDNS [opendns.com] work? Like say Treewalk DNS [treewalkdns.com] pointed to OpenDNS?
Correct me if I'm wrong, but I don't see how they could pull that douchebag behavior if you have a caching server that is only using OpenDNS for queries. And Treewalk is very low resource and runs on seriously old hardware (currently using 6Mb on this 1.1GHz Celeron) and is pretty damned simple to set up and use, so unless I'm missing something it
You dont even need to point it to OpenDNS (which FYI does *exactly* the same kind of advertisement serving on non-existing domains). Just run your own recursive DNS server and you're good to go.
(unless of course your ISP doesn't let you send DNS requests to any other server than theirs, which some people seem to have here)
I actually haven't seen the OpenDNS page but 3 times in 4 years, and in each case I misspelled the address so horribly wrong that the amazing Randi would have went WTF? So I would have to give OpenDNS a thumbs up in that regard. And come to think of it I don't remember seeing the OpenDNS page since running Treewalk, only the basic 404, so maybe having it run as a middle man kills it.
And the "doesn't let you send DNS requests to any other server than theirs" was why I suggested Treewalk to OpenDNS. I haven't
Using a local installation of dnsmasq for your DNS server does, however, allow you to work around NXDOMAIN hijacking, assuming that your ISP uses a consistent IP address for its hijack.
Remember: These changes are often invented by marketing and then pushed through even against the explicit protest of the technology people.
Every technological marketing gimick that has been invented was the result of some techie wanting to get rich quick (or kiss up to his boss) and I don't blame them. If I found a way to exploit DNS further or any other part of the net and was able to get rich from it, I'd do it in a heartbeat.
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.
I doubt it still would go anywhere in court. It's not like it's illegal to break RFC's and protocol standards on services you provide to your customers, who have opted-in and bought them. You might have a case if they blocked using other DNS servers, but they dont. And if they included a part in contract that says you're only allowed to use their DNS server (like they say for email port 25), you don't have a case with that either.
btw, this thing seems to only be a problem in USA too - they're not doing anyt
It's not like it's illegal to break RFC's and protocol standards on services you provide to your customers
No, but it might be illegal to break RFCs and protocol standards on services that you advertise support for. There are lots of truth in advertising laws around the world that could be used to enforce this.
My ISP does the DNS redirection thing, but it's only marginally evil. They only do it for domain names starting www and the page that they redirect to has a permanent opt-out button (which doesn't store anything in a cookie; dig works correctly for looking up www.madeup.example.com after setting it). I
Agreed. Isn't failure to return an NXDOMAIN pretty much the same as any other exploit? I would say that the laws that protect against circumventing the security on a computing system should apply to this false-reply injection technique. Why should some random web operator be given access to download code to my computer when I didn't expressly visit their site?
Uh. Are you completely forgetting that *YOU* are using *THEIR* DNS servers?
Not that DNS response would be anything like executable code either...
Since when is DNS by legal terms part of internet service? Yes ISPs usually have DNS servers for their customers, because it's usually excepted and to make it customer friendly. But unless they specifically state that you will have access to such service too, or say it in contract, you dont have a legal case. And it's not like you cant use other DNS servers or set up your own. ISP's have usually also had email accounts, news and other services but 2000+ they've started dropping those and you wouldn't have a
When your ISP gives you DNS server addresses in your paperwork...
When your ISP gives you name(s) for POP3 service (and maybe NNTP also), rather than addresses, and those names are within the ISP's domain...
Then a working DNS, administered by the ISP, is part of the service. Without it, the ISP is unable to offer the services stated to their customers in their paperwork.
Yes, maybe it's contracted out. But that doesn't change the ISP's responsibility to its customers, or its liability when service fa
Yes I know you pretty much need DNS to use internet, hence why all ISPs offer it to their customers. But what would exactly be that false advertising? They are providing you with DNS servers so you can resolve names. Just because their own-run server breaks RFC (with the NXDOMAIN thing), doesn't exactly break any law. It might be bad habit and it might make technical people angry (normal people just dont care), but that's it. Of course, you are always free NOT to use their services or make them know how you
I dunno. Would your car dealer be doing anything wrong if he only supplied three tires for your new car? I mean, sure, it's pretty much necessary to have four tires to do any kind of real driving, but hey, would they be in the wrong if they opted only to give you three?
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.
I would argue tht IP Masquerading became popular because all of the home consumers that had a single ip address access point to their ISP and multiple devices in the home that needed a connection. High speed home access got affordable and prevalent (outside of major cities) right around '99. At the same time, home access network gateways started having an internet port and four internal network ports with NAT built in to provide the private-public IP translation.
IPv4 vs. IPv6 was not as much as an issue
In fact, that was a great use for masquerading, to get around silly limits by ISPs. The objection is that masquerading eventually became a crutch to avoid switching to IPv6, which wasn't a great use for masquerading.
I think you're missing his point. It's easy to do, because he does hide it quite well behind a large wall of text. DNS, as Vixie (awesome name) rightly says, should be a cacheable mapping. The result should depend on the query and nothing else. It should not depend on who your ISP is. It should not depend on your geographical location. If you do a DNS lookup from your computer, you should get exactly the same result that I get from my computer at the same time, irrespective of where we both are in the
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%.
SPF, SenderID, and DKIM are not spam-fighting techniques. They are forgery-fighting techniques. Some spammers use SPF and SenderID records to give their spam a higher sense of legitimacy. A spammer cannot forge "paypal.com" because Paypal publishes SPF records. A spammer CAN pretend to be Paypal by using a look-alike domain with its own set of SPF records (ie: paypall.com, paypal.org). SPF and SenderID simply publish what IPs are authorized to send email claiming to be from a particular domain. DKIM d
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 suspect anycast would be a better method, honestly.
And you'd be completely, utterly wrong. I've seen anycast resulting some mind-numblingly stupid site selection choices, usually due to a local ISP's BGP policy - and when I say "stupid" I mean "all users of ISP X in New York City getting sent to a mirror in Sydney, Australia instead of the site downtown".
This might be OK for simple DNS queries, but for actual web sites it is a True Path To Pain.
Note: Most large CDNs are setup to use anycast, from Akamai to Google - although Akamai makes use of also DNS geolocation in certain instances.
And you'd be completely, utterly wrong.
...
I've seen anycast resulting some mind-numblingly stupid site selection choices, usually due to a local ISP's BGP policy - and when I say "stupid" I mean "all users of ISP X in New York City getting sent to a mirror in Sydney, Australia instead of the site downtown".
So, a configuration error from one ISP makes it completely, u
I don't know, how much does an anycast address cost? So much that Google or Akamai can't afford it? (Also, RR load balancing is a separate thing entirely.)
Regarding the CDNs, you didn't read the article did you; it is fundamentally flawed. The CDN does not choose a server based upon proximity to the endpoint, but rather to the recursive resolver through which the DNS request passed.
He argues that the problem is, the client doesn't usually hit the DNS server, the clients DNS server only does after it expires its own local cache.
Just because your ISP's DNS servers are sitting in LA, doesn't mean you are. You could be on Seattle, and using those DNS servers, or out in the world, on the work VPN, using their DNS server in downtown Chicago. Thats how many people get around regional restrictions now, in fact.
People have shoehorned DNS into something that it is neither Efficient, or design
That might be the case in USA, but in other parts of world you're 99% of the time using DNS servers in your own country, which is pretty much the closest area CDN can have their things anyway. Yes you could use a vpn, have changed your dns servers and so on, but you're the minority case there, and even then it works normally, probably just not as efficiently as it could.
It is a completely different situation when you look it at the whole world view.
> 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.
According to Google I spent the last two weeks of October jumping around between Japan, France, Spain, and Britain.
I never left Wisconsin. And no, I was not using Tor or a VPN or any such thing.
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.
Uhm, everyone can connect to the exact same webserver cluster and THEN be redirected with no involvement what so ever from dynamic DNS.
Akamai could use DNS with traditional cache times and still redirect to the right node via http redirects. DNS caching would still work flawlessly and the actual request could be handled over the protocol that actually has knowledge of redirection and ways to say 'this is a permeant redirection' or 'this is only temporary, next time ask me again'
I'm not against using DNS this way, but there are certainly alternatives that would accomplish the same thing just as well.
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?
Interesting echo from FAQ [monotone.ca] which I read the other night. The original contains a lot of italic I'm not going to replicate.
An important fact about monotone's networking is that it deals in facts rather than operations. Networking simply informs the other party of some facts, and receives some facts from the other party. The netsync protocol determines which facts to send, based on an interactive analysis of "what is missing" on each end. No obligations, transactions, or commitments are made during networking. For all non-networking functions, monotone decides what to do by interpreting the facts it has on hand, rather than having specific conversations with other programs.
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.
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.
Vixie didn't justify it - he acknowledged that it was a design flaw with no practical airtight fix besides DNSSEC - but he was one of the main players that coordinated the patches to get source port randomization, the best possible fix easily deployable, out there before the bug became public knowledge.
not only Verisign (Score:5, Insightful)
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.
Re:not only Verisign (Score:4, Interesting)
If your ISP does this, then there's a fairly good chance that the software they are using to do it is Nominum's CNS product.
Paul Vixie is on the Advisory Board for Nominum, who also make various other products which conflict with the views that Vixie has stated in this article.
Vixie - you can't have it both ways. If these are your real feeling then I call on you to resign your position on the Advisory Board at Nominum.
Parent
Don't be a baby! (Score:5, Insightful)
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.
Parent
Re: (Score:3, Insightful)
There is something to be said for not wasting your advice on a company that refuses to take it, especially when someone else can put your time to better use.
If the company is going to sink with or without your help, you may as well jump ship and rescue someone else instead of going down with them.
If I'm a consultant, I'm aware that my knowledge, and consequently, time, is a valuable resource. I'm not going to take a lot of crap from a company that pays me well just to have the privilege of ignoring me. Th
Re: (Score:3, Insightful)
The problem is that a lot of these boards never listen to the advice of experts, they only want the presence of experts in order to confer legitimacy on their decision. These boards and committees have only the interests of industry at heart, not those of the public. they're not interesting in the facts, or how things should be done. They're interested in giving money and control to private companies.
Re: (Score:2)
Is that you, Obelix the gallstone? Fell into a vat of anonymous coward super juice as a young infant? I thought so.
He's only having it both ways if he privately supports Nominum's stupidity, while publicly declaiming his involvement.
This post is an excellent example of polarization disorder: the belief that the world will run most smoothly if everyone is neatly al
Re: (Score:2)
And that's why a cheap, low-power computer or hackable router is awesome. Just run your own nameserver.
My ISP isn't horrible, but they hijack DNS with a "friendly" error message when there is more than a little network congestion, which sticks until the cache is flushed. That was enough to get me to stop using their server.
Re:not only Verisign (Score:4, Informative)
Parent
Re: (Score:2)
Well, I suppose a workaround to that would be to set up an encrypted tunnel to some machine outside their network and running your own DNS server there, depending on your work IT policies you could even use your employer's VPN to run "private" DNS requests while still using your own internet connection for actually accessing the net.
That said I sure wish ISPs wouldn't do dumb shit like this, it pretty much breaks DNS.
/Mikael
Re: (Score:2)
If I'm OCD enough to set up my own DNSd, why do you assume I'd not think about that?
True, most people don't have hardware on another network, but virtual servers are silly cheap if you are only using it for DNS and SSH redirection.
Re: (Score:2)
Correct me if I'm wrong, as I'm no DNS expert here, but wouldn't running a caching DNS server pointed at OpenDNS [opendns.com] work? Like say Treewalk DNS [treewalkdns.com] pointed to OpenDNS?
Correct me if I'm wrong, but I don't see how they could pull that douchebag behavior if you have a caching server that is only using OpenDNS for queries. And Treewalk is very low resource and runs on seriously old hardware (currently using 6Mb on this 1.1GHz Celeron) and is pretty damned simple to set up and use, so unless I'm missing something it
Re: (Score:2)
You dont even need to point it to OpenDNS (which FYI does *exactly* the same kind of advertisement serving on non-existing domains). Just run your own recursive DNS server and you're good to go.
(unless of course your ISP doesn't let you send DNS requests to any other server than theirs, which some people seem to have here)
Re: (Score:3, Interesting)
I actually haven't seen the OpenDNS page but 3 times in 4 years, and in each case I misspelled the address so horribly wrong that the amazing Randi would have went WTF? So I would have to give OpenDNS a thumbs up in that regard. And come to think of it I don't remember seeing the OpenDNS page since running Treewalk, only the basic 404, so maybe having it run as a middle man kills it.
And the "doesn't let you send DNS requests to any other server than theirs" was why I suggested Treewalk to OpenDNS. I haven't
Re: (Score:3, Informative)
Bind has Windows binaries for XP/2003/2008
https://www.isc.org/downloadables/11 [isc.org]
Re: (Score:3, Interesting)
Using a local installation of dnsmasq for your DNS server does, however, allow you to work around NXDOMAIN hijacking, assuming that your ISP uses a consistent IP address for its hijack.
Re:not only Verisign (Score:5, Interesting)
Every technological marketing gimick that has been invented was the result of some techie wanting to get rich quick (or kiss up to his boss) and I don't blame them. If I found a way to exploit DNS further or any other part of the net and was able to get rich from it, I'd do it in a heartbeat.
And so would most of you, too.
Parent
Re: (Score:2)
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.
I doubt it still would go anywhere in court. It's not like it's illegal to break RFC's and protocol standards on services you provide to your customers, who have opted-in and bought them. You might have a case if they blocked using other DNS servers, but they dont. And if they included a part in contract that says you're only allowed to use their DNS server (like they say for email port 25), you don't have a case with that either.
btw, this thing seems to only be a problem in USA too - they're not doing anyt
Re: (Score:2)
It's not like it's illegal to break RFC's and protocol standards on services you provide to your customers
No, but it might be illegal to break RFCs and protocol standards on services that you advertise support for. There are lots of truth in advertising laws around the world that could be used to enforce this.
My ISP does the DNS redirection thing, but it's only marginally evil. They only do it for domain names starting www and the page that they redirect to has a permanent opt-out button (which doesn't store anything in a cookie; dig works correctly for looking up www.madeup.example.com after setting it). I
Re: (Score:2)
Agreed. Isn't failure to return an NXDOMAIN pretty much the same as any other exploit? I would say that the laws that protect against circumventing the security on a computing system should apply to this false-reply injection technique. Why should some random web operator be given access to download code to my computer when I didn't expressly visit their site?
Uh. Are you completely forgetting that *YOU* are using *THEIR* DNS servers?
Not that DNS response would be anything like executable code either...
Re: (Score:2)
Since when is DNS by legal terms part of internet service? Yes ISPs usually have DNS servers for their customers, because it's usually excepted and to make it customer friendly. But unless they specifically state that you will have access to such service too, or say it in contract, you dont have a legal case. And it's not like you cant use other DNS servers or set up your own. ISP's have usually also had email accounts, news and other services but 2000+ they've started dropping those and you wouldn't have a
Re: (Score:3, Insightful)
When your ISP gives you name(s) for POP3 service (and maybe NNTP also), rather than addresses, and those names are within the ISP's domain...
Then a working DNS, administered by the ISP, is part of the service. Without it, the ISP is unable to offer the services stated to their customers in their paperwork.
Yes, maybe it's contracted out. But that doesn't change the ISP's responsibility to its customers, or its liability when service fa
Re: (Score:2)
Yes I know you pretty much need DNS to use internet, hence why all ISPs offer it to their customers. But what would exactly be that false advertising? They are providing you with DNS servers so you can resolve names. Just because their own-run server breaks RFC (with the NXDOMAIN thing), doesn't exactly break any law. It might be bad habit and it might make technical people angry (normal people just dont care), but that's it. Of course, you are always free NOT to use their services or make them know how you
Re: (Score:2)
No they are not, because it isn't proper DNS, it's their tainted version of it.
Of course this restaurant doesn't sell dead cat, it clearly says chicken right here on the menu.
Re: (Score:2)
I dunno. Would your car dealer be doing anything wrong if he only supplied three tires for your new car? I mean, sure, it's pretty much necessary to have four tires to do any kind of real driving, but hey, would they be in the wrong if they opted only to give you three?
competition (Score:2)
Re: (Score:2)
Good luck getting everyone join your root servers instead.
Re: (Score:2)
Such things exist. [wikipedia.org] Nobody uses them.
what it is becoming (Score:3, Interesting)
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.
Re: (Score:2, Insightful)
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
I think you're missing his point. It's easy to do, because he does hide it quite well behind a large wall of text. DNS, as Vixie (awesome name) rightly says, should be a cacheable mapping. The result should depend on the query and nothing else. It should not depend on who your ISP is. It should not depend on your geographical location. If you do a DNS lookup from your computer, you should get exactly the same result that I get from my computer at the same time, irrespective of where we both are in the
This is a good opportunity to say... (Score:2)
Breaking the standards to implement policy (Score:4, Interesting)
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%.
Re: (Score:3, Informative)
CDNs are good thing (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
I suspect anycast would be a better method, honestly.
Re: (Score:3, Informative)
I suspect anycast would be a better method, honestly.
And you'd be completely, utterly wrong. I've seen anycast resulting some mind-numblingly stupid site selection choices, usually due to a local ISP's BGP policy - and when I say "stupid" I mean "all users of ISP X in New York City getting sent to a mirror in Sydney, Australia instead of the site downtown".
This might be OK for simple DNS queries, but for actual web sites it is a True Path To Pain.
Re: (Score:2, Flamebait)
Note: Most large CDNs are setup to use anycast, from Akamai to Google - although Akamai makes use of also DNS geolocation in certain instances.
...
So, a configuration error from one ISP makes it completely, u
Re: (Score:2)
Usually free by most IXPs, provided you have a link to them, but also datacenter providers can usually forward on requests to do this too.
No idea, I've never had others handle my hardware in these situations.
For the anycast, it isn't.
Nope.
Re: (Score:2)
I don't know, how much does an anycast address cost? So much that Google or Akamai can't afford it? (Also, RR load balancing is a separate thing entirely.)
Regarding the CDNs, you didn't read the article did you; it is fundamentally flawed. The CDN does not choose a server based upon proximity to the endpoint, but rather to the recursive resolver through which the DNS request passed.
Anycast does exactly what you want.
Re: (Score:3, Informative)
He argues that the problem is, the client doesn't usually hit the DNS server, the clients DNS server only does after it expires its own local cache.
Just because your ISP's DNS servers are sitting in LA, doesn't mean you are. You could be on Seattle, and using those DNS servers, or out in the world, on the work VPN, using their DNS server in downtown Chicago. Thats how many people get around regional restrictions now, in fact.
People have shoehorned DNS into something that it is neither Efficient, or design
Re: (Score:2)
That might be the case in USA, but in other parts of world you're 99% of the time using DNS servers in your own country, which is pretty much the closest area CDN can have their things anyway. Yes you could use a vpn, have changed your dns servers and so on, but you're the minority case there, and even then it works normally, probably just not as efficiently as it could.
It is a completely different situation when you look it at the whole world view.
Re: (Score:3, Informative)
> 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.
According to Google I spent the last two weeks of October jumping around between Japan, France, Spain, and Britain.
I never left Wisconsin. And no, I was not using Tor or a VPN or any such thing.
The two examples don't seem anything alike ... (Score:5, Interesting)
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.
Re:The two examples don't seem anything alike ... (Score:5, Insightful)
Uhm, everyone can connect to the exact same webserver cluster and THEN be redirected with no involvement what so ever from dynamic DNS.
Akamai could use DNS with traditional cache times and still redirect to the right node via http redirects. DNS caching would still work flawlessly and the actual request could be handled over the protocol that actually has knowledge of redirection and ways to say 'this is a permeant redirection' or 'this is only temporary, next time ask me again'
I'm not against using DNS this way, but there are certainly alternatives that would accomplish the same thing just as well.
Parent
News to me (Score:2, Interesting)
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?
facts (Score:3, Interesting)
Interesting echo from FAQ [monotone.ca] 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? [ted.com]
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.
IP over DNS (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Vixie didn't justify it - he acknowledged that it was a design flaw with no practical airtight fix besides DNSSEC - but he was one of the main players that coordinated the patches to get source port randomization, the best possible fix easily deployable, out there before the bug became public knowledge.
BTW have you ever met the man? I have.