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

[Ondřej Surý <[e-mail]>]

> On 15. 1. 2026, at 12:41, Joe Abley <jabley=[e-mail]> wrote:
> 
>> I think that you are motivated by the scale how the broken clients are wide-spread, and how crippled upgrade policies prevent upgrading them in reasonable time. However, writing and publishing an RFC also doesn't happen in a short time.
> 
> Yes, that's totally the motivation. 
> 
> I think of this as an investment in the future; if we can avoid future disasters (even small ones) by making a decision now, I think the return on investment is reasonable.

The last time we used the "scale" as a motivation, we got serve-stale, a DNS protocol breaking bandaid, and we all still suffer from that.

> On 15. 1. 2026, at 3:29, John Levine <[e-mail]> wrote:
> 
> It appears that Libor Peltan  <[e-mail]> said:
>> Anyway, shouldn't we rather go the opposite way of declaring that any 
>> section of DNS response is unordered (why should the answer section be 
>> special?) and the receiver MUST be able to find all the wanted info 
>> regardless -- even in ridiculous cases when the CNAME target is put 
>> first and the CNAME itself afterwards...?
> 
> It seems to me that if we are going to say anything, we should both say that
> caches and forwarders have to emit the records in chain order so that badly
> written stubs won't break, and stubs have to accept records in any order so
> badly written caches won't break them.

If anything, I would say that the language should be:

- caches and forwarders SHOULD emit the records in chain order so that badly written stubs won't break
- stubs resolvers MUST accept records in any order so badly written caches won't break them

Ondrej
--
Ondřej Surý (He/Him)
[e-mail]