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

Joe Abley <jabley@strandkip.nl> Wed, 14 January 2026 14:58 UTC

Return-Path: <jabley@strandkip.nl>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id ED092A794CF3 for <dnsop@mail2.ietf.org>; Wed, 14 Jan 2026 06:58:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iN67nrSbfEsY for <dnsop@mail2.ietf.org>; Wed, 14 Jan 2026 06:58:47 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [185.233.34.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 6F842A794CEE for <dnsop@ietf.org>; Wed, 14 Jan 2026 06:58:47 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.4.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 4drq4c1rBXzPh for <dnsop@ietf.org>; Wed, 14 Jan 2026 14:58:40 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4drq4b6Tqqz4kC for <dnsop@ietf.org>; Wed, 14 Jan 2026 14:58:39 +0000 (UTC)
Authentication-Results: smtp.soverin.net; dkim=pass (2048-bit key; unprotected) header.d=strandkip.nl header.i=@strandkip.nl header.a=rsa-sha256 header.s=soverin1 header.b=M/n4zjjJ; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=soverin1; t=1768402720; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Jsfb0iSdy6XdPjDycV/5k+lYV2yYS9dR9Fsxhqjgexw=; b=M/n4zjjJyf0aSDLDotpz5dpC9+t/2uzGgECTw+V0C3YcoSXM6lG6AnaKwFd5H8P7ljIUPu 4ScZKrvQIiwDqQSddCiEF/HNEy+Y7ec9VJJXgOJGdjUYtIEtOO8O6GccjmqOSGbe0ra6qo 1J/JjhfVtPz576Oj9RGH0uQDW8UI+KMfxY2I62NXLgPftp9QKgAPZBZVVudeeSaGL3O58l XjTFF0k1BfhZPOevYMyKVe4Kh9o9kwBM5P4SVYDDlaYBjmzHrsZLvTfbSUBWqRp6n2MbNp aVrLr5+HE2N10CwTMq4G4VzlNNbBFaVwjj03z4SN1U+TuEUXVQrcvcJ9ABfphw==
X-CMAE-Score: 0
X-CM-Analysis: v=2.4 cv=I7afRMgg c=1 sm=1 tr=0 ts=6967af20 a=ho4XIa1ZauJg8SqrxOdBPg==:617 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=EG7W4yiQAAAA:8 a=48vgC7mUAAAA:8 a=AvCo47uy6PrENAzBjMYA:9 a=CjuIK1q_8ugA:10 a=ADiJHLWpjGBBXEl7-v_j:22
X-CM-Envelope: MS4xfI8W7RXpjMwUBETM0B6KCj034PXEhUIZAvjywJ/gA/rKxNcTQ6L/Oivoud+Vw+kKi3sjXNOnyOKG9QRM6ueVZt9z5jo8JV0QAluZ5S93axXoy0TKkqfA Z5xp/p5cUib+9l+koLWTiGiXKe4SsYRlAGsXH0H3qXoLvObc4lZ1jbi/ag1qnFGcIgTLjBVs4texF6fM9X6KvD1H/vJ4BNj8cHse0ZCRm/tQD1ZaEdKo2Xe/ o5+8s4Na7xZRKWhJbpyTAg==
X-Soverin-Id: 019bbd04-1500-77c2-922e-893b554b3f9f
From: Joe Abley <jabley@strandkip.nl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.4\))
Message-Id: <9175DF63-77F9-4B4C-9EA9-76B30F941F84@strandkip.nl>
Date: Wed, 14 Jan 2026 15:58:29 +0100
To: dnsop <dnsop@ietf.org>
X-Spampanel-Class: ham
Message-ID-Hash: 5V5JNZQPVR7O32SXXS4PYZ67ULCEBE64
X-Message-ID-Hash: 5V5JNZQPVR7O32SXXS4PYZ67ULCEBE64
X-MailFrom: jabley@strandkip.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] ordering of RRSets in the answer section of a DNS response
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2USkYvbnSIQ8s2vfTL4PrCXeUmM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

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