Re: Expiration TTLs
On 02.12.12 18:10, Paul Romano wrote: Thanks for the correction on the term TTL instead of timer. The engineer I inherited this environment from has the refresh set to 40 minutes and the zone expiration set to 2 hours. The explanation I got was that since we are authoritative for AD we want ensure that some kind of scavenging is in place. ... and if your primary server(s) fill fail for 2 hours, your zone will stop working. Your explanation suggests that the refresh time is strictly survivability and will not force an update if the serial numbers do not increment enough to implement the refresh. that is how DNS works. The problem with microsoft DNS servers and AD is that they do not follow this standard. Am I stating this correctly? Any suggestions? according to what I know, use 2-3 AD servers and keep DNS on them. Just make sure they will not fail at the same time... If anyone has better info on how do microsoft AD sevrers work with DNS, just let us know... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows found: (R)emove, (E)rase, (D)elete ___ 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
Re: Expiration TTLs
On Dec 2, 2012, at 6:10 PM, Paul Romano wrote: Chris. Thanks for the correction on the term TTL instead of timer. The engineer I inherited this environment from has the refresh set to 40 minutes and the zone expiration set to 2 hours. The explanation I got was that since we are authoritative for AD we want ensure that some kind of scavenging is in place. Your explanation suggests that the refresh time is strictly survivability and will not force an update if the serial numbers do not increment enough to implement the refresh. Am I stating this correctly? Any suggestions? No, that's not quite right. Here are some definitions: - Refresh timer: Controls how often a slave or stub server will check in with its configured master(s) to see if the zone has been updated, in the absence of a notify message. This check is an SOA query. This is related to master/slave and master/stub zone replication. If the serial number in the retrieved SOA record is larger than the serial number the server currently has -- even by 1 -- it triggers either a zone transfer (slave) or further queries for NS and A records (stub). - Retry timer: If a refresh check fails, the slave or stub server will start the retry timer instead of the refresh timer. When it runs out, the server tries again to refresh from its master(s). The purpose is to control how often a slave or stub server refreshes while the master is unavailable. - Expire timer: At every successful refresh check, this timer is reset. If the zone has not been refreshed by the time this timer runs out, the zone is expired. The server will not respond authoritatively (for slave zones); I'm not sure exactly what happens with stub servers, or whether they use this timer at all. Typically, the refresh timer is set to the longest amount of time the organization will permit a slave to be out of date compared to its master -- depending on the usage, usually somewhere between 1 hour and 1 day. The retry timer is often set to a smaller value -- often between 10 minutes and 2 hours -- but I've seen installations where it is set longer (and not due to misunderstanding). The expire timer is generally set to between 1 and 6 weeks, to allow time for a problem with a master to be noticed and corrected before a slave stops responding authoritatively. The notify mechanism, whereby an authoritative server proactively notifies other authoritative servers (typically a primary master notifying its slaves) when a zone is updated, augments this system of timers. When a notify is received, it causes a refresh check to occur immediately; this resets the timers. Note that there is no scavenging function in BIND (nothing similar to MS DNS' aging and scavenging feature set), and no way to really implement it purely in DNS. Any attempt to use the expire timer to achieve this is evidence of a profound misunderstanding of the use of these timers. Regards, Chris Buxton BlueCat Networks signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: Expiration TTLs
On Dec 1, 2012, at 12:17 PM, Paul Romano wrote: What is a good compromise on zone expiration TTLs? Our DNS is authoritative for AD DNS and we want to make sure we force records to refresh but do not want to expose ourselves to the risk of zone failures. The zone expiration timer is not a TTL timer. The two are different. Zone expiration should usually be at least a week. I've set mine to 6 weeks. This timer has nothing to do with the refresh interval, which is also defined in the SOA record. Chris Buxton BlueCat Networks ___ 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
Re: Expiration TTLs
Chris. Thanks for the correction on the term TTL instead of timer. The engineer I inherited this environment from has the refresh set to 40 minutes and the zone expiration set to 2 hours. The explanation I got was that since we are authoritative for AD we want ensure that some kind of scavenging is in place. Your explanation suggests that the refresh time is strictly survivability and will not force an update if the serial numbers do not increment enough to implement the refresh. Am I stating this correctly? Any suggestions? Thanks Paul From: Chris Buxton chris.p.bux...@gmail.com To: Paul Romano ittec...@yahoo.com Cc: bind-us...@isc.org bind-us...@isc.org Sent: Sunday, December 2, 2012 7:41 PM Subject: Re: Expiration TTLs On Dec 1, 2012, at 12:17 PM, Paul Romano wrote: What is a good compromise on zone expiration TTLs? Our DNS is authoritative for AD DNS and we want to make sure we force records to refresh but do not want to expose ourselves to the risk of zone failures. The zone expiration timer is not a TTL timer. The two are different. Zone expiration should usually be at least a week. I've set mine to 6 weeks. This timer has nothing to do with the refresh interval, which is also defined in the SOA record. Chris Buxton BlueCat Networks___ 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
Expiration TTLs
What is a good compromise on zone expiration TTLs? Our DNS is authoritative for AD DNS and we want to make sure we force records to refresh but do not want to expose ourselves to the risk of zone failures. Thanks Paul___ 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
Re: Expiration TTLs
Wes, Thanks for the quick response. Are you authoritative for AD and, if yes, how many masters do you have for the AD domain? We have a single hidden master pair for our AD and core domains and are set for 2 hours. We lost a device and never got alerts for the failure until after the zones failed. I am looking for some added security to avoid a failure but still want to make sure changes are propagated efficiently. Is there another factor that I should be using to define this value? Our refresh is set for 40 minutes. Paul From: Wes Zuber w...@uia.net To: Paul Romano ittec...@yahoo.com Cc: bind-us...@isc.org bind-us...@isc.org Sent: Saturday, December 1, 2012 3:56 PM Subject: Re: Expiration TTLs We go with 1 hour. --Wes On Dec 1, 2012, at 12:17 PM, Paul Romano ittec...@yahoo.com wrote: What is a good compromise on zone expiration TTLs? Our DNS is authoritative for AD DNS and we want to make sure we force records to refresh but do not want to expose ourselves to the risk of zone failures. Thanks Paul ___ 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___ 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
