[vox-tech] Strange DNS lookup failures (Ubuntu Fiesty)

[Rick Moen]

Quoting Gandalf Parker (gandalf at community.net):

[Overriding domains' TTLs:]

> And I have no idea what is going on at Sonic. BUT just to argue the other 
> side, some ISPs have problems with people who misunderstand the pros and 
> cons for zone settings. New admins dont like the two-day wait on changes 
> so they set the time to live to be 1 minute. :)

> Some ISPs use a bulk default setting on such things. If I remember 
> correctly, that isnt specifically against the protocols? 

Offhand, I'm not sure about RFC implications on that matter, per se, so
I should not address that particular sub-topic in ignorance.  I don't 
enjoy it when other people make free-swinging allegations about RFC
requirements, so I will attempt to be careful to not make them, myself.

I suppose one might divide that scenario up into two cases:  (1) The
ISPs nameserver is authoritative for the domain under discussion, and
(2) it isn't, and is merely caching results from nameservers elsewhere.

In case #1, arguably the ISP has a business relationship with one or
more of the domain admins, or at least the friends/associates of the
domain admins, and so have a way of notifying them that "No, we're not
going to honour the 1 minute [or substitute some other arbitrary cutoff]
TTLs you're putting into your authoritative zonefiles".  If the customer
is not informed directly via positive communications, at least he/she
will readily observe the limitation when testing the new authoritative
nameservice using "dig" (etc.), and can decide "This service sucks; I'm
going to eschew that nameserver, and shift authoritative service
elsewhere."

In case #2, the ISP is taking people much more by surprise, and is more
likely to shoot domains in the foot unawares, e.g., when I reduce my
zonefile TTLs to 1 hour a couple of days before I re-IP, only to find
out, on the day of the change, that several major ISPs override all of
my (and everyone else's) TTLs and cache obsolete RRs for many days past
TTL expiration, just to save a few pico-cents on DNS traffic related to
my domain.

_However_, even in case #2, one could argue that the "several major
ISPs" are not injuring me, but rather their own customers, and
completely defeating the purpose of the mechanism.  

And yes, I most certainly have seen ISPs refusing to honour 1 hour TTLs,
and _even 1-day ones_ -- by, as you say "setting one for all".  It's
sadly common.

I personally don't spend time trying to find what RFC "you MUST"
provision they're violating, if any:  I'd not be able to get them to 
change their policies, anyway, even if I did.  The main point is to be
aware of the practice, compensate for it, work around it where
necessary, and personally avoid reliance on third-party nameservers that
do it.

E.g., at $FIRM, a Linux- and open-source support firm in San Francisco
that shall go nameless (  ;->  ), where I was at the time chief
sysadmin, we were obliged at one point to re-IP the main company Web
server as part of a site migration.  We did all the right things with
TTLs, but, on flag day were dismayaed to note that quite a number of
major ISPs were caching the old, obsolete reference records anyway.
Since there was nothing we could do to stop them, we simply kept the old 
server online at the former IP for several days:  Some customers got the
new site, some got the old one, but nobody got DNS resolution failure.

-- 
Cheers,                     Peter G. Neumann:  "Mars has been a tough target."
Rick Moen                   Harlan Rosenthal:  "That's because the Martians keep
rick at linuxmafia.com         shooting things down."   RISKS Digest, v. 20, #59&60