A mail delivery puzzle

[John Abreau]

"Bill Horne" <bill at horne.net> writes:

> You're right, it was a propagation issue. It's fixed now, but I'm very
> confused: why would attbi.com cache something like ampr.org? I thought
> things like that would be looked up directly from the authoritative server.

*Everything* in DNS is cached. Otherwise the system would melt down from 
the overload on the root nameservers.

Your problem sounds similar to one we had a while ago with blu.org. 
In our case it turned out that we had a longer TTL on the NS records 
than on the corresponding A records. I had dropped the TTL on the A 
records to an hour to prepare for a server move, but forgot about the
NS records. After the change, everyone's caches expired the old A records
withing the hour, but because the NS records were still cached, nobody 
was finding the A records. The symptoms sound much like what you 
described.

Apparently this behavior is a side effect of the way DNS was designed 
to get around the chicken-and-egg problem of initially finding a 
domain's nameservers. Otherwise you'd have to query a domain's nameserver
to find out where that domain's nameservers are. Kind of like someone 
telling you, "Call me and I'll tell you my phone number".


-- 
John Abreau / Executive Director, Boston Linux & Unix 
IM: jabr at jabber.blu.org / abreauj at aim / abreauj at yahoo / 28611923 at icq
Email jabr at blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99

   Some people say, "The enemy of my enemy is my friend."
   I often respond, "When elephants fight, it's the grass
   that gets trampled."



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 344 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20020919/b57be05d/attachment.sig>