Hi David, 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? E.g., if I try and access https://somedomain.alt in my browser today then it attempts to lookup the domain and fails because it doesn't exist.
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. Possibly, the draft could have some text that allows stub resolves to filter out DNS requests for .alt names if they wish. I.e., filtering does no harm, performing the DNS lookup also does no harm, and the implementations can decide if they want to add a special code path for this case or just follow the standard code path. Regards, Rob // No hats. // Also not a DNS expert, so apologies if I'm using the wrong terms/words ... > -----Original Message----- > From: DNSOP <dnsop-boun...@ietf.org> On Behalf Of David Conrad > Sent: 22 October 2022 00:55 > To: Paul Hoffman <paul.hoff...@icann.org> > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] [Ext] Possible alt-tld last call? > > Paul, > > On Oct 21, 2022, at 3:34 PM, Paul Hoffman <paul.hoff...@icann.org> > wrote: > >> If the intent here is that .alt names should never be looked up via the > DNS, then MUST NOT is the expected behavior, no? > > There is no such intent of the draft. > > Ah. Then I guess I don’t support the draft and the rest of my input is > irrelevant. > > Regards, > -drc _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
