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.
> Why reserve so many names for a singular purpose? If human semantics are
> irrelevant then why not just pick a name at random and reserve that one?
> There may come a time in the future where one of these names might be useful
> for something else.
The question of "why" is a good one. There are two extremes:
- All these labels are equivalent, so the WG should just allow one to be used.
- These labels have different semantic properties to different people, so let
them choose freely among the set.
This hasn't been well-discussed in the WG. My personal preference is the latter
(which is what is in the draft) because names and abbreviations matter, whether
or not we techies like that. There is no technical downside to the list being
large but bounded, I think.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
