Future of BIND's built-in empty zone list

Mark Andrews marka at isc.org
Fri May 15 23:18:07 UTC 2015


In message <CAHw9_iJoec40+uxs_-oLVeB0kJEGT1Gk=p=tcbwL4VKEPVJxGQ at mail.gmail.com
>, Warren Kumari writes:
> On Thursday, May 14, 2015, Rob Foehl <rwf at loonybin.net> wrote:
> 
> > On Thu, 14 May 2015, Chris Thompson wrote:
> >
> >  Now that RFCs 7[5]34 & 7[5]35 have been published, how do ISC see the
> >> future
> >> 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 correspondin
> g
> >> 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 t
> o
> > 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 thos
> e
> > 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...
> 
> 
> Yup.
> 
> 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
> could....
> 
> W

When IANA and ARIN finally gets around to doing 64.100.IN-ADDR.ARPA
et al., which has been waiting over a year for the of DNSOP to write
up the last call of draft-ietf-dnsop-rfc6598-rfc6303 to be written
up, it should be done similar to this with a insecure delegation
to 64.100.IN-ADDR.ARPA, to allow the ISP's using this range and
others to server their own instances of 64.100.IN-ADDR.ARPA without
DNSSEC validation failures, and a DNAME to the AS112 traffic sink
for the leaked traffic.

64.100.IN-ADDR.ARPA  SOA ...
64.100.IN-ADDR.ARPA  NS ...
64.100.IN-ADDR.ARPA  NS ...
64.100.IN-ADDR.ARPA  DNAME EMPTY.AS112.ARPA

Note: there are no DNSKEY records.  This is deliberate.

Recursive nameservers will just have the traditional locally served
empty zone by default.

64.100.IN-ADDR.ARPA  SOA ...
64.100.IN-ADDR.ARPA  NS ...

Mark


> > -Rob
> > _______________________________________________
> > 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
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
> 
> 
> -- 
> 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
> pants.
>    ---maf
> 
> --f46d043c80bc062bee0516210c9a
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <br><br>On Thursday, May 14, 2015, Rob Foehl <<a href=3D"javascript:_e(%=
> 7B%7D,'cvml','rwf at loonybin.net');" target=3D"_blank">rwf at lo=
> onybin.net</a>> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
> gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 14 May =
> 2015, Chris Thompson wrote:<br>
> <br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> Now that RFCs 7[5]34 & 7[5]35 have been published, how do ISC see the f=
> uture<br>
> of the seemingly ever-expanding built-in empty zone list in BIND?<br>
> <br>
> One possibility that seems plausible to me is to add EMPTY.AS112.ARPA<br>
> to the list now, and remove existing entries if and when the corresponding<=
> br>
> names in the public DNS acquire DNAMEs pointing to that (hopefully ones<br>
> with large TTLs).<br>
> </blockquote>
> <br>
> Adding empty.as112.arpa to the list seems like a good idea, but removing th=
> e existing empty zones does not -- they also prevent leaking internal queri=
> es, which is both more noise for the root/IANA/AS112 infrastructure to sink=
>  and a potential privacy concern.<br>
> <br>
> There's also the minor benefit of fast responses from local resolvers, =
> which still matters for determinism in the initial query.=C2=A0 From where =
> I sit, the nearest blackhole.as112.arpa is 90+ms and an ocean away (v4 or v=
> 6), and the existing AS112 nodes aren't much better.<br>
> <br>
> What would be gained by shrinking the number of empty zones?=C2=A0 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 g=
> rasping at straws here...</blockquote><div><br></div><div>Yup.</div><div><b=
> r></div>One of the advantages to the new style AS112 / DNAME solution is th=
> at you can easily add *and* remove zones from AS112. This means that we can=
>  more easily=C2=A0add things that may need to be removed in the future -- b=
> ut I don't think any of the existing things fall into this category.<di=
> v><br></div><div>I'm not actually suggesting this, but imagine delegati=
> ng .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 solu=
> tion perhaps you could....</div><div><br></div><div>W<br><div>=C2=A0</div><=
> blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
>  #ccc solid;padding-left:1ex">
> <br>
> -Rob<br>
> _______________________________________________<br>
> Please visit <a href=3D"https://lists.isc.org/mailman/listinfo/bind-users" =
> target=3D"_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to =
> unsubscribe from this list<br>
> <br>
> bind-users mailing list<br>
> <a>bind-users at lists.isc.org</a><br>
> <a href=3D"https://lists.isc.org/mailman/listinfo/bind-users" target=3D"_bl=
> ank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
> </blockquote></div>
> <br><br>-- <br>I don't think the execution is relevant when it was obvi=
> ously a bad idea in the first place.<br>This is like putting rabid weasels =
> in your pants, and later expressing regret at having chosen those particula=
> r rabid weasels and that pair of pants.<br>=C2=A0 =C2=A0---maf<br>
> 
> --f46d043c80bc062bee0516210c9a--
> 
> --===============7032085822905059876==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscrib
> e from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===============7032085822905059876==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


More information about the bind-users mailing list