On 14 Jan 2026, at 18:11, Florian Weimer <[email protected]> wrote: > I think it's been previously observed that compression is not actually > optional in practice, that is, the first answer record needs to start > with 0xc0 0x0c. It's not really related to ordering, but it fits > the underlying theme of producing maximally compatible responses.
That theme sounds like a fun theme. However, the scope of this draft is narrower. Our draft is aimed at addressing the specific problem we saw that broke things last week. We enlarged the scope slightly (we made a general rule for how to construct the answer section in general, not just when there is CNAME processing) but mainly we tried to choose a narrow scope and stick within it. It feels a bit like if we started collecting all the nagging ambiguities in 1034/1035 and put them all in the draft too we would have actually rewritten and modernised the whole DNS specification. History tells us that such a feat would be hard to pull off. In this draft we are not that ambitious, but this draft would still fit within such a theme. Future people who are more ambitious could include it together with all the other things, but in the mean time we have written down what we need to remember to avoid things breaking next time. As an aside, I spent a few minutes looking for what prompted me to write that earlier draft in 2015, and I found https://mailarchive.ietf.org/arch/msg/dnsop/7KoE8Dr-SxuNToskxbvAwJ3BQLQ/ which reveals https://github.com/skynetservices/skydns/issues/217 which was also a glibc assumption about the ordering of RRs in an answer section, possibly the same assumption, I didn't look at the code. Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
