John Kristoff wrote: > First, the NS RRset has differing TTL values at the parent and child. > Strictly speaking I thought this was a configuration error. Is it?
Well, 1034 says the NS RRSets (without using that term) should be consistent and that usually is read to mean having consistent RDATA. > If so, what are the potential issues in such a TTL mismatch that may > cause problems with this zone? Depending on the contents of the zone and the falvor of name servers that serve this example zone, authoritative positive responses will be accompanied by the child's NS RRSet which then will take precedence over what the requesting resolver had in its cache (learned from the parent). In this case it results in much more frequent queries to the parent, provided there are also short TTLs on the actual data RRSets or multiple names in the zone that are queried for. That might be unfriendly to the parent and to anyone experiencing the additional delay. With the tendency of low TTLs on some auth data, at least for 'dynamic' zones, I think this is something the WG could have a look at in the context of TTL recommendations for infrastructure vs. data RRSets. > A records as shown in the additional section is not a configuration > error. Is that the case? What if any issues might result from that > configuration? It drives the load on those servers serving the server's name and increases latency of the resolution process. In other cases, where there is real glue and the authoritative version of the glue data has a low TTL, esp. a lower TTL than the NS RRSet, one can effectively take a domain out of service. -Peter . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
