Hi Petr, On 14 Jan 2026, at 16:24, Petr Špaček <[email protected]> wrote:
> On 14. 01. 26 15:58, Joe Abley wrote: > >> Since it seemed newly pertinent, Sebastiaan and I submitted a new proposal >> to resolve the ambiguity in 1034/1035 (I have no good way to authorise a -01 >> submission for the 2015 draft, fun as it would have been to have that draft >> rise from the grave and walk amongst us). > > Nit: You can ask Secretariat to mark the old draft as replaced with the new > one. We have done this with some deleg documents. Yep, I'll do that. > For example, what's interoperable order of RRs in this answer? > > ; ANSWER > test1. DNAME test2. > www.test1. CNAME www.test2. > test2. DNAME test3. > www.test2. CNAME www.test3. > www.test3. AAAA 3fff:: So, QNAME=www.test1, QTYPE=AAAA, QCLASS=IN. The TEST1 zone contains an apex DNAME, and so does the TEST2 zone, like this: TEST1. SOA ... TEST1. NS ... TEST1. DNAME TEST2. TEST2. SOA ... TEST2. NS ... TEST2. DNAME TEST3. TEST3. SOA ... TEST3. NS ... WWW.TEST3. AAAA 3fff:: Following RFC 6672 section 3.1, we must "in all cases" include the relevant DNAME RR in the answer section. This means append. Subsequently the instructions are to include a synthetic CNAME, which means append. So the answer section construction looks like this. I am handwaving slightly since the text in 6672 is not clear about these steps being sequential; I'm just going by what is mentioned first. Maybe this is also worth clarifying. TEST1. DNAME TEST2. WWW.TEST1. CNAME WWW.TEST2. Then the same again following the next DNAME, which gives us an answer section under construction as follows: TEST1. DNAME TEST2. WWW.TEST1. CNAME WWW.TEST2. TEST2. DNAME TEST3. WWW.TEST2. CNAME WWW.TEST3. Then we are back to following 1034, also using append, which gives us: TEST1. DNAME TEST2. WWW.TEST1. CNAME WWW.TEST2. TEST2. DNAME TEST3. WWW.TEST2. CNAME WWW.TEST3. WWW.TEST3. AAAA 3ffe:: > Bonus points for test what would Cisco switch would do it if had the same > CNAME in the answer twice :-) Say the DNAME looped and that loop was > generated into the message. I seem to think that resolvers already need logic about the number of times they will iterate trying to find an answer, and SERVFAIL otherwise. Resolution loops are also beyond what this clarification was aiming for. Not to suggest it isn't a good question, just that it's not the question that this draft currently answers. > Is it 'protocol-legal' to have multiple identical RRs in the message? > > I would think it is not, but also I don't see test prohibiting it. That seems reasonable but it feels like a different clarification to the one in this draft. Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
