You've made your position clear, thanks. On Sep 13, 2017 20:54, "Mark Andrews" <ma...@isc.org> wrote:
> > In message <714677ea-e3c8-4145-825c-5ba8eabd0...@fugue.com>, Ted Lemon > writes: > > > > On Sep 13, 2017, at 1:19 PM, John Levine <jo...@taugh.com> 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: +61 2 9871 4742 INTERNET: ma...@isc.org >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
