In message <CAHw9_iKBDY9hNThOY3GDeG7BbCkc8Ncy1T=rjpcQ=h5qdB7=u...@mail.gmail.com> , 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
