Thought-provoking article by Paul Vixie: http://queue.acm.org/detail.cfm?id=1647302 -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Alex Balashov wrote:
Thought-provoking article by Paul Vixie:
I doubt Henry Ford would appreciate the Mustang. -Dave
Dave Temkin wrote:
Alex Balashov wrote:
Thought-provoking article by Paul Vixie:
I doubt Henry Ford would appreciate the Mustang.
I don't think that is a very accurate analogy, and in any case, the argument is not that we should immediately cease at once all the things we do with DNS today. DNS is one of the more centralised systems of the Internet at large; it works because of its reliance on intermediate caching and end-to-end accuracy. It seems to me the claim is more that DNS was not designed to handle them and that if this is what we want to do, perhaps something should supplant DNS, or, alternate methods should be used. For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS? -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Alex Balashov wrote:
For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS?
-- Alex
In most cases it already is. He completely fails to address the concept of Anycast DNS and assumes people are using statically mapped resolvers. He also assumes that DNS is some great expense and that by not allowing tons of caching we're taking money out of peoples' wallets. This is just not true with the exception of very few companies whose job it is to answer DNS requests. -Dave
On Nov 8, 2009, at 7:06 PM, Dave Temkin wrote:
Alex Balashov wrote:
For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS?
-- Alex
In most cases it already is. He completely fails to address the concept of Anycast DNS and assumes people are using statically mapped resolvers.
He also assumes that DNS is some great expense and that by not allowing tons of caching we're taking money out of peoples' wallets. This is just not true with the exception of very few companies whose job it is to answer DNS requests.
This myth (that Paul mentions, not to suggest Dave T's comment is a myth) was debunked years ago: "DNS Performance and the Effectiveness of Caching" Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris http://pdos.csail.mit.edu/papers/dns:ton.pdf Basically: Caching of NS records is important, particularly higher up in the hierarchy. Caching of A records is drastically less important - and, not mentioned in the article, the cost imposed by low-TTL A records is shared mostly by the client and the DNS provider, not some third party infrastructure. From the paper: "Our trace-driven simulations yield two findings. First, reducing the TTLs of A records to as low as a few hundred seconds has little adverse effect on hit rates. Second, little benefit is obtained from sharing a forwarding DNS cache among more than 10 or 20 clients. This is consistent with the heavy-tailed nature of access to names. This suggests that the performance of DNS is not as dependent on aggressive caching as is commonly believed, and that the widespread use of dynamic low-TTL A-record bindings should not degrade DNS performance. The reasons for the scalability of DNS are due less to the hierarchical design of its name space or good A-record caching than seems to be widely believed; rather, the cacheability of NS records efficiently partition the name space and avoid overloading any single name server in the Internet." -Dave
On Nov 8, 2009, at 7:30 PM, bmanning@vacation.karoshi.com wrote:
On Sun, Nov 08, 2009 at 07:17:16PM -0500, David Andersen wrote:
"Our trace-driven simulations yield two findings. First, reducing the
-----------
-Dave
a simulation is driven from a mathmatical model, not real world constructions.
Hi, Bill - The paper is worth reading. "The paper also presents the results of trace-driven simulations that explore the effect of varying TTLs and varying degrees of cache sharing on DNS cache hit rates. " emphasis on *trace-driven*. Now, you can argue whether or not their traces are representative (whatever that means) -- they used client DNS and TCP connection traces from MIT and KAIST, so it definitely has a .edu bias, iff there is a bias in DNS traffic for universities vs. "the real world", but to the extent that their traces represent what other groups of users might see, their evaluation seems accurate. -Dave
On Sun, Nov 08, 2009 at 07:42:18PM -0500, David Andersen wrote:
On Nov 8, 2009, at 7:30 PM, bmanning@vacation.karoshi.com wrote:
On Sun, Nov 08, 2009 at 07:17:16PM -0500, David Andersen wrote:
"Our trace-driven simulations yield two findings. First, reducing the
-----------
-Dave
a simulation is driven from a mathmatical model, not real world constructions.
Hi, Bill -
The paper is worth reading.
"The paper also presents the results of trace-driven simulations that explore the effect of varying TTLs and varying degrees of cache sharing on DNS cache hit rates. "
emphasis on *trace-driven*. Now, you can argue whether or not their traces are representative (whatever that means) -- they used client DNS and TCP connection traces from MIT and KAIST, so it definitely has a .edu bias, iff there is a bias in DNS traffic for universities vs. "the real world", but to the extent that their traces represent what other groups of users might see, their evaluation seems accurate.
-Dave
I'm not debating the traces - I wonder about the simulation model. (and yes, I've read the paper) --bill
On Nov 8, 2009, at 7:46 PM, bmanning@vacation.karoshi.com wrote:
"The paper also presents the results of trace-driven simulations that explore the effect of varying TTLs and varying degrees of cache sharing on DNS cache hit rates. "
I'm not debating the traces - I wonder about the simulation model. (and yes, I've read the paper)
I'm happy to chat about this offline if it bores people, but I'm curious what you're wondering about. The method was pretty simple: - Record the TCP SYN/FIN packets and the DNS packets - For every SYN, figure out what name the computer had resolved to open a connection to this IP address - From the TTL of the DNS, figure out whether finding that binding would have required a DNS lookup There are some obvious potential sources of error - most particularly, name-based HTTP virtual hosting may break some of the assumptions in this - but I'd guess that with a somewhat smaller trace, not too much error is introduced by clients going to different name-based vhosts on the same IP address within a small amount of time. There are certainly some, but I'd be surprised if it was more than a %age of the accesses. Are there other methodological concerns? I'd also point out for this discussion two studies that looked at how accurately one can geo-map clients based on the IP address of their chosen DNS resolver. There are obviously potential pitfalls here (e.g., someone who travels and still uses their "home" resolver). In 2002: Z. M. Mao, C. D. Cranor, F. Douglis, and M. Rabinovich. A Precise and Efficient Evaluation of the Proximity between Web Clients and their Local DNS Servers. In Proc. USENIX Annual Technical Conference, Berkeley, CA, June 2002. Bottom line: It's ok but not great. "We con- clude that DNS is good for very coarse-grained server selection, since 64% of the associations belong to the same Autonomous System. DNS is less useful for finer- grained server selection, since only 16% of the client and local DNS associations are in the same network-aware cluster [13] (based on BGP routing information from a wide set of routers)" We did a wardriving study in Pittsburgh recently where we found that, of the access points we could connect to, 99% of them used their ISP's provided DNS server. Pretty good if your target is residential users: http://www.cs.cmu.edu/~dga/papers/han-imc2008-abstract.html (it's a small part of the paper in section 4.3). -Dave
On Nov 8, 2009, at 4:59 PM, David Andersen wrote:
Z. M. Mao, C. D. Cranor, F. Douglis, and M. Rabinovich. A Precise and Efficient Evaluation of the Proximity between Web Clients and their Local DNS Servers. In Proc. USENIX Annual Technical Conference, Berkeley, CA, June 2002.
Given that paper is 7 years old and the Internet has changed a bit since 2002 (and the DNS looks to change somewhat drastically in the relatively near future) it might be dangerous to rely too much on their results. This might be an interesting area of additional research... Regards, -drc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Nov 8, 2009 at 9:35 PM, David Conrad <drc@virtualized.org> wrote:
On Nov 8, 2009, at 4:59 PM, David Andersen wrote:
Z. M. Mao, C. D. Cranor, F. Douglis, and M. Rabinovich. A Precise and Efficient Evaluation of the Proximity between Web Clients and their Local DNS Servers. In Proc. USENIX Annual Technical Conference, Berkeley, CA, June 2002.
Given that paper is 7 years old and the Internet has changed a bit since 2002 (and the DNS looks to change somewhat drastically in the relatively near future) it might be dangerous to rely too much on their results. This might be an interesting area of additional research...
Well, the marketing folks have sure taken advantage of it. It would be nice to see the technology folks... not just lie there and take it. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFK96suq1pz9mNUZTMRAni8AKDyw1NMu2FuXFVQ8vDjLSOONy8T2ACg+tNJ 2sJl1I22u18nJw0PPg1juL4= =QI6K -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
On Sun, Nov 8, 2009 at 4:06 PM, Dave Temkin <davet1@gmail.com> wrote:
He also assumes that DNS is some great expense and that by not allowing tons of caching we're taking money out of peoples' wallets. This is just not true with the exception of very few companies whose job it is to answer DNS requests.
And of course in many cases these are the same people who are benefiting significantly by the geo-aware (and sometimes, network-aware) CDN's that this type of DNS service provides. Scott.
On Sun, Nov 8, 2009 at 6:06 PM, Dave Temkin <davet1@gmail.com> wrote:
In most cases it already is. He completely fails to address the concept of Anycast DNS and assumes people are using statically mapped resolvers.
He also assumes that DNS is some great expense and that by not allowing tons of caching we're taking money out of peoples' wallets. This is just not true with the exception of very few companies whose job it is to answer DNS requests.
I don't know why Paul is so concerned, just think how many F root mirrors it helps him sell to unsuspecting saps. The Henry Ford analogy was amazingly apt, imagine 'ol Henry coming back and claiming that automatic transmissions were a misuse of the automobile. Drive Slow ('cause someone left the door open at the old folks home)
Alex Balashov wrote:
For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS?
-- Alex
In most cases it already is. He completely fails to address the concept of Anycast DNS and assumes people are using statically mapped resolvers.
I'm not sure that's a correct assumption.
He also assumes that DNS is some great expense and that by not allowing tons of caching we're taking money out of peoples' wallets. This is just not true with the exception of very few companies whose job it is to answer DNS requests.
It's kind of the same sort of thing that led to what is commonly called the "Kaminsky" vulnerability; the fact that it was predicted years before continues to be ignored. The reason that's relevant is because the resource consumption argument in question is the same one; in the last ten years, bandwidth, CPU, and memory resources have all moved by greater than an order of magnitude in a favorable direction for DNS operators. Paul's argument is best considered on an idealistic basis. For example, with the CDN stuff, people who muck with DNS should absolutely be aware of what Paul is saying; that does not mean that there aren't equally valid reasons to treat DNS in a different manner. The technical problems related to CDN-style use of DNS lookups are pretty well known and understood. The resource consumption issues are trivialized with the advent of high speed Internet, cheaper resources, etc. It doesn't make it idealistically *right*, but it means it is really much less damaging than ten or fifteen years ago. To classify NXDOMAIN mapping and CDN "stupid DNS tricks" in the same class of "DNS lies" is probably damaging to any debate. The former is evil for breaking a lot of things, the latter ia only handing out varied answers for questions one should have the answer to. It's the difference between being authorized to answer and just handing out answers that Paul objects to, and being unauthorized to answer and handing out answers that many people object to. My opinion is that it'd be better for Paul to avoid technical arguments that were weak even in the '90's to support his position. As it stands, people read outdated technical bits and say "well, we know better," which trivializes the remaining technical and idealistic bits. That's damaging, because Paul's dead on about a lot of things. DNS is essentially the wrong level at which to be doing "my web browser could not find X" mapping; it'd be better to build this into web browsers instead. But that's a discussion and a half. :-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of. i knew that the "incoherent DNS" market would rise up on its hind legs and say all kinds of things in its defense against the ACM Queue article, and i'm not going to engage with every such speaker. there three more-specific replies below. Dave Temkin <davet1@gmail.com> writes:
Alex Balashov wrote:
For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS?
In most cases it already is. He completely fails to address the concept of Anycast DNS and assumes people are using statically mapped resolvers.
"anycast DNS" appears to mean different things to different people. i didn't mention it because to me anycast dns is a bgp level construct whereby the same (coherent) answer is available from many servers having the same IP address but not actually being the same server. see for example how several root name servers are distributed. <http://www.root-servers.org/>. if you are using "anycast DNS" to mean carefully crafted (noncoherent) responses from a similarly distributed/advertised set of servers, then i did address your topic in the ACM Queue article. David Andersen <dga@cs.cmu.edu> writes:
This myth ... was debunked years ago:
"DNS Performance and the Effectiveness of Caching" Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris http://pdos.csail.mit.edu/papers/dns:ton.pdf
my reason for completely dismissing that paper at the time it came out was that it tried to predict the system level impact of DNS caching while only looking at the resolver side and only from one client population having a small and uniform user base. show me a "trace driven simulation" of the whole system, that takes into account significant authority servers (which would include root, tld, and amazon and google) as well as significant caching servers (which would not include MIT's or any university's but which would definitely include comcast's and cox's and att's), and i'll read it with high hopes. note that ISC SIE (see http://sie.isc.org/ may yet grow into a possible data source for this kind of study, which is one of the reasons we created it.) Simon Lyall <simon@darkmere.gen.nz> writes:
I heard some anti-spam people use DNS to distribute big databases of information. I bet Vixie would have nasty things to say to the guy who first thought that up.
someone made this same comment in the slashdot thread. my response there and here is: the MAPS RBL has always delivered coherent responses where the answer is an expressed fact, not kerned in any way based on the identity of the querier. perhaps my language in the ACM Queue article was imprecise ("delivering facts rather than policy") and i should have stuck with the longer formulation ("incoherent responses crafted based on the identity of the querier rather than on the authoritative data"). -- Paul Vixie KI6YSY
Hi, Paul - I share your dislike of DNS services that break the DNS model for profit in ways that break applications. For instance, returning the IP address of your company's port-80 web server instead of NXDOMAIN not only breaks non-port-80-http applications, it also breaks the behaviour that browsers such as IE and Firefox expect, which is that if a domain isn't found, they'll do something that the user chooses, such as sending another query to the user's favorite search engine. There is one special case for which I don't mind having DNS servers lie about query results, which is the phishing/malware protection service. In that case, the DNS response is redirecting you to the IP address of a server that'll tell you "You really didn't want to visit PayPa11.com - it's a fake" or "You really didn't want to visit dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware". It's technically broken, but you really _didn't_ want to go there anyway. It's a bit friendlier to administrators and security people if the response page gives you the IP address that the query would have otherwise returned, though obviously you don't want it to be a clickable hyperlink. However, I disagree with your objections to CDN, and load balancers in general - returning the address of the server that example.com thinks will give you the best performance is reasonable. (I'll leave the question of whether DNS queries are any good at determining that to the vendors.) Maintaining a cachable ns.example.com record in the process is friendly to everybody; maintaining cachable A records is less important. If reality is changing rapidly, then the directory that points to the reality can reasonably change also. On Mon, Nov 9, 2009 at 12:00 PM, Paul Vixie <vixie@isc.org> wrote:
i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of.
Well, there's the built-in GPS navigation system that tells you to go drive off the dock into the water, because it wasn't smart enough to know that the route the map database showed in dotted lines was a ferryboat... -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
On Mon, 09 Nov 2009 15:04:06 PST, Bill Stewart said:
For instance, returning the IP address of your company's port-80 web server instead of NXDOMAIN not only breaks non-port-80-http applications
Remember this...
There is one special case for which I don't mind having DNS servers lie about query results, which is the phishing/malware protection service. In that case, the DNS response is redirecting you to the IP address of a server that'll tell you "You really didn't want to visit PayPa11.com - it's a fake" or "You really didn't want to visit dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware". It's technically broken, but you really _didn't_ want to go there anyway. It's a bit friendlier to administrators and security people if the response page gives you the
Returning bogus non-NXODMAIN gives non-port-80-http apps heartburn as well.
Shouldn't such apps be checking the content they receive back from a server anyway? Regardless of if they think they're getting to the right server (due to a bogus non-NXDOMAIN response) there should be some sort of validation in place.. otherwise you're open in any sort of man-in-the-middle attack. I think the issue is more that older apps would expect that if they can get a response then everything is ok.. perhaps this simply an outdated method and needs to be rethought. Valdis.Kletnieks@vt.edu wrote:
On Mon, 09 Nov 2009 15:04:06 PST, Bill Stewart said:
For instance, returning the IP address of your company's port-80 web server instead of NXDOMAIN not only breaks non-port-80-http applications
Remember this...
There is one special case for which I don't mind having DNS servers lie about query results, which is the phishing/malware protection service. In that case, the DNS response is redirecting you to the IP address of a server that'll tell you "You really didn't want to visit PayPa11.com - it's a fake" or "You really didn't want to visit dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware". It's technically broken, but you really _didn't_ want to go there anyway. It's a bit friendlier to administrators and security people if the response page gives you the
Returning bogus non-NXODMAIN gives non-port-80-http apps heartburn as well.
Andrew Cox wrote:
I think the issue is more that older apps would expect that if they can get a response then everything is ok.. perhaps this simply an outdated method and needs to be rethought.
The app is expecting a response of some kind. When it gets back bogus information that has it connecting to an IP that may not respond at all, the app will have to sit around waiting on a timeout. Jack
When I write applications that make DNS queries, I expect the request to turn NXDOMAIN if the host does not exist - HTTP as well as non-HTTP, but especially non-HTTP. Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
On 11/9/09 6:06 PM, Alex Balashov wrote:
Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial.
Because some people want the ability and choice to block DNS responses they don't like; just as they have the ability and choice to reject email they don't want to accept. When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is. -David
On 11/9/09 6:06 PM, Alex Balashov wrote:
Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial.
Because some people want the ability and choice to block DNS responses they don't like; just as they have the ability and choice to reject email they don't want to accept.
When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. Dealing with 10k~ uni students who like to spread new viruses faster
David Ulevitch wrote: than STD's I often make light of the fact that we can use OpenDNS to a) keep tabs on who's infected at what sites and b) prevent them from possibly doing more damage by phoning home with info or to collect instructions.
To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is.
-David
It's as David says, there are a lot of us who would rather have the choice than not have it. If that's not acceptable to some then that's their decision however as a part of our network this DNS 'tomfoolery' is something that both we and the end user see benefits from so I don't see it going away anytime soon. Regards, Andrew Cox AccessPlus HNA
On Mon, 09 Nov 2009 18:15:09 -0500 David Ulevitch <davidu@everydns.net> wrote:
On 11/9/09 6:06 PM, Alex Balashov wrote:
Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial.
Because some people want the ability and choice to block DNS responses they don't like; just as they have the ability and choice to reject email they don't want to accept.
When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home.
To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is.
In which case, make your own nameserver authoritative for those domains; do not foist your own wishes on other people. -- John
When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home.
To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is.
In which case, make your own nameserver authoritative for those domains; do not foist your own wishes on other people.
Since people need to *explicitly* choose using the OpenDNS servers, I can hardly see how anybody's wishes are foisted on these people. If you don't like the answers you get from this (free) service, you can of course choose to use a different service - for instance your ISP's name servers. (I may or may not agree with what OpenDNS does - that is completely irrelevant in this case.) Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Since people need to *explicitly* choose using the OpenDNS servers, I can hardly see how anybody's wishes are foisted on these people.
If you don't like the answers you get from this (free) service, you can of course choose to use a different service - for instance your ISP's name servers.
What if your ISP's name servers are those from OpenDNS?
Run your own nameservers or get a different ISP that doesn't force you to be filtered :-) -----Original Message----- From: Florian Weimer [mailto:fw@deneb.enyo.de] Sent: Wednesday, November 11, 2009 12:49 PM To: sthaug@nethelp.no Cc: nanog@nanog.org Subject: Re: What DNS Is Not
Since people need to *explicitly* choose using the OpenDNS servers, I can hardly see how anybody's wishes are foisted on these people.
If you don't like the answers you get from this (free) service, you can of course choose to use a different service - for instance your ISP's name servers.
What if your ISP's name servers are those from OpenDNS? http://slash128.com
On Nov 11, 2009, at 3:48 PM, Florian Weimer wrote:
Since people need to *explicitly* choose using the OpenDNS servers, I can hardly see how anybody's wishes are foisted on these people.
If you don't like the answers you get from this (free) service, you can of course choose to use a different service - for instance your ISP's name servers.
What if your ISP's name servers are those from OpenDNS?
1) You can personally opt-out of OpenDNS' NXDOMAIN stuff & such. 2) I don't really see how that makes a difference. The point is, OpenDNS is not forcing anyone. Your ISP has a policy you don't like, use a different ISP. If there is no other ISP, well, I don't know what to tell you? Start one? Move? End of day, it is an OPT-IN service. If you happen to "opt-in" by buying service from your ISP, that does not change the basic premise. -- TTFN, patrick
Since people need to *explicitly* choose using the OpenDNS servers, I can hardly see how anybody's wishes are foisted on these people.
If you don't like the answers you get from this (free) service, you can of course choose to use a different service - for instance your ISP's name servers.
What if your ISP's name servers are those from OpenDNS?
Then I guess you need to vote with your wallet and find a different ISP. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On Wed, 11 Nov 2009 21:48:39 +0100, Florian Weimer said:
Since people need to *explicitly* choose using the OpenDNS servers, I can hardly see how anybody's wishes are foisted on these people.
If you don't like the answers you get from this (free) service, you can of course choose to use a different service - for instance your ISP's name servers.
What if your ISP's name servers are those from OpenDNS?
# vi /etc/resolv.conf
On 11/11/09 12:48 PM, Florian Weimer wrote:
Since people need to *explicitly* choose using the OpenDNS servers, I can hardly see how anybody's wishes are foisted on these people.
If you don't like the answers you get from this (free) service, you can of course choose to use a different service - for instance your ISP's name servers.
What if your ISP's name servers are those from OpenDNS?
We don't sell service to ISPs. That's a deliberate decision. But you already knew that. -David
* David Ulevitch:
On 11/11/09 12:48 PM, Florian Weimer wrote:
Since people need to *explicitly* choose using the OpenDNS servers, I can hardly see how anybody's wishes are foisted on these people.
If you don't like the answers you get from this (free) service, you can of course choose to use a different service - for instance your ISP's name servers.
What if your ISP's name servers are those from OpenDNS?
We don't sell service to ISPs. That's a deliberate decision. But you already knew that.
No, I'm genuinely surprised, really. After all, there is <http://www.opendns.com/customers/industry/3/>. Generally, I've got less knowledge about OpenDNS than you might think.
On 11/10/09 8:05 AM, John Peach wrote:
On Mon, 09 Nov 2009 18:15:09 -0500 David Ulevitch<davidu@everydns.net> wrote:
On 11/9/09 6:06 PM, Alex Balashov wrote:
Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial.
Because some people want the ability and choice to block DNS responses they don't like; just as they have the ability and choice to reject email they don't want to accept.
When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home.
To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is.
In which case, make your own nameserver authoritative for those domains; do not foist your own wishes on other people.
Umm... That's precisely what I've done. Please read the thread. -David
On Mon, Nov 09, 2009 at 06:15:09PM -0500, David Ulevitch <davidu@everydns.net> wrote a message of 18 lines which said:
When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home.
That's an extremely bad idea: many of the domains generated by the Conficker algorithm are already registered by a legitimate registrant (in .FR: the national railways, a national TV, etc). Also, the example is not a good choice since Conficker now mostly uses P2P: <http://mtc.sri.com/Conficker/P2P/> for those who like assembly code and awful technical details.
When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home.
That's an extremely bad idea: many of the domains generated by the Conficker algorithm are already registered by a legitimate registrant (in .FR: the national railways, a national TV, etc).
It's an idea that needs to be used *with caution*. We did something similar as part of testing a new DNS product, and found that any such list of domain names needed to be *manually* vetted before being used as input to a DNS-based blackhole system. We also found that we had to explicitly whitelist a number of domains (generated by Conficker but registered many years ago and pretty clearly legit). Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On 11/10/09 9:04 AM, sthaug@nethelp.no wrote:
When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home.
That's an extremely bad idea: many of the domains generated by the Conficker algorithm are already registered by a legitimate registrant (in .FR: the national railways, a national TV, etc).
It's an idea that needs to be used *with caution*. We did something similar as part of testing a new DNS product, and found that any such list of domain names needed to be *manually* vetted before being used as input to a DNS-based blackhole system. We also found that we had to explicitly whitelist a number of domains (generated by Conficker but registered many years ago and pretty clearly legit).
This is correct. And we take this into consideration in determining what to block using our existing datasets, which are sufficient considering the volume of DNS traffic that crosses our network. -David
Alex Balashov wrote:
When I write applications that make DNS queries, I expect the request to turn NXDOMAIN if the host does not exist - HTTP as well as non-HTTP, but especially non-HTTP.
Actually, the one I hate is when they return NXDOMAIN for any RR type other than A, breaking DNS. Most common is AAAA to return NXDOMAIN, which immediately has the effect of breaking the ability to fallback to A (why query for another RR, when the domain doesn't exist?). Several high end load balancers have the ability to do this according to the content providers I have addressed the matter with. As a side note, any IPv6 capable stack which has determined there is IPv6 connectivity (through 6to4, native, teredo, etc) cannot access these sites. For an example (an ongoing issue) see www.txu.com. Responds to A, gives NXDOMAIN to AAAA. I will not shame the high profile websites that have fixed their loadbalancers/DNS servers, but everyone on this list knows and has probably used them. Jack
On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote:
i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of.
i knew that the "incoherent DNS" market would rise up on its hind legs and say all kinds of things in its defense against the ACM Queue article, and i'm not going to engage with every such speaker.
Paul: I completely agree with you that putting wildcards into the roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. Users have little (no?) choice on their TLDs. Stopping those is a Good Thing, IMHO. However, I own a domain (or couple hundred :). I have a wildcard on my domain. I point it where I want. I feel not the slightest twinge of guilt at this. Do you think this is a Bad Thing, or should this be allowed? Also, why are you upset at OpenDNS. People _intentionally_ select to use OpenDNS, which is clear in its terms of service, and even allows users to turn off the bits that annoy you. Exactly what is the issue? And lastly, DNS is not "truth". DNS is the Domain Name System, it is what people configure it to be. You yourself have argued things like responding with "192.0.2.1" for DNSBLs that are being shut down. That is clearly NOT "truth". -- TTFN, patrick P.S. Yes, I am intentionally ignoring the CDN side of things. Find me in private, preferably with a shot of single-malt, if you want my opinion.
there three more-specific replies below.
Dave Temkin <davet1@gmail.com> writes:
Alex Balashov wrote:
For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS?
In most cases it already is. He completely fails to address the concept of Anycast DNS and assumes people are using statically mapped resolvers.
"anycast DNS" appears to mean different things to different people. i didn't mention it because to me anycast dns is a bgp level construct whereby the same (coherent) answer is available from many servers having the same IP address but not actually being the same server. see for example how several root name servers are distributed. <http://www.root-servers.org/>. if you are using "anycast DNS" to mean carefully crafted (noncoherent) responses from a similarly distributed/advertised set of servers, then i did address your topic in the ACM Queue article.
David Andersen <dga@cs.cmu.edu> writes:
This myth ... was debunked years ago:
"DNS Performance and the Effectiveness of Caching" Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris http://pdos.csail.mit.edu/papers/dns:ton.pdf
my reason for completely dismissing that paper at the time it came out was that it tried to predict the system level impact of DNS caching while only looking at the resolver side and only from one client population having a small and uniform user base. show me a "trace driven simulation" of the whole system, that takes into account significant authority servers (which would include root, tld, and amazon and google) as well as significant caching servers (which would not include MIT's or any university's but which would definitely include comcast's and cox's and att's), and i'll read it with high hopes. note that ISC SIE (see http://sie.isc.org/ may yet grow into a possible data source for this kind of study, which is one of the reasons we created it.)
Simon Lyall <simon@darkmere.gen.nz> writes:
I heard some anti-spam people use DNS to distribute big databases of information. I bet Vixie would have nasty things to say to the guy who first thought that up.
someone made this same comment in the slashdot thread. my response there and here is: the MAPS RBL has always delivered coherent responses where the answer is an expressed fact, not kerned in any way based on the identity of the querier. perhaps my language in the ACM Queue article was imprecise ("delivering facts rather than policy") and i should have stuck with the longer formulation ("incoherent responses crafted based on the identity of the querier rather than on the authoritative data"). -- Paul Vixie KI6YSY
From: "Patrick W. Gilmore" <patrick@ianai.net> Date: Mon, 9 Nov 2009 18:24:52 -0500
On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote:
i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of.
i knew that the "incoherent DNS" market would rise up on its hind legs and say all kinds of things in its defense against the ACM Queue article, and i'm not going to engage with every such speaker.
Paul: I completely agree with you that putting wildcards into the roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. Users have little (no?) choice on their TLDs. Stopping those is a Good Thing, IMHO.
However, I own a domain (or couple hundred :). I have a wildcard on my domain. I point it where I want. I feel not the slightest twinge of guilt at this. Do you think this is a Bad Thing, or should this be allowed?
Also, why are you upset at OpenDNS. People _intentionally_ select to use OpenDNS, which is clear in its terms of service, and even allows users to turn off the bits that annoy you. Exactly what is the issue?
And lastly, DNS is not "truth". DNS is the Domain Name System, it is what people configure it to be. You yourself have argued things like responding with "192.0.2.1" for DNSBLs that are being shut down. That is clearly NOT "truth".
I find it mildly amusing that my first contact with Paul was about 25 years ago when he was at DEC and I objected to his use of a wildcard for dec.com. The situations are not parallel and the Internet was a very different animal in those days (and DEC was mostly DECnet), but still I managed to maintain a full set of MX records for all of our DECnet systems. That said, I really, really get annoyed by the abuse of the DNS system. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
"Kevin Oberman" <oberman@es.net> writes:
I find it mildly amusing that my first contact with Paul was about 25 years ago when he was at DEC and I objected to his use of a wildcard for dec.com.
I was only an egg.
The situations are not parallel and the Internet was a very different animal in those days (and DEC was mostly DECnet), but still I managed to maintain a full set of MX records for all of our DECnet systems.
Based partly on my conversation with you, I ended up pulling over the list of DECnet nodes and generating MX's for each one, just to remove that wildcard. You were right, and I listened. Probably I forgot to thank you until now. Thanks. -- Paul Vixie KI6YSY
Well, If it counts Paul, thanks for vixie cron. ;) -----Original Message----- From: Paul Vixie [mailto:vixie@isc.org] Sent: Thursday, November 12, 2009 4:58 PM To: nanog@merit.edu Subject: Re: What DNS Is Not "Kevin Oberman" <oberman@es.net> writes:
I find it mildly amusing that my first contact with Paul was about 25 years ago when he was at DEC and I objected to his use of a wildcard for dec.com.
I was only an egg.
The situations are not parallel and the Internet was a very different animal in those days (and DEC was mostly DECnet), but still I managed to maintain a full set of MX records for all of our DECnet systems.
Based partly on my conversation with you, I ended up pulling over the list of DECnet nodes and generating MX's for each one, just to remove that wildcard. You were right, and I listened. Probably I forgot to thank you until now. Thanks. -- Paul Vixie KI6YSY
On Mon, Nov 09, 2009 at 06:24:52PM -0500, Patrick W. Gilmore wrote:
On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote:
i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of.
i knew that the "incoherent DNS" market would rise up on its hind legs and say all kinds of things in its defense against the ACM Queue article, and i'm not going to engage with every such speaker.
Paul: I completely agree with you that putting wildcards into the roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. Users have little (no?) choice on their TLDs. Stopping those is a Good Thing, IMHO.
However, I own a domain (or couple hundred :). I have a wildcard on my domain. I point it where I want. I feel not the slightest twinge of guilt at this. Do you think this is a Bad Thing, or should this be allowed?
notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes. Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be "a Bad Thing" and should be stopped? --bill
-----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Monday, November 09, 2009 4:32 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: What DNS Is Not
...
notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes.
Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be "a Bad Thing" and should be stopped?
Ok, devils advocate argument. Is there is a difference between being a domain "owner" (Patrick wanting to wildcard the domain he has paid for), and a domain "custodian" (Verisign for the .com example) in whether wildcards are ever acceptable in the DNS responses you provide?
On Nov 9, 2009, at 7:52 PM, Buhrmaster, Gary wrote:
-----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Monday, November 09, 2009 4:32 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: What DNS Is Not
...
notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes.
Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be "a Bad Thing" and should be stopped?
Ok, devils advocate argument.
Is there is a difference between being a domain "owner" (Patrick wanting to wildcard the domain he has paid for), and a domain "custodian" (Verisign for the .com example) in whether wildcards are ever acceptable in the DNS responses you provide?
I think this is spot on. In particular: Patrick, for some domains at least, can implement a wildcard with the full cooperation and agreement of all of the customers of sub-zones within his domain. Particularly if he doesn't resell any subdomains within it. Verisign cannot. [1] [1] As a customer of .com, my own disagreement on this is sufficient to prove that they don't have unanimous agreement. :-) -Dave
On Mon, Nov 09, 2009 at 04:52:35PM -0800, Buhrmaster, Gary wrote:
-----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Monday, November 09, 2009 4:32 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: What DNS Is Not
...
notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes.
Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be "a Bad Thing" and should be stopped?
Ok, devils advocate argument.
Is there is a difference between being a domain "owner" (Patrick wanting to wildcard the domain he has paid for), and a domain "custodian" (Verisign for the .com example) in whether wildcards are ever acceptable in the DNS responses you provide?
good question - does patrick own the domain or has he paid for the registration of mapping a string into a database? either? both? neither? I'll lay out what I just did in private email a moment ago. regardless of payment, ownership, or other considerations, we all (who manage a delegation point) are stewards of that delegation. Patrick, as steward of a domain, feels certain behaviours are acceptable when he performs them within his stewardship, yet is nonplused when another steward does the exact same thing in a different delegation. not being able to resist the analogy.... Its ok for me to practice indentured servitude in my home, yet when I see my neighbor practicing it in their home - I call the cops on her for practicing slavery. and hope that no one notices me. --bill
As someone just said to me privately: "I dislike the pedantic **** nerds pull sometimes." (The "****" is mine, not the original quote, so the Communications Committee doesn't send me a warning.) On Nov 9, 2009, at 8:10 PM, bmanning@vacation.karoshi.com wrote:
good question - does patrick own the domain or has he paid for the registration of mapping a string into a database? either? both? neither?
The argument is silly at best. I "own" the domain for the year I paid for it. You call it "stewardship". I won't argue if you want to play that game. (BTW, I seriously considered putting the word "own" in quotes, but it would have required five extra keystrokes on the iPhone and I didn't think it was worth the effort. Everyone - including Bill - knows exactly what I meant. I mean, we're not newbies or idiots or .... Oh, right. Teach me to be lazy.) Let's use "stewardship", or any other string of characters that makes you happy. The basic premise does not change. My "stewardship" of ianai.net (and it's not ".com" - one would think someone like you would realize the difference) is qualitatively different than the "stewardship" of the *TLDs. For one thing, I have every right to point any hostname in my domain at any IP address I want.[*] I could create a zone file with 36^N entries pointing them all at the same IP address. No one would blink an eye. It is not unexpected, inappropriate, or in any way "wrong". Putting "* IN A 1.2.3.4" has the exact same results for any hostname up to N letters. Consider it shorthand. Think of all the RAM I'll save! Verisign putting a domain into .com that does not exist is not only unexpected, it is inappropriate, and Just Plain Wrong. They do not "own" the zone, they have _no_right_ to put any entries in that zone that are not requested through the appropriate method. If you do not (want to) see that, we will have to agree to disagree. Also, you were so busy picking on my choice of words that you completely ignored the "choice" point. Guess you couldn't come up with any feeble semantic arguments on that one?
not being able to resist the analogy....
s/the/a really bad/
Its ok for me to practice indentured servitude in my home, yet when I see my neighbor practicing it in their home - I call the cops on her for practicing slavery. and hope that no one notices me.
Honestly, Bill, don't you think that was a little pathetic? Why don't you just compare me to Hitler and get it over with. -- TTFN, patrick [*] I'm not going to explain things like "I shouldn't point hostnames at IP addresses I do not own" (er, "steward") because anyone who brings up that point is not worth talking to. If your best counter argument is so stupid that anyone with more than three brain cells to rub together already knows, understands, and has gone right past, then please un-sub from NANOG, throw your laptop in a lake, and go get a job a HS drop out can do. Because that's all you deserve.
At 0:32 +0000 11/10/09, bmanning@vacation.karoshi.com wrote:
not being Paul, its rude of me to respond - yet you posted this to a public list ... so here goes.
Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be "a Bad Thing"...
Not being anyone who has posted on this thread on a public list... I agree that the rules for what is acceptable in the operations of DNS zones vary from zone to zone. This is because of the different relationships between the zone administrator and the entities represented in the zone and the different relationships between the zone administrator and the relying parties. (I"m just going to pick on one "reason.") For the root zone or aTLD (which themselves have differences) the relationships tend to be global, multilingual, etc. Stability and coherence here are vital for operations, because as you know being in "operations" really means "handling outages." Once a problem pops up, it might take a while (hours, days) to go from report to root cause analysis to long-term fix. If the root and TLDs have lots of "bells and whistles" then, well, this is hard, so the root and TLDs are kept simple. For a zone "lower in the stack" assumptions are different. Generally speaking, the zone represents a single entity (a government agency, store, school) who will have a varying degree of active management of what is in the zone. They may even be able to "roll back" to some point in time and see what is in the zone. On-the-fly response generation is even acceptable because they can see what mislead someone, etc. (if they zone is properly run). And by on-the-fly I am including wildcards generated answers, calculated answers or answers based on source of the request, etc., and other demographics or current load measures. As far as relying parties, think about "who do I call?" when I can't get through. They have two obvious choices - their ISP or the organization they want to reach. Calls will end up with the ISP if the issue is high up in the zone, calls might get to the organization if the problems are lower in the tree. (Because perhaps they got to the main web page but not to the department page.) This is just one reason why it's reasonable to manage different DNS zones differently, why the "rules" don't apply the same everywhere. There are many other reasons. But this is a public list. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
Sent from my iPhone, please excuse any errors. On Nov 9, 2009, at 19:32, bmanning@vacation.karoshi.com wrote:
On Mon, Nov 09, 2009 at 06:24:52PM -0500, Patrick W. Gilmore wrote:
On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote:
i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of.
i knew that the "incoherent DNS" market would rise up on its hind legs and say all kinds of things in its defense against the ACM Queue article, and i'm not going to engage with every such speaker.
Paul: I completely agree with you that putting wildcards into the roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. Users have little (no?) choice on their TLDs. Stopping those is a Good Thing, IMHO.
However, I own a domain (or couple hundred :). I have a wildcard on my domain. I point it where I want. I feel not the slightest twinge of guilt at this. Do you think this is a Bad Thing, or should this be allowed?
notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes.
Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be "a Bad Thing" and should be stopped?
Thought I was clear: Choice. I believe there is a qualitative difference between a *TLD and a second level domain. /Especially/ for the GTLDs. I guess one could argue CCTLDs are different, but I disagree. If you are in Germany, a .de is nearly as important as .com in the US. (Don't believe me? Go to www.dtag.com.) But no one has to use ianai.net. Or aa.com. Or .... A second issue is ownership. I own my domain. The .com domain is not owed by Verisign (despite what they may think :-). Again, one could make an argument that the CCTLDs are different - "owned" by their host countries. I personally disagree, but I admit that argument is less objective than the GTLDs. Do you disagree wih my logic? Do you believe Verisign should be allowed to do with .net the same things I should be allowed to do with ianai.net ? If so, please explain why. If not, uh ... Why did you ask? =) -- TTFN, patrick
On Mon, Nov 9, 2009 at 8:54 PM, Jorge Amodio <jmamodio@gmail.com> wrote:
A second issue is ownership. I own my domain.
Interesting statement, did you get a property title with your domain name ?
Just curious
I'd take that question up with your IP attorney. [ Summary: lots of lawyers and courts seem to think that domain names are property ] http://news.cnet.com/2100-1023-223597.html http://www.domainnamenews.com/legal-issues/are-domain-names-considered-prope... http://newmedialaw.proskauer.com/2008/12/articles/domain-names/appellate-wat... http://www.law.duke.edu/journals/dltr/articles/2001dltr0032.html http://pblog.bna.com/techlaw/2009/09/domain-name-deemed-tangible-property-we... -M< -- Martin Hannigan martin@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
On Mon, Nov 09, 2009 at 08:32:38PM -0500, Patrick W. Gilmore wrote:
notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes.
Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be "a Bad Thing" and should be stopped?
Thought I was clear: Choice.
I believe there is a qualitative difference between a *TLD and a second level domain. /Especially/ for the GTLDs.
so you are making the arguement that as one navigates the dns heirarchy, operational choices nearer the root affect more people. as may be. - yet we see ICANN under serious pressure to flatten out the root zone - to create the same amount of choice at the root as one might find in .COM I will echo your original question to Paul, If its a "Bad Thing" at the root or TLD, is it a "Bad Thing" in ianai.com? I would say yes it is - looking for consistency in the stewardship guidelines for any delegation. personally, I take the path less traveled and woudl suggest that a wildcard - at any delegation point - can be a useful tool. the unspoken compoent here is the diversity of expectation on what one might do with a wildcard. Is the wildcard in and of itself a "Bad Thing" or has the wildcard been used in conjunction with other heinous practice to unfairly exploit the gullible masses? I don't think it fair to blame wildcards here - they are a symptom but not the actual cause of "Bad Thing" - for that you need other bits in play. --bill
On Sun, 8 Nov 2009, Alex Balashov wrote:
For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS?
Well my first answer to that would be that GSLB scales down a lot further than anycast. And my first question would be what would the load on the global routing system if a couple of thousand (say) extra sites started using anycast for their content? Each would have their own AS (perhaps reused from elsewher in the company) and a small network or two. Routes would be added and withdrawn regularly and various "stupid BGP tricks" attempted with communitees and prefixes. I heard some anti-spam people use DNS to distribute big databases of information. I bet Vixie would have nasty things to say to the guy who first thought that up. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
On 2009-11-09, at 10:35, Simon Lyall wrote:
And my first question would be what would the load on the global routing system if a couple of thousand (say) extra sites started using anycast for their content?
Are you asking what the impact would be of a couple of thousand extra routes in the current full table of ~250,000? That sounds like noise to me (the number, not your question :-) Joe
DNS is NOT always defined by Paul... :) --bill On Sun, Nov 08, 2009 at 05:39:47PM -0500, Alex Balashov wrote:
Thought-provoking article by Paul Vixie:
http://queue.acm.org/detail.cfm?id=1647302
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
DNS is NOT always defined by Paul... :)
I agree Bill, but Paul is right on the money about how the DNS is being misused and abused to create more smoke and mirrors in the domain name biz. I really find annoying that some ISPs (several large ones among them) are still tampering with the DNS responses just to put few more coins on their coffers from click through advertising. What I'm really afraid is that all the buzz and $$ from the domain biz will create strong resistance to any efforts to develop a real directory service or better better scheme for resource naming and location. BTW simulations != real world. Cheers Jorge
Alex Balashov wrote:
Thought-provoking article by Paul Vixie:
Bah, many of the CDN's I've dealt with don't seed geographical responses based on DNS, but rather use many out of band methods for determining what response they will hand out. The primary reason for short cutting cache is to limit failures in case the system a requestor is going to goes down. And different CDN's behave differently, depending on how they deliver content, support provider interconnects, etc. I'd hardly call many of them DNS lies, as they do resolve you to the appropriate IP, and if that IP disappears, try and quickly get you to another appropriate IP. The rest of the article was informative,though. Jack
On 10/11/09 01:58, Jack Bates wrote:
And different CDN's behave differently, depending on how they deliver content, support provider interconnects, etc. I'd hardly call many of them DNS lies, as they do resolve you to the appropriate IP, and if that IP disappears, try and quickly get you to another appropriate IP.
It depends what you mean by "appropriate". It may not be "least cost" or "closest", and that can be a rude shock when the CDN traffic suddenly costs you A$5/GB (delivered from the US by undersea cable) rather than $0 (delivered from an in-country peer). DNS is the wrong answer, simply because there's no way for the user to express *their* policy. But since there no CDN support in HTTP..... -- Glen Turner <http://www.gdt.id.au/~gdt/>
Maybe Google needs to incorporate some level of CDN support into their SPDY layer... Better than DNS I would think. -brandon On 11/16/09, Glen Turner <gdt@gdt.id.au> wrote:
On 10/11/09 01:58, Jack Bates wrote:
And different CDN's behave differently, depending on how they deliver content, support provider interconnects, etc. I'd hardly call many of them DNS lies, as they do resolve you to the appropriate IP, and if that IP disappears, try and quickly get you to another appropriate IP.
It depends what you mean by "appropriate". It may not be "least cost" or "closest", and that can be a rude shock when the CDN traffic suddenly costs you A$5/GB (delivered from the US by undersea cable) rather than $0 (delivered from an in-country peer).
DNS is the wrong answer, simply because there's no way for the user to express *their* policy. But since there no CDN support in HTTP.....
-- Glen Turner <http://www.gdt.id.au/~gdt/>
-- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
Glen Turner wrote:
It depends what you mean by "appropriate". It may not be "least cost" or "closest", and that can be a rude shock when the CDN traffic suddenly costs you A$5/GB (delivered from the US by undersea cable) rather than $0 (delivered from an in-country peer).
In some cases this may be true. However, many of the CDN's I've talked to will happily update which POP my network talks to. Is automatic detection perfect? Probably not. That is why they support manual correction. Their goal is to get you the best connectivity, and they usually don't have a problem, in my experience, working with a provider to ensure the right IP ranges go to the best POP.
DNS is the wrong answer, simply because there's no way for the user to express *their* policy. But since there no CDN support in HTTP.....
See above. It appears I have no problem expressing my policy to CDN's. Corporate world often uses views to express external and internal policy. Unfortunately, it's not that easy for the CDN, so they do the best that they can, and they correct when it's important enough for a provider to say "hey, this pop isn't the best for my network!" Jack
As a follow up to this, one of the large Australian ISP's has just introduced a DNS redirection "service" for all home customers. "/The BigPond-branded landing page provides BigPond customers with organic search results, sponsored links, display advertisements and intelligent recommendations, all derived from the invalid domain input - much more helpful and friendly than a nasty 404 page error./" http://www.crn.com.au/News/160923,bigpond-redirects-typos-to-unethical-brand...
On Fri, Nov 20, 2009 at 09:49:14AM +1030, Andrew Cox wrote:
As a follow up to this, one of the large Australian ISP's has just introduced a DNS redirection "service" for all home customers.
"/The BigPond-branded landing page provides BigPond customers with organic search results, sponsored links, display advertisements and intelligent recommendations, all derived from the invalid domain input - much more helpful and friendly than a nasty 404 page error./"
*Facepalm* Maybe my browser's just doing something wrong, but when was the last time you got a "nasty 404 page error" for an NXDOMAIN response? - Matt *mumblemumble*journalists*mumblemumble*
Preemptive action or smart move ? http://googlecode.blogspot.com/2009/12/introducing-google-public-dns-new-dns... Cool IP address to remember though (8.8.8.8) Cheers Jorge
participants (33)
-
Alex Balashov -
Andrew Cox -
Bill Stewart -
bmanning＠vacation.karoshi.com -
Brandon Galbraith -
Buhrmaster, Gary -
Dave Temkin -
David Andersen -
David Conrad -
David Ulevitch -
Edward Lewis -
Florian Weimer -
Glen Turner -
Jack Bates -
Jason Granat -
Joe Abley -
Joe Greco -
John Peach -
Jorge Amodio -
Kevin Oberman -
Martin Hannigan -
Matthew Palmer -
Patrick W. Gilmore -
Paul Ferguson -
Paul Vixie -
Paul Wall -
Randy Bush -
Scott Howard -
Simon Lyall -
Stephane Bortzmeyer -
sthaug＠nethelp.no -
Valdis.Kletnieks＠vt.edu -
Warren Bailey