IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Sun, 18 January 2026 23:40 UTC

Return-Path: <marka@isc.org>
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 4F13FA973B3F for <dnsop@mail2.ietf.org>; Sun, 18 Jan 2026 15:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_MED=-2.3, 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 (1024-bit key) header.d=isc.org header.b="FuGeJXpw"; dkim=pass (1024-bit key) header.d=isc.org header.b="S1+0lnu4"
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 g_RgEq6k347Y for <dnsop@mail2.ietf.org>; Sun, 18 Jan 2026 15:40:08 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (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 BB473A973B37 for <dnsop@ietf.org>; Sun, 18 Jan 2026 15:40:08 -0800 (PST)
Received: from zimbra10.isc.org (zimbra10.isc.org [149.20.2.90]) (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) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 020744E49C0; Sun, 18 Jan 2026 23:40:08 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 020744E49C0
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.90
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1768779608; cv=none; b=JPOmPNLSnmI9g0LbcVP1eQqtqjSibBGs5uokQrtApZOalnu8Ke9EFcOSFIvziRmRrI/8HdyZu1yxUiu+xY3soajDv/rtQu34Wumvnx46NV1oRyGS8YZ2yrmByXYdeyM6JQbEhat5xPcfLu5TIhb2Peu3TbZXAMupOU6R+cSBYbo=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1768779608; c=relaxed/relaxed; bh=sdB3ziiDLOtbnL6FYZVqISCj5EGms3eRG+w91HsqtgY=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=m9lXunvRTtaqsAUCYuFDmcQvv8ZyozlaPhEB3A7rhkrj4iRXKEcraCP6o8FUq8LpQYdXpv1PSi442/VnsHhJkXUucm65xSwLOkFpml0YT/21rxNpYFrdrEbssTJrq6PMH39Ulf5RKleqlJJYkhYzJGEV6zFwHwxT0O06Z7nqlPw=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 020744E49C0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1768779608; bh=Xt/jpKYgRDhvUXaBqWMyWvBnCURWGmmU+8AQpHg8D2c=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=FuGeJXpwTtwYhCOw6RVG4RT8xEklySwLfNbc6hc6jApJNNqy9icCQO0LME2bYhQ0n /uvCCVMbtIx7+XKOBh7ABnXiuOP+h10OOT80b8F705k65VwU4NAxOL3/MKjURyZjWI 0WTQN8GZbRbeGctRr4QKczN+DmW2zqtg+7MrBlPg=
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id F171D2E602A0; Sun, 18 Jan 2026 23:40:07 +0000 (UTC)
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id EDC512E602C5; Sun, 18 Jan 2026 23:40:07 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra10.isc.org EDC512E602C5
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1768779607; bh=sdB3ziiDLOtbnL6FYZVqISCj5EGms3eRG+w91HsqtgY=; h=Mime-Version:From:Date:Message-Id:To; b=S1+0lnu4rBclEzuyZzOiAhk8e5UjdUl1QJSBiLbDrjDnu5AC2tYIRLAs0jq9F+I0+ VXoS0VF6y/Nl3jVp+xlyNdNdLzHRggACmpL/La6iCaucgH+/8k0eNLuAYJ5r6F4yw2 HAfe9wn7mwcn4HMR9t+gyz5fM/hB03EDNSuoPs8I=
Received: from smtpclient.apple (unknown [49.187.18.238]) by zimbra10.isc.org (Postfix) with ESMTPSA id 6D4862E602A0; Sun, 18 Jan 2026 23:40:07 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.21\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAJZkTRcRYSdzNyPscUr=F6OA7BNQsdm5ttqOa7PfvNOqpc+sYA@mail.gmail.com>
Date: Mon, 19 Jan 2026 10:39:55 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <13FFEEBE-12CE-4C1A-B9C7-DA545A643AD6@isc.org>
References: <CAJZkTRcRYSdzNyPscUr=F6OA7BNQsdm5ttqOa7PfvNOqpc+sYA@mail.gmail.com>
To: X L <idealeer521@gmail.com>
X-Mailer: Apple Mail (2.3731.700.6.1.21)
Message-ID-Hash: UOT5VFEVIQRBVDHSVDEJ32UOGL6X2IWS
X-Message-ID-Hash: UOT5VFEVIQRBVDHSVDEJ32UOGL6X2IWS
X-MailFrom: marka@isc.org
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
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: 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/2xRbYqpLOjkO3DoYJ2biAzuAsGo>
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>

CNAME records are supposed to be singletons.  If we want to specify anything it should be
to reject answers with multiple CNAME records with the same owner name, however this is the
wrong draft to do that.

> On 15 Jan 2026, at 12:06, X L <idealeer521@gmail.com> wrote:
> 
> Hi Joe,
> 
> About the "CNAME-restart logic" mentioned in https://blog.cloudflare.com/cname-a-record-order-dns-standards/,
> we have tested mainstream resolver's behaviors in our USENIX Security 2023 paper.
> There could be mutiple CNAME records for one qname. Different resolvers have 
> unique processing logic when doing the CNAME chaining (CNAME-restart you called).
> 
> CNAME Chaining:
> https://www.usenix.org/system/files/usenixsecurity23-li-xiang.pdf
> (Section 4.1 and Table 2)
> 
> Third, we also found that the resolver can select a CNAME record from all the CNAME records embedded in R (during U pdateQuery) and query the closest server in the cache, but the implementations differ. BIND, Unbound, MaraDNS, and Simple DNS Plus use the first CNAME record to issue the following query Q, while Knot Resolver and PowerDNS Recursor use the last CNAME record. Microsoft DNS selects a random CNAME record to lookup.
> 
> Xiang Li
> Nankai University
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.46.0 | Report a Bug | By Email | System Status