Re: hhs.gov resolvers broken, or BIND misconfigured?
On Fri, Mar 4, 2016 at 1:25 PM, John Wobuswrote: > > 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 2607:f220:0:1::2a > > rh202ns2.355.dhhs.gov. 168 IN A 158.74.30.99 > > rh202ns2.355.dhhs.gov. 14260 IN 2607:f220:0:1::2b > > rh120ns2.368.dhhs.gov. 81 IN A 158.74.30.103 > > rh120ns2.368.dhhs.gov. 81 IN 2607:f220:0:1::2d > > rh120ns1.368.dhhs.gov. 168 IN A 158.74.30.102 > > rh120ns1.368.dhhs.gov. 14260 IN 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 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 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
Re: hhs.gov resolvers broken, or BIND misconfigured?
> 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 2607:f220:0:1::2a > rh202ns2.355.dhhs.gov. 168 IN A 158.74.30.99 > rh202ns2.355.dhhs.gov. 14260 IN 2607:f220:0:1::2b > rh120ns2.368.dhhs.gov. 81 IN A 158.74.30.103 > rh120ns2.368.dhhs.gov. 81 IN 2607:f220:0:1::2d > rh120ns1.368.dhhs.gov. 168 IN A 158.74.30.102 > rh120ns1.368.dhhs.gov. 14260 IN 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. The caching ttls above suggest the 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 records for the same NS name. One clear thing about the above query is that renewals from the authoritative the nameservers don’t happen to be in synch. John Wobus Cornell University IT ___ 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: hhs.gov resolvers broken, or BIND misconfigured?
On Wed, Mar 2, 2016 at 7:08 AM, Tony Finchwrote: > James Ralston wrote: > > > We're running a recursive resolver on RHEL6, using the latest > > RHEL-provided BIND package, bind-9.8.2-0.37.rc1.el6_7.6. The > > recursive resolver only has an IPv4 interface; it does not have an > > IPv6 interface. DNSSEC is enabled (by default). > > Dunno why BIND is failing to find the A records, but have you tried > running named -4? Yes. It doesn't change anything. BIND already knows that there is no usable IPv6 interface on the system. That's why it returns SERVFAIL when it gets into the state where it thinks the nameservers for hhs.gov are only reachable via IPv6. Disabling IPv6—either at the OS level, in BIND, or both—won't prevent BIND from fetching records when it performs recursive resolution. And when the cache contains only the records (instead of the A records), BIND can no longer resolve any hhs.gov records. The frustrating thing is that I can see from the ngrep capture that BIND *does* attempt to refresh the cached A records of the nameservers. I don't see anything obviously wrong with that exchange. But BIND seemingly ignores the answers that contain the A records. ___ 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: hhs.gov resolvers broken, or BIND misconfigured?
James Ralstonwrote: > > We're running a recursive resolver on RHEL6, using the latest > RHEL-provided BIND package, bind-9.8.2-0.37.rc1.el6_7.6. The > recursive resolver only has an IPv4 interface; it does not have an > IPv6 interface. DNSSEC is enabled (by default). Dunno why BIND is failing to find the A records, but have you tried running named -4 ? Tony. -- f.anthony.n.finch http://dotat.at/ Humber: West or northwest, becoming cyclonic for a time, 5 to 7, decreasing 4 or 5 later. Slight or moderate. Wintry showers. Good, occasionally poor. ___ 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