Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

In message <CAHw9_iKBDY9hNThOY3GDeG7BbCkc8Ncy1T=rjpcQ=h5qdB7=UQ@mail.gmail.com>
, Warren Kumari writes:

> On Wed, Sep 6, 2017 at 10:35 AM, Ted Lemon <mellon@fugue.com> wrote:
> > On Sep 6, 2017, at 10:33 AM, tjw ietf <tjw.ietf@gmail.com> 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
> > DNSOP@ietf.org
> > 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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org