Hi again, So we corrected this yesterday. We realized that we have been tripping this behavior in BIND:
https://deepthought.isc.org/article/AA-00804/0/Why-does-named-log-an-error-disabling-RFC-1918-empty-zones-when-starting-up.html (although the log message it's referring to never showed up for us) The hosts which comprise t.arin.net run BIND as authoritative and as a recursive resolver for just themselves. This is due to the limited footprint we have at that location). That's why this didn't manifest itself on Z, X, etc, despite functionally-identical configurations. Thanks again for alerting us to this. cheers, Matt Matt Rowley wrote: > Hi Chris, > > Thanks for pointing this out to us. We are investigating as to why that > SOA is being returned on T. It doesn't jive with our configs. We're > looking into this now, and I'll let you know what we find. > > cheers, > Matt > > > > Chris Thompson wrote: >> I came across this while investigating the 172.in-addr.arpa KSK rollover >> problem, but it is unrelated. >> >> t.arin.net is configured with dummy empty zones for >> [16-31].172.in-addr.arpa, >> as well as 168.192.in-addr.arpa (and 10.in-addr.arpa, but it's unlikely to >> get asked about that one). They look exactly like the "automatic empty >> zones" >> of all modern BIND versions. >> >> The other seven official nameservers [ruvwxyz].arin.net for the zones >> {176,192}.in-addr.arpa are not so configured. They return a referral >> to the AS112 servers blackhole-{1,2}.iana.org when queried for RFC1918 >> addresses. >> >> It isn't obvious that this does any harm - RFC1918 reverse queries that >> escape onto the Internet get an NXDOMAIN one way or another, but the >> inconsistency is somewhat confusing. >> _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
