Re: [nznog] DNS TTLs: trademe and anz
In message <45F5DAA1.9070701(a)deanpemberton.com>, Dean Pemberton writes:
I can remember a time when a similar question was raised about zero time TTLs on records. [...] It was with a bank. [...] "We want to make sure that each and every request for an IP address comes to our DNS server. We don't want it to be cached at all as this can lead to someone hijacking the cache. We like it this way"
So if someone _does_ manage to find a way to poison the cache with a record, then they can happily set a long TTL on the poison record and avoid any other lookups. And there's an almost zero chance that there'll be valid cached record there to prevent the poisoned one being cached. Seems to me some people don't think through the logical consequences of their actions. It also seems to me that anyone needing failover in less than about an hour wants a different solution than updating DNS entries (load balancer, anycast, etc). Ewen
On 13/03/2007, at 12:17 PM, Ewen McNeill wrote:
In message <45F5DAA1.9070701(a)deanpemberton.com>, Dean Pemberton writes:
I can remember a time when a similar question was raised about zero time TTLs on records. [...] It was with a bank. [...] "We want to make sure that each and every request for an IP address comes to our DNS server. We don't want it to be cached at all as this can lead to someone hijacking the cache. We like it this way"
So if someone _does_ manage to find a way to poison the cache with a record, then they can happily set a long TTL on the poison record and avoid any other lookups. And there's an almost zero chance that there'll be valid cached record there to prevent the poisoned one being cached.
Seems to me some people don't think through the logical consequences of their actions. It also seems to me that anyone needing failover in less than about an hour wants a different solution than updating DNS entries (load balancer, anycast, etc).
These solutions are about failover between sites where anycast is (a) not possible because of lack of BGP, or (b) a concern for connection oriented protocols (TCP). It's also useful to balance load between sites, as Simon suggested Google and Yahoo do. Agreed that people who make silly decisions like that are, well, silly. A fairly good example of "A little bit of knowledge is much more dangerous than none". -- Nathan Ward
On Tue, 2007-03-13 at 12:29 +1300, Nathan Ward wrote:
Seems to me some people don't think through the logical consequences of their actions. It also seems to me that anyone needing failover in less than about an hour wants a different solution than updating DNS entries (load balancer, anycast, etc).
These solutions are about failover between sites where anycast is (a) not possible because of lack of BGP,
I wonder how many sites that serve "big content" and are concerned about loadsharing are not BGP connected. Not many I suspect.
or (b) a concern for connection oriented protocols (TCP).
Correct me if I'm wrong but this is only a concern under a failure mode of an anycast node? So combined with probability of risk and ease of resolution (browser reload), is this really a big concern? jamie
On Tue, March 13, 2007 12:36, jamie baddeley wrote:
On Tue, 2007-03-13 at 12:29 +1300, Nathan Ward wrote: [cut]
or (b) a concern for connection oriented protocols (TCP).
Correct me if I'm wrong but this is only a concern under a failure mode of an anycast node? So combined with probability of risk and ease of resolution (browser reload), is this really a big concern?
TCP anycast works just fine (http://www.nanog.org/mtg-0606/levine.html)...it is FUD (spread by verislime and others) that it doesn't work. like ALL things network-related, you have to know what you are doing and understand the limitations... /joshua -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams -
On 12-Mar-2007, at 19:49, joshua sahala wrote:
TCP anycast works just fine (http://www.nanog.org/mtg-0606/levine.html)...it is FUD (spread by verislime and others) that it doesn't work.
To be fair, Verisign have an extensive anycast deployment with COM/ NET and J-root, and they naturally support queries over both TCP and UDP transports. I've never heard anybody from Verisign suggest that anycast is fundamentally incompatible with TCP.
like ALL things network-related, you have to know what you are doing and understand the limitations...
... many of which we tried to capture in RFC 4786/BCP 126. Joe
On Tue, March 13, 2007 14:56, Joe Abley wrote:
On 12-Mar-2007, at 19:49, joshua sahala wrote:
TCP anycast works just fine (http://www.nanog.org/mtg-0606/levine.html)...it is FUD (spread by verislime and others) that it doesn't work.
To be fair, Verisign have an extensive anycast deployment with COM/ NET and J-root, and they naturally support queries over both TCP and UDP transports. I've never heard anybody from Verisign suggest that anycast is fundamentally incompatible with TCP.
page 29 of the "Life and Times of J-Root" presentation would seem to suggest otherwise (http://www.nanog.org/mtg-0410/kosters.html): DO NOT RUN Anycast with Stateful Transport They then clarified, somewhat, that statement on page 36 of "Follow-up analysis of J root anycast traffic" presentation (http://www.nanog.org/mtg-0702/larson.html). They state that DNS anycast works "fine" over TCP, though they cite a decent number of TCP resets saying only that it requires more investigation/explanation (fair enough). They do still contend that "...longer-running TCP sessions may have problems" (warning those that don't engineer carefully).
like ALL things network-related, you have to know what you are doing and understand the limitations...
... many of which we tried to capture in RFC 4786/BCP 126.
which is a good document on the ins/outs of it...now if only more people would read those RFC things :) /joshua -- common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams -
On 12-Mar-2007, at 22:52, joshua sahala wrote:
page 29 of the "Life and Times of J-Root" presentation would seem to suggest otherwise (http://www.nanog.org/mtg-0410/kosters.html):
DO NOT RUN Anycast with Stateful Transport
Aha, I actually missed that meeting :-) Despite what Mark might have concluded in that self-confessed "just in time" presentation, the fact remains that Verisign continued their aggressive J-root and COM/NET anycast deployment beyond 2004, and certainly have never suggested that they don't support TCP transport to those servers. Verisign engineers are active in dnsext, in fact, and it's fair to say that DNSSEC is only going to make the proportion of queries which use TCP transport greater. Actions speak louder than words on rushed slide decks, maybe.
like ALL things network-related, you have to know what you are doing and understand the limitations...
... many of which we tried to capture in RFC 4786/BCP 126.
which is a good document on the ins/outs of it...now if only more people would read those RFC things :)
:-) Joe
On 13/03/2007, at 12:36 PM, jamie baddeley wrote:
On Tue, 2007-03-13 at 12:29 +1300, Nathan Ward wrote:
Seems to me some people don't think through the logical consequences of their actions. It also seems to me that anyone needing failover in less than about an hour wants a different solution than updating DNS entries (load balancer, anycast, etc).
These solutions are about failover between sites where anycast is (a) not possible because of lack of BGP,
I wonder how many sites that serve "big content" and are concerned about loadsharing are not BGP connected. Not many I suspect.
or (b) a concern for connection oriented protocols (TCP).
Correct me if I'm wrong but this is only a concern under a failure mode of an anycast node? So combined with probability of risk and ease of resolution (browser reload), is this really a big concern?
Ah but you didn't read the next sentence which was "It's also useful to balance load between sites, as Simon suggested Google and Yahoo do.". That's not so easy to do with anycast - the site selection is done by the network not by you (or your automagic boxes). If you don't care about that, anycast would work fine. It would work even better if you have lots of small files, ie. no long running TCP sessions. Not terribly good for people who do large files though, and is probably one of the reasons that people like Akamai use BGP-fed DNS views (or similar) for this sort of thing. Not as bad for live streaming I suppose, because people don't need to start the `download' again, or have much manual intervention (sure, having to start a download from scratch is software dependent). -- Nathan Ward
participants (5)
-
Ewen McNeill -
jamie baddeley -
Joe Abley -
joshua sahala -
Nathan Ward