Quoting Gandalf Parker ([EMAIL PROTECTED]): [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 [EMAIL PROTECTED] shooting things down." RISKS Digest, v. 20, #59&60 _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
