Future of BIND's built-in empty zone list
warren at kumari.net
Fri May 15 16:07:54 UTC 2015
On Thursday, May 14, 2015, Rob Foehl <rwf at loonybin.net
> On Thu, 14 May 2015, Chris Thompson wrote:
> Now that RFCs 734 & 735 have been published, how do ISC see the
>> of the seemingly ever-expanding built-in empty zone list in BIND?
>> One possibility that seems plausible to me is to add EMPTY.AS112.ARPA
>> to the list now, and remove existing entries if and when the corresponding
>> names in the public DNS acquire DNAMEs pointing to that (hopefully ones
>> with large TTLs).
> Adding empty.as112.arpa to the list seems like a good idea, but removing
> the existing empty zones does not -- they also prevent leaking internal
> queries, which is both more noise for the root/IANA/AS112 infrastructure to
> sink and a potential privacy concern.
> There's also the minor benefit of fast responses from local resolvers,
> which still matters for determinism in the initial query. From where I
> sit, the nearest blackhole.as112.arpa is 90+ms and an ocean away (v4 or
> v6), and the existing AS112 nodes aren't much better.
> What would be gained by shrinking the number of empty zones? The only
> thing that comes to mind is that it'd make life marginally easier for those
> who run cache hierarchies and override some of those zones at the top
> level, but there's already an option for that and I'm definitely grasping
> at straws here...
One of the advantages to the new style AS112 / DNAME solution is that you
can easily add *and* remove zones from AS112. This means that we can more
easily add things that may need to be removed in the future -- but I don't
think any of the existing things fall into this category.
I'm not actually suggesting this, but imagine delegating .belkin to AS112 -
at the moment it is all noise at the root, one day it may be real. Using
old style AS112 you cannot do this, with the DNAME solution perhaps you
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users