On Tue, Jan 23, 2018 at 08:03:25PM +0000, Jeff Hodges wrote: > This is great! I can't wait for it to ship.
I am not nearly so enthusiastic about an important component of the draft. Specifically, I'd like to suggest that while the requirement for recursive resolvers to return NXDOMAIN for "localhost." is well-intentioned, it will prove counter-productive to the motivating goals of this draft. To whit, the stated motivation is in good measure that applications should be able to rely on getting loopback addresses in response to user requests to access resources located at "localhost". And I agree that requiring stub resolvers to short-circuit "localhost" is a positive step in that direction. However, I'd like to suggest that requiring recursive resolvers to return NXDOMAIN will likely backfire. When the C-library (or equivalent) stub resolver has not yet been updated to short-circuit "localhost" (the only case in which the requirement on recursive resolvers is relevant), but a spanking new recursive resolver starts returning "NXDOMAIN" per the draft, the user's reaction will not be an immediate rebuild of the system library to short-circuit "localhost". Rather, the far more likely outcome is that users will switch to using IP addresses, which is precisely what the draft is trying to avoid. Therefore, I'd like to suggest that draft should require that loopback addresses be returned as early as possible at every layer of the stack, the application, the stub resolver, and the iterative resolver (everybody except the root servers). In summary, I believe that the draft's goals would be better served by *requiring* recursive resolvers to short-circuit the request and return the applicable requested (A or AAAA) loopback address. -- Viktor. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop