Such things are only supposed to take 24/48 hours.
Patently false - DNS only guarantees updates within the old record's time to live (TTL), which is typically about the one week timeframe. Even though things often take less time, it's not actually a flaw that it takes a week.
Also, it's entirely possible that LJ's outgoing mail server has the sensible policy of retrying on a growing window, so that it tried sending, failed, waited a day, retried, failed, waited two days, failed, waited four days, succeeded.
In any case, it could happen anywhere along the pipeline from the LJ servers to the master DNS servers. It could be their DNS servers, if they keep one, but more likely it is their provider's DNS cache. In any case, telling somebody that it took a week for an updated DNS record to be registered is not likely to make anybody too concerned, unless you know that the old DNS record had a TTL that was shorter.
For example, your current DNS record has a TTL of 86388 seconds, or 12 seconds shy of a day. OTOH, the TTL of colobus.isomerica.net, the underlying host, is 544346 seconds, or 6.3 days (not atypical). If your old host had a similar TTL for nchanted.net, then this is actually expected behavior. (Which isn't unreasonable - after all, you register with them for at least a month, if not a year, at a time.)
Well, um, it was still annoying. :-P
Yeah, but we already said it had to do with computers, right?
Actually the TTL for isomerica.net is 604800 seconds, which is exactly 7 days. And the TTL for nchanted.net is currently 86400, exactly one day. I think you're probably seeing smaller numbers because dig displays the TTL remaining if the result is already cached. To get the real TTL you need to do an AXFR from the authoritative nameserver for the domain.
Unfortunately, lots of caching servers, resolver libraries, and clients don't actually obey the TTL, or do more caching on top. This means TTLs are frequently useless and the trick mentioned below often doesn't work. Of course, the trick is still useful much of the time. I was only involved on the receiving end, so didn't set that up.
2006-03-30 04:26 pm (UTC)
For domains I administer, I usually keep TTLs a few days long, but when I know I'm going to be moving things around, I reduce all the TTLs to an hour a few days before the move. Then, after the move has settled down, I bring them back up. I thought this was pretty standard DNS administration practice.
I think it's pretty clever, but not common. Also, it only works if the people administering the DNS record are given enough lead time, which isn't always the case - I don't know about this specific case, obviously.
Huh, yeah, the TTL was a week. I thought about dropping it before the move but I thought I had set it to 24 hours and didn't think it was worth messing with.