On Wed, Jan 14, 2026 at 5:11 PM, Libor Peltan < [email protected]> wrote:
> Hi Joe, > > I don't like that this document only refers (and updates) RFC1034, and > ignores the existence of RFCs for DNSSEC (in particular!), CNAME, DNAME, > etc. > > It can be easily seen that the construction of DNS responses (all of their > sections) vary across DNS implementations, and I don't think this is really > a problem. > > For example, when querying ns3.xdp.cz. AAAA, the authoritative server > (which is Knot DNS) puts into the answer section first the CNAME and AAAA, > and appends both RRSIGs afterwards; while the resolver at 8.8.8.8 puts each > RRSIG just after the record it signs. > > Do you think any of those implementations is "wrong"? After reading your > document, I don't have any clue about that -- what is my exact critique of > your document. > > 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...? > While I personally believe that the records should be able to appear in any old order within a section, it seem that some things go BOOM if you don't put thing in just the right way. So, to me, a document which says something like "While records are ethnically unordered, if you want your implementation to work in the real world, you need to put them in this order A → B → C.". Yes, this is technical debt, but glibc style things have been around for ever, and are likely to remain on the Big-I Internet for the long foreseeable future[0]. This feels like perfect DNSOP, or DNS Operations advice… W [0]: As an example, I still have some Cisco 2511 term-servers in use, which were EOL in ~1999… > Libor > > On 14. 01. 26 15:58, Joe Abley wrote: > > Hi all, > > Cloudflare's 1.1.1.1 public DNS service triggered some unexpected > operational effects during a routine software release on 8 January. > Sebastiaan has done a great write-up here, for those that are interested. > If you happened to notice any weird spontaneous reboot loops of old > enterprise switches in your network, you might be more interested than you > would normally imagine. > > https://blog.cloudflare.com/cname-a-record-order-dns-standards/ > > The nature of the trigger caused us to think a bit about ambiguity in the > specification. And that trigger caused me to remember something that came > up in 2015, because at the time I wrote a draft about it. I haven't taken > the time to dig through the mailing list archives to figure out precisely > what disturbance in the force occurred, but here's the old expired draft: > > https://www.ietf.org/archive/id/draft-jabley-dnsop-ordered-answers-00.txt > > Since it seemed newly pertinent, Sebastiaan and I submitted a new proposal > to resolve the ambiguity in 1034/1035 (I have no good way to authorise a > -01 submission for the 2015 draft, fun as it would have been to have that > draft rise from the grave and walk amongst us). > > 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). > > This seems to us like an uncontentious update to the DNS standard that > would be useful to publish, but let us know what you think. > > Joe > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
