[dns-operations] t.arin.net and RFC1918 reverse zones [was: 172.in-addr.arpa DNSSEC broken]

[Matt Rowley]

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