<div dir="ltr"><div>Andrew Ayer reported an erratum on RFC 6844, separately from the erratum 5065 tree-climbing issue: <a href="https://www.rfc-editor.org/errata/eid5097">https://www.rfc-editor.org/errata/eid5097</a></div><div><br></div><div>The current RFC 6844 says:</div><div><div>> Let CAA(X) be the record set returned in response to performing a CAA</div><div>> record query on the label X, P(X) be the DNS label immediately above</div><div>> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME</div><div>> alias record specified at the label X.</div></div><div><br></div><div>The problem is that DNAME records are not aliases, they are instructions to generate aliases: <a href="https://tools.ietf.org/html/rfc6672#section-3">https://tools.ietf.org/html/rfc6672#section-3</a></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>My question is: Do root programs consider the "natural" interpretation reasonable?</div></div>