On Apr 19, 2021, at 7:17 AM, Andrew McConachie <and...@depht.com> wrote: > > > > On 16 Apr 2021, at 17:18, Paul Hoffman wrote: > >> On Apr 16, 2021, at 5:31 AM, Andrew McConachie <and...@depht.com> wrote: >> >>> If I understand section 4.3 correctly, DNSSEC validating stub resolvers >>> SHOULD NOT resolve these names. Is that the intention of Section 4.3? >> >> No, definitely not. The text says: >> 3. Name resolution APIs and libraries SHOULD NOT recognise these >> names as special and SHOULD NOT treat them differently. Name >> resolution APIs SHOULD send queries for these names to their >> configured caching DNS server(s). >> Not recognizing them as special means to treat them like any other name. >> There is no mention of DNSSEC. >> > > I realize now my question was unclear. My understanding is that a DNSSEC > validating stub SHOULD attempt to validate these names, which will fail. > Therefore a DNSSEC validating stub cannot use these names.
That's correct, as it would be for any private-use TLD. In fact, it's not just about validating stubs: an organization wanting to use a private-use TLD cannot have validating stub resolvers or validating recursive resolvers anywhere in the organization. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
