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: <m1vghuo-0000McC@stereo.hq.phicoh.net>
Date: Mon, 19 Jan 2026 10:15:15 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E9345AE8-6D35-49E0-97B2-E3F41747FB7E@isc.org>
References: <9175DF63-77F9-4B4C-9EA9-76B30F941F84@strandkip.nl>
 <e48c41c3-86cf-4e1f-a9ab-195426bdea17@nic.cz>
 <20260115022930.C70F4F11E0CD@ary.qy> <877bth4z9c.fsf@mid.deneb.enyo.de>
 <m1vghuo-0000McC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-dnsop-7@u-1.phicoh.com>
Message-ID-Hash: ZZTBGXPEQS7NQMLGSB2LSO4DBOLS2USI
CC: dnsop <dnsop@ietf.org>, Florian Weimer <fw@deneb.enyo.de>
Precedence: list
Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_ordering_of_RRSets_in_the_answer_section_of_a_DN?=
 =?utf-8?q?S_response?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsop/tswBQPTKWIjwl3pde_0eUQVG87A>



> On 16 Jan 2026, at 22:22, Philip Homburg <pch-dnsop-7@u-1.phicoh.com> =
wrote:
>=20
>> Can stubs just ignore CNAMEs and just extract addresses from A and
>> AAAA records found in the answer section?
>>=20
>> Assuming that the internal stub interfaces eventually discard CNAME
>> data anyway, that would actually result in a simplified =
implementation.
>>=20
>> The current code with CNAME matching allows the upstream server to
>> include unrelated addresses in the answer section that will be
>> ignored.  Retaining this behavior, while relaxing the CNAME ordering,
>> requires quite a bit of extra complexity in stubs.
>=20
> There is a problem with that if the stub relies on a DNSSEC validating =
proxy
> (or if the stub has a DNSSEC validator that just implements the =
specs.)
>=20
> As far as I know, DNSSEC requires the validator to validate every =
RRset in
> the answer and authority sections. It also requires the validator to=20=

> verify that there is proof of NXDOMAIN or NODATA. However, there =
doesn't
> seem any requirement that the validator removes unwanted data.

There is no such requirements. You may be thinking of setting AD=3D1 =
where the
validating resolver is asserting that every RRset in the ANSWER and =
AUTHORITY
sections of the response it is producing has been validated as secure.

Note AD=3D1 is only supposed to be accepted if you trust the resolver =
and can
verify that the answer as not been tampered with.

> That means that an attacker can insert extra RRsets and the stub =
resolver
> believes it is secure because it is behind a DNSSEC validator. So at
> the moment, the only option for the sub resolver is to follow the =
CNAME=20
> chain.
>=20
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org

--=20
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org