> On 15 Jan 2026, at 04:11, Florian Weimer <[email protected]> wrote: > > * Joe Abley: > >> https://datatracker.ietf.org/doc/draft-jabley-dnsop-ordered-answer-section/ >> >> The new draft is essentially the old draft plus references to last >> week's observed impact with reference to Cloudflare's comments above >> and a description of the impact from cisco (whose ethernet switches >> were the ones rebooting). > > 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. > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected]
Requiring 0xc0 0xc0 indicates that the developers reverse engineered the DNS protocol. When you reverse engineer the protocol you get things WRONG! STD 13 requires that servers be case preserving (as entered in the zone file or equivalent) which implies that 0xc0 0xc0 is not guaranteed to be the first octets of the answer section. Additionally with QUERY responses with DNAMEs the answer section does not start with 0xc0 0xc0 as the DNAME is supposed to come first so even if the server is not case preserving the compression pointer isn’t to the start of the question section. Devices that require that the answer section starts with 0xc0 0xc0 are just plain broken should be upgraded / returned to the manufacture as not fit for purpose. There are very few devices with this fault. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
