In message <CAHw9_iJoec40+uxs_-oLVeB0kJEGT1Gk=p=tcbwl4vkepvj...@mail.gmail.com >, Warren Kumari writes: > On Thursday, May 14, 2015, Rob Foehl <r...@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@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','r...@loonybin.net');" target=3D"_blank">rwf@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@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@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: ma...@isc.org _______________________________________________ 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
