Just to make sure I have TTL's understood.

[D. Stussy]

"Scott Haneda" <talklists at newgeo.com> wrote in message
news:ggimuc$5rm$1 at sf1.isc.org...
> Before I go out on a limb, I wanted to ask those who know more about
> this than I do.  I added a zone change to my primary server, in this
> case, setting the TTL's pretty low, as things were going to move
> around a bit in the beginning.  Waited a few weeks after adding it.
>
> * The basic thing I am trying to understand, is *when* the slaves get
> the change, and what repercussions there are if it is slow.
>
> Here is the zone:
> ORIGIN .
> $TTL 86400      ; 1 day
> example.com              IN SOA  ns1.hostwizard.com.
> scott.hostwizard.com. (
>                                  2008112501 ; serial *** I did change
> this ***
>                                  14400      ; refresh (4 hours)
>                                  7200       ; retry (2 hours)
>                                  604800     ; expire (1 week)
>                                  3600       ; minimum (1 hour)
>                                  )
> $TTL 3600       ; 1 hour
>                          NS      ns1.hostwizard.com.
>                          NS      ns1.nacio.com.
>                          A       64.84.37.51
>
> $TTL 300        ; 5 minutes
>                          MX      10 gonepostal.hostwizard.com.
>
> $TTL 3600       ; 1 hour
>                          TXT     "v=spf1 ip4:64.84.37.0/26 ?all"

Should be changed to:  SPF    "v=spf1 ... "
Usage of TXT for spf declarations has been depreciated for 2 years now.
Why are you using "?all"?  That opens you up to forged messages (unless
you're uncertain about the record).

> $ORIGIN example.com.
> foo                     A       64.84.37.51
> bar                     A       64.84.37.51
>
>
> $TTL 300        ; 5 minutes
> www                     A       64.84.37.51
> pop                     A       64.84.37.6
> smtp                    A       64.84.37.6
>
> dig example.com MX
> That will give me back the MX you see above. In this case, I am on a
> starbucks wifi, so they use whatever NS they are using.
>
> At home, the same command, pointed to openDNS, gives back the new MX
> as well.
>
> Now, if I run dig example.com MX @ns1.hostwizard.com I also get the
> new MX
>
> Running dig example.com MX @ns1.nacio.com, which is my slave provide
> example.com. 188 IN MX 20 mx1.biz.mail.yahoo.com.
> example.com. 188 IN MX 30 mx5.biz.mail.yahoo.com.
>
> It took openDNS, all of 6 or 7 minutes to get the change, I am now,
> hours later, not seeing the change in my secondary provider.  They
> also have ns0.nacio.com, ns1.nacio.com, ns2.nacio.com and
> ns3.nacio.com, all of which answer stale for this query.

It may take up to 4 hours for your secondary to see the change.  Why?  Your
refresh value on your SOA record is set to 4 hours.  Therefore, the
secondary server(s) won't check again until 4 hours after the last zone
transfer, and when that check occurs and doesn't note a new serial number,
then they should check in 2 hour intervals thereafter.

So why did "opendns" get the change earlier:
1)  They didn't have anything cached, are not servers for your zone, and
queried your primary.
2)  If they are also secondaries, perhaps they respect NOTIFY messages,
while your secondaries do not.

> Am I correct, in that, the 300 TTL I set, is correct, and what I
> should have done to prepare for a MX change to happen with as little
> problem/delay as possible?

No.  The least delay is a TTL of 0 second, which should cause no caching of
the record at all.

> What is the setting on a slave that determines when it should see my
> change?  My logs show the notifies going over, and being accepted.

Depends on the DNS software at the secondary.  Perhaps notifies are being
ignored.  Do you know what they run?

> I also provide a secondary, and to be honest, if I wanted to stall my
> secondary from accepting a primary notify, different than the TTL, I
> would not even know how to do that.
>
> If the whois servers are listed with myself, and my secondary, and the
> secondary is now stale, for hours, what repercussions does this have?

A lame delegation or old data at your TLD's name servers.

> I think, queries that are not cached by the local resolver of a
> internet user, go back to whoever is listed in the whois.  I am also
> pretty sure it does not pick one over the other, I see no way a client
> request could pick a primary over a secondary, I believe it happens at
> random, almost in a load balanced way, or perhaps it is distance
> routed, so the closest is first.

Short of fetching the SOA record, there is nothing that tells a resolver
which name server is primary, and even that is sometimes non-conclusive
(due to faulty data).

> Either way, am I correct in that a secondary, is needed, if it is
> there, it must be in sync, as it is pretty evenly used by all clients
> requesting data from it, until their local resolver caches it?

Needed?  Yes.  (Disaster recovery)
In Sync?  It should be.  (Minor variations during an update are OK)
Used evenly?  Given enough time, yes.  (random distribution).

> Thanks, and as I said, I am just trying to understand this, so I have
> the correct date to provide a accurate support request.