Re: [DNSOP] Validating responses when following unsigned CNAME chains...

Shumon Huque <> Wed, 29 April 2020 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C523A3A0AFD for <>; Wed, 29 Apr 2020 15:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h65-1mswKyOW for <>; Wed, 29 Apr 2020 15:56:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 753173A0A69 for <>; Wed, 29 Apr 2020 15:56:17 -0700 (PDT)
Received: by with SMTP id s3so3026726eji.6 for <>; Wed, 29 Apr 2020 15:56:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gj09NClQnLQ8UC0x5d23IA4ClcGjoOyGp0eOaLB4O10=; b=U+1LdvYR1PU9WN0V14hVSbK00RYaKAUxHi7rZWVjzuBWsWrTyNDgtAJA+Rz+fXkrwK JqodomRwXBksRcPayfoDNZUO9BXuadbTv16z/CnHhsGm3BQTWhnCyop0qSq6ixp20Uwp cH0Z1IkzvTRq60icX6J2OUeccat2cd+jH3LoLLq/QNngXBxtFYmaGziZX9h3zgpd9T2f i+MWEVohDoplFyQYsb7Je98rtvTGV0wTXUFQPhkATo1fJ7aMWb6Rf3JYoE5CtVVX7nDs on82HfDMxQZ/xYqpOjFTxPM8F4elKfm3lLrhSnEVGkX8hEwPCydAWlWGv5TlpNDSvfqo 6bww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gj09NClQnLQ8UC0x5d23IA4ClcGjoOyGp0eOaLB4O10=; b=VfmOr9oq31mvcfLAN+QFYHo3rIoYV6wkhMaJT1KP6pgO8a1uilHKgLAuQqrtf3AAOo pWrAAFEAPcem69+eygjUBHBdzhd+tc1UVX3POCi6T1CCtk6HgqgnwmG73wndOcRHdrqe YQaN8EkJW8yuT3Hy+5bb79sXJxHjyeGcvMKwKSOJGcNGJPITjjPuAx109S9Fd9q/Q8Lm iRnAbQUAVfNCu/kHn+qvOjeAtvLiqA7keBHLiVNMuOykG8rlB/RtB22YYQZa4fI4V1ST LM6K55xTh78Ov7S0+IXbJOD0DJylgQdtOOv6GY7/M+Lgckyq9JO60WAnmopcJNeAS4yh fMrA==
X-Gm-Message-State: AGi0PuYk56oFGbZl6+dtQqK476j9EkIwmHHl1rgS4K9+PHmAzpLzyINM Hx5yU8umvmkPUQXw/MZx9KwTmD8XkrpqoUrvk4c=
X-Google-Smtp-Source: APiQypJBQcnUeqXn+H4iQx4ec3R4XgF+v0Lu2zlean2mgjwt8jEGAXynKEAMLEW9oQ1pOC789hMcIh4ZOhLXfpYo79Q=
X-Received: by 2002:a17:906:2acf:: with SMTP id m15mr71668eje.173.1588200975644; Wed, 29 Apr 2020 15:56:15 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Wed, 29 Apr 2020 18:56:03 -0400
Message-ID: <>
To: Ted Lemon <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000fc3dd105a475dafb"
Archived-At: <>
Subject: Re: [DNSOP] Validating responses when following unsigned CNAME chains...
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Apr 2020 22:56:55 -0000

On Wed, Apr 29, 2020 at 5:50 PM Ted Lemon <> 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’t validate,
> because it’s not signed. When we look up the record the CNAME points to, do
> we set the DO bit? Do we validate the answer? Or do we assume that because
> the CNAME isn’t signed, we don’t 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.