In message <[email protected]>, Ted Lemon writes: > > On Sep 13, 2017, at 1:19 PM, John Levine <[email protected]> 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: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
