Section 4.3 claims RFC7671 reserves "_dane":
" +------------+------------------+------------+
| RR Type | _NODE NAME | REFERENCE |
+------------+------------------+------------+
..
| TLSA | _dane | [RFC7671] |
"
I can't see any support of this in RFC7671.
I assume the misunderstanding comes from a couple of examples using a
"_dane" label. But this is an arbitrary choice, and not an attempt to
reserve a name. For example from RFC7671 section 5.2:
" Some domains may prefer to avoid the operational complexity of
publishing unique TLSA RRs for each TLS service. If the domain
employs a common issuing CA to create certificates for multiple TLS
services, it may be simpler to publish the issuing authority as a TA
for the certificate chains of all relevant services. The TLSA query
domain (TLSA base domain with port and protocol prefix labels) for
each service issued by the same TA may then be set to a CNAME alias
that points to a common TLSA RRset that matches the TA. For example:
; Two servers, each with its own certificate, that share
; a common issuer (TA).
;
www1.example.com. IN A 192.0.2.1
www2.example.com. IN A 192.0.2.2
_443._tcp.www1.example.com. IN CNAME tlsa._dane.example.com.
_443._tcp.www2.example.com. IN CNAME tlsa._dane.example.com.
tlsa._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14...
"
It is obvious from this that "tlsa._dane.example.com." is a placeholder
alias, and not reserving "tlsa" or "_dane" labels.
The consistent choice of "tlsa._dane" in the RFC7671 examples might have
contributed to this confusion. Something to keep in mind for future DNS
label examples. Use your fantasy :-)
Bjørn
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
