On 02/07/2016 04:55 PM, Mark Andrews wrote:
This proves robustness in the presence of link failures.
Faster than ttl expiry of local zone changes (provided that notify
messages are sent).
I presume you are referring to the slave zone expiration timer, not
normal record TTLs.
No, I mean normal TTL.
Now I'm confused. Will you please elaborate on what you meant then?
I interpret "normal TTL" to be the TTL for a given record. Is that also
what you mean?
Are you referring to the fact that a caching recursive server will
expire the TTL before refreshing to see the new / updated zone contents?
Compared to the slave server (presumably with properly functional
notifications) seeing the same new / updated zone contents?
If you are a slave and are getting notify
messages updates happen in seconds, not minutes or hours which are
the usual range for TTL values.
Agreed.
I mis-took your statement about link failures to mean the ability to
continue serving the zone while the link was down until the zone expired.
.local doesn't have servers.
Um....
Please forgive me while I look at many Small Business Server / poorly
configured networks.
That being said, I'll give you that it's not an official TLD. (Last I
looked.)
Home zones generally aren't delegated to so there isn't a need for
seperation of rolls. Even if they are delegated to the home server
is more likely to be a stealth master so it won't be in the NS
RRset. And as with almost all rules there are exceptions.
*nod*
Hence my question about how / where SOHO recursive / authoritative
servers fall into the rule ~> exception.
--
Grant. . . .
unix || die
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
