hhs.gov resolvers broken, or BIND misconfigured?
ralston at pobox.com
Tue Mar 8 18:51:51 UTC 2016
On Fri, Mar 4, 2016 at 1:25 PM, John Wobus <jw354 at 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 188.8.131.52
> > rh202ns1.355.dhhs.gov. 14260 IN AAAA 2607:f220:0:1::2a
> > rh202ns2.355.dhhs.gov. 168 IN A 184.108.40.206
> > rh202ns2.355.dhhs.gov. 14260 IN AAAA 2607:f220:0:1::2b
> > rh120ns2.368.dhhs.gov. 81 IN A 220.127.116.11
> > rh120ns2.368.dhhs.gov. 81 IN AAAA 2607:f220:0:1::2d
> > rh120ns1.368.dhhs.gov. 168 IN A 18.104.22.168
> > 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
> The caching ttls above suggest the AAAA records are cached glue and
> the A records are cached authoritative. Just an observation.
> 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.
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…
More information about the bind-users