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?
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] >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
