Re: NS record TTL versus nameserver's A record TTL
On 08.10.13 11:49, John Wobus wrote: We received a report that a domain we serve was not resolving at a remote site. The site also reported their own analysis that the issue appeared to be that the domain's NS record had a longer TTL than its target nameserver's A record and their caching server didn't seem able to handle this. FYI, the nameserver was not within the domain with the issue. it's hard to say from this information. Maybe if you provided concrete domain name(s) we could tell more. They took responsibility for their nameserver's deficiency, but it makes me wonder: -Is this addressed by a standard? E.g., the nameserver's A record have the same TTL as NS records pointing at it. It should be the same, when the server is in the domain. I met exactly those issues when NS record had longer ttl then the A record in the same domain. -- 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. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... ___ 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: NS record TTL versus nameserver's A record TTL
Hi John, El 2013-10-08 11:49:24, John Wobus escribió: > They took responsibility for their > nameserver's deficiency, but it > makes me wonder: > -Is this addressed by a standard? E.g., > the nameserver's A record have the same > TTL as NS records pointing at it. > -Is this addressed by a "best practice"? I don't of any standard addressing this. Neither I know a best practice document on this. But due to my experience, it is a quite common practice to have longer TTL on NS records than on A records. I consider this quite normal, as often you will more often change individual host's IP address than the addresses of your nameservers. Setting longer TTLs on the NS records reduces load on the higher level DNS servers while allowing you to update entries in your zone faster. For example DynDNS uses a TTL of 60 seconds for their customer's A records while having a TTL value of 86400 seconds (1 day) on their NS records. Regards, Matthias -- Matthias Wimmer Contact details: http://matthias.wimmer.tel/ smime.p7s Description: S/MIME cryptographic signature ___ 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
NS record TTL versus nameserver's A record TTL
We received a report that a domain we serve was not resolving at a remote site. The site also reported their own analysis that the issue appeared to be that the domain's NS record had a longer TTL than its target nameserver's A record and their caching server didn't seem able to handle this. FYI, the nameserver was not within the domain with the issue. They took responsibility for their nameserver's deficiency, but it makes me wonder: -Is this addressed by a standard? E.g., the nameserver's A record have the same TTL as NS records pointing at it. -Is this addressed by a "best practice"? -If neither of the above, is there a "hidden practice that knowing folk often follow to dodge remote nameserver deficiencies"? FYI, I only received the report fourth hand and can't tell you the nameserver software that had this issue. John Wobus Cornell University IT P.S. This made me wonder what record bind puts in the additional section if it has both a glue A record for a nameserver in the zone's file and an authoritative A record for the nameserver in the nameserver's own zone file. I find by TTL finagling that it serves the authoritative A record. ___ 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
