MIME-Version: 1.0
References: <1EA6A13C-6E60-4ED9-9A50-E33D9D17504C@fugue.com>
In-Reply-To: <1EA6A13C-6E60-4ED9-9A50-E33D9D17504C@fugue.com>
From: Shumon Huque <shuque@gmail.com>
Date: Wed, 29 Apr 2020 18:56:03 -0400
Message-ID: <CAHPuVdXWqA8Lu+Xy-rnad9UQvvAfawLk6-+G=GLCmGuMjfoZWA@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fc3dd105a475dafb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9HtV-er2Aow-ugws9pOUdLEILJs>
Subject: Re: [DNSOP] Validating responses when following unsigned CNAME
 chains...
Precedence: list

--000000000000fc3dd105a475dafb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 29, 2020 at 5:50 PM Ted Lemon <mellon@fugue.com> wrote:

> Is there an RFC or draft that talks about what the right thing is to do
> when an unsigned CNAME points to a record in a signed zone?

That is, suppose we are doing validation. The CNAME doesn=E2=80=99t validat=
e,
> because it=E2=80=99s not signed. When we look up the record the CNAME poi=
nts to, do
> we set the DO bit? Do we validate the answer? Or do we assume that becaus=
e
> the CNAME isn=E2=80=99t signed, we don=E2=80=99t need to validate what it=
 points to?
>

Hi Ted,

I believe a validating resolver always sets the DO-bit in outbound queries.
The answer in your example can't be authenticated (i.e. no AD bit can be
set) because not all the answers (namely the CNAME) in the response have
been authenticated (per RFC 4035, Section 3.2.3).

But a resolver would still authenticate the RR type at the signed target of
the CNAME (assuming the target has an unbroken chain to the trust anchor),
and record that RRset as authenticated. Otherwise, if it later received a
query directly for the target name/type, it could not return the answer
that it incorrectly didn't bother to authenticate.

Shumon.

--000000000000fc3dd105a475dafb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Apr 29, 2020 at 5:50 PM Ted Lemon=
 &lt;<a href=3D"mailto:mellon@fugue.com">mellon@fugue.com</a>&gt; wrote:<br=
></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Is there an RFC or draft that talks about what the right thing i=
s to do when an unsigned CNAME points to a record in a signed zone?=C2=A0</=
blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That is, suppose we are doing validation. The CNAME doesn=E2=80=99t validat=
e, because it=E2=80=99s not signed. When we look up the record the CNAME po=
ints to, do we set the DO bit? Do we validate the answer? Or do we assume t=
hat because the CNAME isn=E2=80=99t signed, we don=E2=80=99t need to valida=
te what it points to?<br></blockquote><div><br></div><div>Hi Ted,</div><div=
><br></div><div>I believe a validating resolver always sets the DO-bit in o=
utbound queries. The answer in your example can&#39;t be authenticated (i.e=
. no AD bit can be set) because not all the answers (namely the CNAME) in t=
he response have been authenticated (per RFC 4035, Section 3.2.3).</div><di=
v><br></div><div>But a resolver would still authenticate the RR type at the=
 signed target of the CNAME (assuming the target has an unbroken chain to t=
he trust anchor), and record that RRset as authenticated. Otherwise, if it =
later received a query directly for the target name/type, it could not retu=
rn the answer that it incorrectly didn&#39;t bother to authenticate.</div><=
div><br></div><div>Shumon.</div><div><br></div></div></div>

--000000000000fc3dd105a475dafb--