hhs.gov resolvers broken, or BIND misconfigured?

[James Ralston]

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       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…