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

[Ted Lemon <[e-mail]>]

You've made your position clear, thanks.

On Sep 13, 2017 20:54, "Mark Andrews" <[e-mail]> wrote:

>
> In message <[e-mail]>, Ted Lemon
> writes:
> >
> > On Sep 13, 2017, at 1:19 PM, John Levine <[e-mail]> wrote:
> > > I concur with Mark that while localhost.<foo> is a problem,
> > > <foo>.localhost is not.  I've occasionally used that hack to pass
> > > traffice to various servers running on 127/8 addresses other than
> > > 127.0.0.1.
> >
> > So we should expose end-users to attack because it's "occasionally" =
> > convenient for you to do this hack?
>
> The biggest problem is that HTTP says that hostnames in URLs may
> be relative.  Close that grand canyon sized security hole.  There
> is zero need for relative names in URL's in html documents, email
> etc.  There is some need for them in address bars but that is UI.
> What goes over the wire should be treated as absolute, always.
>
> Treat "localhost" as always being absolute.  No searching if that
> is the entered hostname.  Yes, this will break somethings that
> depend on searching to find localhost.*.  It is the one hangover
> from the flat global namespace we still have.
>
> Have public DNS return unsigned NODATA for localhost (qtype != SOA,
> NS, DS) and signed NODATA for localhost DS.
>
> getaddrinfo() et al. is still free to hardcode localhost -> (::1,
> 127.0.0.1) if the implementation wants to.  Make it a requirement
> for *browsers* (includes curl, fetch, lynx etc.) to do this if you
> want.
>
> Recommend that recursive servers have a "localhost." zone with ::1
> and 127.0.0.1 for "localhost." built in by default.
>
> You don't need to sabatage the DNS.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
>