David's got it in one. So yeah, can those of you who have nameservers that don't support small TTL's have a look at flushing that zone? Thanks to those that have. Cheers Jamie On Wed, 2007-08-08 at 16:43 +1200, David Robb wrote:

On Wed, 8 Aug 2007, Nathan Ward wrote:

...

If you can't do that, at least make your DNS TTLs shorter than 86400 - some providers (apparently) don't honour that, though.

Don't make them too short though. Some nameservers won't honour TTLs of 60 seconds (for example)

--David

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On 8/8/07, Mark Foster wrote:

I'm sure my learned NZNOG colleagues can explain to me why nameservers won't honour certain TTL's?

Seems to make a bit of a mockery of the whole ability to set them, really...

Because the clueless get in on it. "Why don't you set it to 1 so we can update whenever?". -- Phillip Hutchings http://www.sitharus.com/

Jamie Baddeley wrote:

On Wed, 2007-08-08 at 20:35 +1200, Phillip Hutchings wrote:

...

On 8/8/07, Mark Foster wrote:

...

I'm sure my learned NZNOG colleagues can explain to me why nameservers won't honour certain TTL's?

Seems to make a bit of a mockery of the whole ability to set them, really...

Because the clueless get in on it. "Why don't you set it to 1 so we can update whenever?".

OK then. What nameserver daemon behaves like this?

various versions of IE cache either for 30 minutes or an hour irrespective of the times they get back from the resolver. see http://support.microsoft.com/default.aspx?kbid=263558 I believe gecko based browsers are guilty of this too (although to a lesser extent -- 10 minutes iirc).

On 8/9/07, Mark Foster wrote:

...

...

OK then. What nameserver daemon behaves like this?

various versions of IE cache either for 30 minutes or an hour irrespective of the times they get back from the resolver. see http://support.microsoft.com/default.aspx?kbid=263558 I believe gecko based browsers are guilty of this too (although to a lesser extent -- 10 minutes iirc).

Interesting that the article in question cites IE up to version 6.

Did they change this behavior in IE7?

Nope, IE7 pins DNS records for 30 minutes as well (it's configurable with the same registry key). Cheers, Bojan

Hi, guys On 8 Aug 2007, at 05:23, Nathan Ward wrote:

...

various reasons some folks at TVC would appreciate it if you could flush the information you have in your recursive/caching nameservers for the zone images.tvnz.co.nz That would help clear up some TTL badness. For those that don't know, a better way to renumber is to run your

On 8/08/2007, at 4:14 PM, jamie baddeley wrote: public facing services on both the new /and/ old addresses simultaneously, for /at least/ the TTL that your DNS zone proposes.

The long tail is weeks and weeks following a renumbering. I used to work for a huge e-tailer in the UK. One of my major projects was to move them from their single-homed hosting to a new multi-homed network. Their webserver vips were therefore renumbered from their old providers' PA address space, to their new PA space. I put a transparent proxy that was configured to just proxy their site, on the old address, and then updated dns. As expected, before the ttl expiry there was a lot of traffic on the proxy. The next morning (12 hours after moving, 1hr ttl during the move) there was still a lot of traffic. This was because many ISPs in the UK were ignoring our 1h TTL, and enforced their own 24hr+ minimum TTLs. When I had to take the proxy out - a month after the renumber - because we were handing back the old datacentre space, there was still traffic going through the proxies. Much of it bots, some of it customer traffic. Only a request or two a minute, so it represented a tiny fraction of our traffic, but traffic still existed. I put this down to some users having a browser that did infinite cacheing ? Renumbering is an imprecise science. Proxy between your old and new infrastructure for at least a month is my advice. Best wishes, Andy