[cabfpub] Clarification on DNAME erratum
jsha at letsencrypt.org
Tue Oct 10 15:27:57 MST 2017
Andrew Ayer reported an erratum on RFC 6844, separately from the erratum
5065 tree-climbing issue: https://www.rfc-editor.org/errata/eid5097
The current RFC 6844 says:
> Let CAA(X) be the record set returned in response to performing a CAA
> record query on the label X, P(X) be the DNS label immediately above
> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
> alias record specified at the label X.
The problem is that DNAME records are not aliases, they are instructions to
generate aliases: https://tools.ietf.org/html/rfc6672#section-3
Andrew's interpretation is that the letter of the RFC says to treat DNAMEs
as direct aliases rather than alias generators, which would mean that the
normal RFC 1034 alias resolution process doesn't work, and additional
DNAME-specific code is needed.
I think there is another reasonable interpretation, which is that "DNAME
alias record" refers to an alias record generated by a DNAME. This results
in the "natural" treatment of DNAMEs and mean the RFC 1034 alias resolution
in off-the-shelf DNS resolvers can be used. This also matches the "CAA
Simplification" draft being discussed at the IETF LAMPS WG.
My question is: Do root programs consider the "natural" interpretation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public