In message <capt1n1kxef0zj_vhuv00taz+39hr6nw19uz5rdxjr3aues5...@mail.gmail.com> , Ted Lemon writes: > > Mark, I really don't think this is a human rights issue. Is there something > that will break for you if the secure denial of existence is left in place?
I shouldn't BE FORCED to hard code special LOCALHOST rules into DNS tools. Lookups should "just work" like they did before the root zone was signed. Mark > On Sep 7, 2017 12:17 AM, "Mark Andrews" <[email protected]> wrote: > > > > > In message <CAHw9_iKBDY9hNThOY3GDeG7BbCkc8Ncy1T=rjpcQ=h5qdB7= > > [email protected]> > > , Warren Kumari writes: > > > > > On Wed, Sep 6, 2017 at 10:35 AM, Ted Lemon <[email protected]> wrote: > > > > On Sep 6, 2017, at 10:33 AM, tjw ietf <[email protected]> wrote: > > > > > > > > Thanks. The document still waffles, but it 'waffles less' than it did > > > > initially. But Mike is committed to working that and any other issue > > > which > > > > may arise. > > > > > > > > > > > > The question I really have is not whether Mike is willinghe's stated > > > that > > > > he is. It's whether the working group is willing, since returning > > > NXDOMAIN > > > > is an actual change in behavior from the original specification in RFC > > > 6761, > > > > and will likely result in some breakage, since it can safely be assumed > > > that > > > > some stacks are currently following the RFC6761 advice. > > > > > > > > > > Actually, I suspect that the breakage will be fairly minimal -- Google > > > Public DNS appears to have been returning NXDOMAIN since launch: > > > dig +nocmd +nostats localhost @8.8.8.8 > > > ;; Got answer: > > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55075 > > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > > > > > ;; QUESTION SECTION: > > > ;localhost. IN A > > > > > > ;; AUTHORITY SECTION: > > > . 14208 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017090502 > > > 1800 900 604800 86400 > > > > Which shows absolutely nothing. > > > > Is 'localhost.' assigned for use by my local machine? I believe > > the answer to that is: Yes. If if is assigned for use then with > > DNSSEC there MUST be a delegation in the root or is this working > > group going to overstep its mandate and tell me how I can use the > > name localhost. ICANN stuffed up by not adding the delegation when > > the root zone was signed. It was necessary then and it is still > > necessary now. > > > > If we want to create a alternative name and give it much more > > restrictive properties than the current assignment of localhost has > > then I'm fine with that. It is actually the correct fix for the > > problem statement. Fiddling with the properties of localhost after > > it has been in use for decades isn't the way to address this issue. > > > > Mark > > > > > and Verisign returns NOERROR (probably also since launch): > > > dig +nocmd +nostats localhost @64.6.64.6 > > > ;; Got answer: > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44657 > > > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > > > > > ;; QUESTION SECTION: > > > ;localhost. IN A > > > > > > ;; ANSWER SECTION: > > > localhost. 10800 IN A 127.0.0.1 > > > > > > > > > This doesn't seem to have caused any breakage - or, at least, we > > > haven't heard of any, and apparently basically no-one had noticed a > > > difference :-) > > > > > > W > > > > > > > > > > > > > > > > _______________________________________________ > > > > DNSOP mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > > > > > > > > > > > -- > > > 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 > > > > > > _______________________________________________ > > > DNSOP mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: [email protected] > > > > --089e0826f99c5cfff90558921502 > Content-Type: text/html; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"auto">Mark, I really don't think this is a human rights iss= > ue. Is there something that will break for you if the secure denial of exis= > tence is left in place?</div><div class=3D"gmail_extra"><br><div class=3D"g= > mail_quote">On Sep 7, 2017 12:17 AM, "Mark Andrews" <<a href= > =3D"mailto:[email protected]";>[email protected]</a>> wrote:<br type=3D"attributi= > on"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef= > t:1px #ccc solid;padding-left:1ex"><br> > In message <CAHw9_<wbr>iKBDY9hNThOY3GDeG7BbCkc8Ncy1T=3D<wbr>rjpcQ=3Dh5qd= > B7=3D<a > href=3D"mailto:[email protected]";>[email protected]</a><wbr>><br= > > > , Warren Kumari writes:<br> > <br> > > On Wed, Sep 6, 2017 at 10:35 AM, Ted Lemon <<a href=3D"mailto:mello= > [email protected]">[email protected]</a>> wrote:<br> > > > On Sep 6, 2017, at 10:33 AM, tjw ietf <<a href=3D"mailto:tjw.i= > [email protected]">[email protected]</a>> wrote:<br> > > ><br> > > > Thanks.=C2=A0 The document still waffles, but it 'waffles les= > s' than it did<br> > > > initially.=C2=A0 But Mike is committed to working that and any ot= > her issue<br> > > which<br> > > > may arise.<br> > > ><br> > > ><br> > > > The question I really have is not whether Mike is willinghe's= > stated<br> > > that<br> > > > he is.=C2=A0 =C2=A0It's whether the working group is willing,= > since returning<br> > > NXDOMAIN<br> > > > is an actual change in behavior from the original specification i= > n RFC<br> > > 6761,<br> > > > and will likely result in some breakage, since it can safely be a= > ssumed<br> > > that<br> > > > some stacks are currently following the RFC6761 advice.<br> > > ><br> > ><br> > > Actually, I suspect that the breakage will be fairly minimal -- Google= > <br> > > Public DNS appears to have been returning NXDOMAIN since launch:<br> > > dig +nocmd +nostats localhost @<a href=3D"http://8.8.8.8"; rel=3D"noref= > errer" target=3D"_blank">8.8.8.8</a><br> > > ;; Got answer:<br> > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55075= > <br> > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0<b= > r> > ><br> > > ;; QUESTION SECTION:<br> > > ;localhost. IN A<br> > ><br> > > ;; AUTHORITY SECTION:<br> > > . 14208 IN SOA <a href=3D"http://a.root-servers.net"; rel=3D"noreferrer= > " target=3D"_blank">a.root-servers.net</a>. <a href=3D"http://nstld.verisig= > n-grs.com" rel=3D"noreferrer" target=3D"_blank">nstld.verisign-grs.com</a>.= > <a href=3D"tel:2017090502" value=3D"+12017090502">2017090502</a><br> > > 1800 900 604800 86400<br> > <br> > Which shows absolutely nothing.<br> > <br> > Is 'localhost.' assigned for use by my local machine?=C2=A0 I belie= > ve<br> > the answer to that is: Yes.=C2=A0 If if is assigned for use then with<br> > DNSSEC there MUST be a delegation in the root or is this working<br> > group going to overstep its mandate and tell me how I can use the<br> > name localhost.=C2=A0 ICANN stuffed up by not adding the delegation when<br= > > > the root zone was signed.=C2=A0 It was necessary then and it is still<br> > necessary now.<br> > <br> > If we want to create a alternative name and give it much more<br> > restrictive properties than the current assignment of localhost has<br> > then I'm fine with that.=C2=A0 It is actually the correct fix for the<b= > r> > problem statement.=C2=A0 Fiddling with the properties of localhost after<br= > > > it has been in use for decades isn't the way to address this issue.<br> > <br> > Mark<br> > <br> > > and Verisign returns NOERROR (probably also since launch):<br> > > dig +nocmd +nostats localhost @<a href=3D"http://64.6.64.6"; rel=3D"nor= > eferrer" target=3D"_blank">64.6.64.6</a><br> > > ;; Got answer:<br> > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44657<= > br> > > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: = > 0<br> > ><br> > > ;; QUESTION SECTION:<br> > > ;localhost. IN A<br> > ><br> > > ;; ANSWER SECTION:<br> > > localhost. 10800 IN A 127.0.0.1<br> > ><br> > ><br> > > This doesn't seem to have caused any breakage - or, at least, we<b= > r> > > haven't heard of any, and apparently basically no-one had noticed = > a<br> > > difference :-)<br> > ><br> > > W<br> > > ><br> > > ><br> > > ><br> > > > ______________________________<wbr>_________________<br> > > > DNSOP mailing list<br> > > > <a href=3D"mailto:[email protected]";>[email protected]</a><br> > > > <a href=3D"https://www.ietf.org/mailman/listinfo/dnsop"; rel=3D"no= > referrer" target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/dnso= > p</a><br> > > ><br> > ><br> > ><br> > ><br> > > --<br> > > I don't think the execution is relevant when it was obviously a ba= > d<br> > > idea in the first place.<br> > > This is like putting rabid weasels in your pants, and later expressing= > <br> > > regret at having chosen those particular rabid weasels and that pair<b= > r> > > of pants.<br> > >=C2=A0 =C2=A0 ---maf<br> > ><br> > > ______________________________<wbr>_________________<br> > > DNSOP mailing list<br> > > <a href=3D"mailto:[email protected]";>[email protected]</a><br> > > <a href=3D"https://www.ietf.org/mailman/listinfo/dnsop"; rel=3D"norefer= > rer" target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/dnsop</a>= > <br> > <br> > --<br> > Mark Andrews, ISC<br> > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> > PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2= > 9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0INTERNET: <a href=3D"mailto:[email protected]";>[email protected]</a><br> > </blockquote></div></div> > > --089e0826f99c5cfff90558921502-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
