Hi Joe,
On 15. 01. 26 9:45, Joe Abley wrote:
... The stub resolvers that are observed to be sensitive don't receive RRSIGs
in the answer section, since they don't send queries with DO=1.
... there are important and widespread assumptions about the ordering of RRSets
in the answer section, and not paying attention to those assumptions makes
things break in surprising ways.
The answer section *is* special, not for any philosophical or design reason,
but because we know that arbitrary ordering of RRSets there breaks the Internet.
Joe
I still argue that the best way of fixing broken clients is fixing
broken clients. If they made incorrect assumptions about RR ordering, we
should take the lesson and write an Informational document making clear
that the assumptions are incorrect.
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.
If we however decide to go ahead with this document, I'd like to have it
more limited in scope (perhaps only recursive-to-stub responses, maybe
only CNAME and DNAME, no effect on DNSSEC) and clearly explaining (with
examples! of correct and incorrect responses) what are the consequences
and what aren't, for example to SVCB alias-form, non-standard ALIAS
records etc etc. The current wording is so general that I can't event
say if some response complies or not.
Thank you,
Libor
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
