Ted Lemon <mel...@fugue.com> wrote: > > 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.
I was looking at query traffic recently to prepare for deleting localhost entries from our main zone (http://news.uis.cam.ac.uk/articles/2017/09/01/deleting-localhost-entries-from-the-cam-ac-uk-dns-zone) It was reassuring to see there were very few leaked localhost queries, whether bare or with the search path appended. So it seems that stub resolvers are successfully sinking localhost queries as they should. I have configured the resolvers I run pedantically to include the empty zones that aren't built-in to BIND, including localhost. So my setup is a lot more RFC 6761 than the default. (But I'll happily delete most of it when the cheese shop reaches production.) Based on the low volume of localhost query traffic and the lack of RFC 6761 conformance in at least one common recursive server, I think the change from positive to negative responses will only affect a tiny number of things that are already buggy. A related thing that needs to be covered is the reverse DNS for 127.0.0.1 and ::1 - pedants like me have configured PTR records for those addresses, which become useless when the forward domain goes away (if they aren't useless already). BIND returns a built-in NXDOMAIN for them by default which is justified by RFC 5735 though that spec doesn't mention the DNS. Perhaps let-localhost-be-localhost should explicitly require reverse DNS behaviour to match the forward DNS, i.e. positive answers generated in stubs and NXDOMAIN from recursive servers. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode Irish Sea: West 4 or 5, decreasing 3 for a time, backing southwest 5 or 6 later. Slight or moderate. Showers later. Good. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
