Bob Goodwin:
> Assuming the Newegg problem was due to an address change, should the
> Wildblue dns have caught up with it sooner?
That depends... DNS records have time-to-live data, that says how long
records should be cached for. So, if a website's record say cache me
for 15 days, then that's what the downstream servers, and clients,
should do. Of course, that time period begins from the first access.
So if one server accesses it last Tuesday, and another accessed it on
Saturday, the absolute dates of expiry will be different, between them.
Lump on top of that, intermediate DNS servers which may be between you
and them, that each cache the records. And lump, on top of that, too,
servers which cache things for longer than told to (bad administration
practices), and it becomes even messier.
That's the simplistic explanation. There's four time periods in DNS
records. I've used just one of them, in the explanation above. In all,
there's:
* How long before trying to "refresh" the records.
* How long to wait before trying to get new records ("retry"), if the
master server didn't respond.
* How long to serve stale records for (i.e. after they expire, how much
longer to keep serving them, in the absence of being able to acquire new
data). After this, /no answer/ is returned for the query, it doesn't
exist anymore ("retire").
* How long other servers/clients should use the information provided to
them from this server (time-to-live, "TTL"), if they're not able to get
fresh data from another master server.
There are some other interpretations of what those four time periods
mean, they're not brilliantly explained in some text books, and that's
been my best guess at interpreting the explanation I read (long ago), so
you'll find some servers and clients behaving differently. Some just
blatantly ignore the data, and do whatever they damn well feel like.
There'll be servers which cache them for a set time period, no matter
what. And clients, such as some web browsers, have their own settings
for caching (the Opera web browser gives you some choices about this in
the preferences, or used to).
Changing IPs is a bad thing, best avoided. If you must do it, then the
only way to attempt to do it cleanly, is well ahead of your expiry date.
So that things just switch over. If you're hoping to change over
quicker than that, you really can't expect it to work. And, in the
meantime, your services should be listening out on both IPs.
So, it's rarely a good idea to give lengthy times for records. Admins
faced with a looming change may try shortening the time periods ahead of
the date, but it's no good trying to set a 1 day period if the rest of
the world has cached your records for 30 days, they're going to use what
they learnt the first time around (that this data is good for 30 days).
Admins anticipating that there might be a need to change records may set
shortish time periods from the get-go. It's not unusual to see records
that only live for a day, for ordinary websites. And for records tied
to dynamic addresses, that they know will change at the drop of the hat,
or want to spread across multiple servers, may have records set to last
just a few minutes, or even seconds (seems a bit overzealous, to me).
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
