Re: NAT Multihoming

[Donald Stahl]

The last time I renumbered, I found that quite a few people were not
honoring the TTLs I put in my DNS zone files. [...] Custom customer
zone files hosted elsewhere?


Do not forget that applications have their own caches, too, and they
typically ignore completely the DNS TTL. A typical Web brower calls
getaddrinfo() once and use the IP address as long as it is not
restarted.
Not to mention java's caching which has screwed me up more times than I 
care to think about. I sincerley wish Sun had disabled it by default- I 
really don't think it's the JRE's responsibility to cache name service 
lookups- at least not by default.


-Don

Re: NAT Multihoming

[Iljitsch van Beijnum]

On 4-jun-2007, at 4:33, Stephen Satchell wrote:

The last time I renumbered, I found that quite a few people were  
not honoring the TTLs I put in my DNS zone files.  I would clone  
the new address and monitor traffic to the old address -- and it  
took up to seven days for the traffic to the old address to die  
down enough that I could take it out.


Are you sure this was the result of DNS servers increasing the TTL,  
not simply applications doing their own caching?

Re: NAT Multihoming

[Stephane Bortzmeyer]

On Sun, Jun 03, 2007 at 07:33:45PM -0700,
 Stephen Satchell <[EMAIL PROTECTED]> wrote 
 a message of 29 lines which said:

> The last time I renumbered, I found that quite a few people were not
> honoring the TTLs I put in my DNS zone files. [...] Custom customer
> zone files hosted elsewhere?

Do not forget that applications have their own caches, too, and they
typically ignore completely the DNS TTL. A typical Web brower calls
getaddrinfo() once and use the IP address as long as it is not
restarted.

Re: NAT Multihoming

[Donald Stahl]

You write "when" rather than "if" - is ignoring reasonable TTLs
current practice?


Definitely.  We've seen 15 minute TTLs regularly go 48 hours without updating 
on Cox or Comcast's name servers.  I believe the most I've seen was 8 days 
(Cox).
I definitely meant "when" not if. And Cox is by no means the only ISP to 
do this.


-Don

Re: NAT Multihoming

[Stephen Satchell]

Chris Owen wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jun 3, 2007, at 4:19 PM, Simon Leinen wrote:


You write "when" rather than "if" - is ignoring reasonable TTLs
current practice?


Definitely.  We've seen 15 minute TTLs regularly go 48 hours without 
updating on Cox or Comcast's name servers.  I believe the most I've seen 
was 8 days (Cox).


The last time I renumbered, I found that quite a few people were not 
honoring the TTLs I put in my DNS zone files.  I would clone the new 
address and monitor traffic to the old address -- and it took up to 
seven days for the traffic to the old address to die down enough that I 
could take it out.  This is based on a server farm of, at the time, 162 
servers.


Custom customer zone files hosted elsewhere?  I had a few of those, the 
effect of which is not included in the observation above.


By the way, I standardized on a customer zone TTL of 14400 (four hours) 
for all zones.  That provided a good balance betwen agility and master 
DNS server load.  rDNS is currently 172800 (two days).  DNS A records 
are 432000 (5 days).

Re: NAT Multihoming

[Randy Bush]

>> You write "when" rather than "if" - is ignoring reasonable TTLs
>> current practice?
> Definitely.  We've seen 15 minute TTLs regularly go 48 hours without
> updating on Cox or Comcast's name servers.  I believe the most I've seen
> was 8 days (Cox).

i wish all my competitors did that.

randy

Re: NAT Multihoming

[Chris Owen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jun 3, 2007, at 4:19 PM, Simon Leinen wrote:


You write "when" rather than "if" - is ignoring reasonable TTLs
current practice?


Definitely.  We've seen 15 minute TTLs regularly go 48 hours without  
updating on Cox or Comcast's name servers.  I believe the most I've  
seen was 8 days (Cox).


Chris


Chris Owen ~ Garden City (620) 275-1900 ~  Lottery (noun):
President  ~ Wichita (316) 858-3000 ~A stupidity tax
Hubris Communications Inc  www.hubris.net





-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFGYzdMElUlCLUT2d0RArCzAJ4rqL4eWxMzswEwibiZfYIk43bvpwCaA8Ix
UkBbPlRGOiuL+6RSPZoNR7c=
=TmiM
-END PGP SIGNATURE-

Re: NAT Multihoming (was:Re: NANOG 40 agenda posted)

[Paul Vixie]

> Cisco has a whitepaper entitled "Enabling Enterprise Multihoming with Cisco 
> IOS NAT" that addresses this.  See 
> http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a0080091c8a.shtml
> as well as RFC2260.

see also .

> There are indeed a few thorny issues with this approach; the largest
> issue is that all connectivity becomes DNS-dependent and raw IP addresses
> (from both the inside and outside) become virtually useless.  Running
> servers behind this scheme, while doable, is difficult.

and also much fun to watch, once you get it working.
-- 
Paul Vixie