On Mon, Apr 19, 2021 at 9:34 AM Paul Hoffman <paul.hoff...@icann.org> wrote:
> 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. > I think there is value in highlighting the root problem, and its implications. Private-use TLDs will fail DNSSEC validation which uses the IANA DNSSEC Root Trust Anchor. Organizations using names beneath such private-use TLDs while operating validating recursive resolvers or validating stub resolvers need to also manage trust anchors for those domains on those hosts. Such a trust anchor could be used to either sign the domain, or prove the unsigned nature of the domain. (It may be an implementation-specific issue and/or specification issue, as to how multiple trust anchors are handled. I.e. I'm not 100% sure off hand if the current specifications are compatible with my statements. If they aren't, IMHO they should be either revised or made more clear so as to support use cases like this.) Brian Dickson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
