Hi David, [Still with no hats]
> -----Original Message----- > From: David Conrad <d...@virtualized.org> > Sent: 22 October 2022 17:40 > To: Rob Wilton (rwilton) <rwil...@cisco.com> > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] [Ext] Possible alt-tld last call? > > Rob, > > On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton) <rwil...@cisco.com> wrote: > > If this was a MUST NOT, then at the point that the RFC is published, would > that not mean that all DNS stub (and maybe recursive) resolvers immediately > become non complaint with the new standard? > > The draft says “Informational”. It is (maybe) recommending the partitioning > of > the domain name namespace, explicitly creating a sub-space that is for non- > DNS use. It makes no sense to me to then pretend it’s "just fine” to issue > DNS > queries in that sub-namespace. As I read it, the partitioning of the domain name namespace is really to achieve two aims: 1) to guarantee that .alt, and no domains under .alt, will ever exist in the DNS, and hence it will need be impossible for an alternative name resolution system to "shadow" valid .alt entries in the DNS (since there can be none). 2) it gives a place to experiment with alternative naming systems in a way that doesn't interfere with the DNS. As I understand it , some of these alternative name services are squatting on unallocated TLDs, and some browsers are resolving names in these alternative name services. This is not ideal, particularly if those unallocated TLDs end up getting sold by ICANN to companies that expect to use them with the regular DNS rather than any alternative name service. > > > My interpretation of Paul's comment is that nothing bad happens if a client > does attempt to resolve .alt names in the DNS because they will just fail in > the > same way as any other domain that doesn't exist in the DNS, and that is okay. > > But it is not OK. Yes, the root servers are surely provisioned to handle the > additional load the use of .alt might create, but it adds to the useless > noise — > why would the IETF encourage this? Worse, it exposes .alt traffic to > potential > eavesdroppers. I’m confused why the IETF would publish an informational > document that says both of those are not protocol violations. My assumption is that a browser, application, or even the OS, that supports any of these alternative name resolution services will have some code switch that decides to either look up the name in the DNS or look the name up in the alternative service. E.g., If my browser supports GNS, then the browser knows to try and resolve https://myfunkyname.gns.alt/ using GNS. If the browser has the code to do that, then I would also hope then it wouldn't also try and resolve the same domain in the DNS on failure to resolve it using GNS. But even if they did, I don't see that as really being a problem, it will just fail the same way as any other unknown domain. If a user types the same URL into a different browser that doesn’t support GNS, then stub resolver would naturally try and resolve https://myfunkyname.gns.alt/ in the DNS, which must fail because there can never be any domains in the DNS that end with .alt. It fails in the same way as if I mistype a URL and try and resolve "https:://google.con" rather than "https://google.com";. But I don't understand why this alternative browser, that doesn't care about alternative name resolution schemes at all, must change their code. This is outside my area of expertise, but I'm not convinced that the global DNS would see any significant increase in load, because the stub resolver would generally not be sending the requests to the DNS assuming that they are valid domains, and if they are not valid domains then that would seem to be the same as what DNS already handles today. And as for the eavesdropping concern, doesn't this equally apply for all domain lookups, particularly invalid ones? Regards, Rob > > > Possibly, the draft could have some text that allows stub resolves to > > filter out > DNS requests for .alt names if they wish. > > The point is that DNS resolvers of any kind are explicitly not supposed to see > .alt queries — .alt is NOT a DNS namespace. If they do (and they obviously > will), something is broken and should be fixed. > > Regards, > -drc _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
