On Fri, Mar 4, 2016 at 1:25 PM, John Wobus <jw...@cornell.edu> wrote:
> > Our recursive resolver periodically returns SERVFAIL for lookups > > for hhs.gov records, which are served by these nameservers: > > > > rh202ns1.355.dhhs.gov. 168 IN A 158.74.30.98 > > rh202ns1.355.dhhs.gov. 14260 IN AAAA 2607:f220:0:1::2a > > rh202ns2.355.dhhs.gov. 168 IN A 158.74.30.99 > > rh202ns2.355.dhhs.gov. 14260 IN AAAA 2607:f220:0:1::2b > > rh120ns2.368.dhhs.gov. 81 IN A 158.74.30.103 > > rh120ns2.368.dhhs.gov. 81 IN AAAA 2607:f220:0:1::2d > > rh120ns1.368.dhhs.gov. 168 IN A 158.74.30.102 > > rh120ns1.368.dhhs.gov. 14260 IN AAAA 2607:f220:0:1::2c > > I don’t know the cause, but checking these nameserver authoritative > and glue records, I see ttl 300 for the authoritative records and > ttl 86400 for the gov glue records. Yes, I saw the same thing. It certainly doesn’t seem very optimal: my suspicion is that the TTL on the NS records was set to 5 minutes for testing/upgrade purposes, and was never restored to a more reasonable value. > The caching ttls above suggest the AAAA records are cached glue and > the A records are cached authoritative. Just an observation. I concur. > But that seems like something bind would deal with every day, even > with both A and AAAA records for the same NS name. Yes. The differing TTLs notwithstanding, BIND should be able to handle this situation without getting confused and returning SERVFAIL. > One clear thing about the above query is that renewals from the > authoritative the nameservers don’t happen to be in synch. True. I’m going to wander over to bind-workers with this issue, because I’m honestly beginning to wonder whether this is a bug with BIND… _______________________________________________ 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
