[DNSOP] Re: ordering of RRSets in the answer section of a DNS response

[Mark Andrews <[e-mail]>]

> On 15 Jan 2026, at 04:11, Florian Weimer <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

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: [phone]              INTERNET: [e-mail]