--On Monday, March 26, 2018 17:18 +0200 Martin Hoffmann
<mar...@opennetlabs.com> wrote:
> John C Klensin wrote:
>>
>> From that point of view, namespaces are actually
>> per-RRTYPE and the right way to design this document would be
>> as a registry of "_"-introduced keywords, with subregistries
>> for each RRTYPE with which those keywords can be used. Given
>> the way the DNS works, at least as I understand it, there is
>> no DNS protocol conflict between
>> _foo IN XYZ Data1
>> and
>> _foo IN ABC Data2
>>
>> Using the same keyword in both cases may be a bad idea [...]
>
> This sort of thing already happens: Both SRV and TLSA use the
> _tcp and _udp labels. Perhaps the difference is subtle since in
> both cases the label denotes the transport protocol. But names
> do represent different things -- a service provided for a
> logical entity v. a port of a physical host.
The current text of the I-D, as I read it, is intended to bind
the use of a given string to a given RRTYPE. From the abstract:
"The purpose of the Underscore registry is to avoid
collisions resulting from the use of the same
underscore-based name, for different services."
Subtle or not, that is a collision. I would much prefer to see:
SRV [sub]registry
...
_tcp [RFC2782]
...
TLSA subregistry
...
_tcp [RFCnnnn]
...
rather than
_tcp SRV [RFC2782][RFCnnnn]
the former would also make it easy to say whatever needs to be
said about second-level strings.
> Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and
> OPENPGPKEY all use underscore labels and are currently missing
> from the initial table in section 3.1.
Sigh.
best,
john
p.s. Some nit-picking in the hope of general improvements to the
document. At least for me, the terminology and background
explanation needs careful review. In particular
(1) The text in Section 1.1 says
'the DNS rules for a "host" (host name) are not allowed
to use the underscore character... legal host names
[RFC1035]'
1035 does not say that. Its section 2.3.1 is about what is
preferred, not what is required (or "legal"). It says "should"
and "preferred", but there is no requirement. As far as I know,
there has never been a serious attempt to turn that preference
into a requirement. Indeed, RFC 8121 says exactly the opposite
and, if there were a prohibition, RFC 6055 would have been
largely unnecessary.
(2) While, AFAICT, it is correct or close to it, the terminology
describing the DNS tree structure is awkward. For example, in
"_foo._tcp.example.com", it is probably incorrect to refer to
"_tcp" as a leaf node because it has substructure. The
statement
"Each globally-registered underscore name owns a
distinct, subordinate name space"
does not work if _foo._bar.examplle.com is valid for one RRTYPE
but not for a different one (this is another argument for both
associating "namespace" terminology with a keyword-RRTYPE pair
and a subregistry approach, but the current language is
problematic even if we stick with the current model. And,
because a casual reader might associate "global" and
"right-most" with TLDs and get confused about whether the DNS
tree is considered "root up", "root down", or "root right",
those terms would probably benefit from an explicit terminology
section that describes this documents view of the tree.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
