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

Shumon Huque <> Fri, 01 May 2020 12:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED6893A1123 for <>; Fri, 1 May 2020 05:10:17 -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 DiR5NPJ5xRld for <>; Fri, 1 May 2020 05:10:16 -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 3FF253A1122 for <>; Fri, 1 May 2020 05:10:16 -0700 (PDT)
Received: by with SMTP id n17so7312125ejh.7 for <>; Fri, 01 May 2020 05:10:16 -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=9i38ZMLtv4zg+VySVpKzGWfH6UyLCKQW6B0pN974pis=; b=htWjJ6X+g0PJT7bRBr6XXvFkM06YxvF/Z+wOMitzefZvLEtIRxQopu+auwdxnzToYD SqXzz7wC3dxB+P2yK02hGI+My56NsZLAXywXXPyDH1Dh/wnoNiG1+irFNcGAUBCSkc5m 2H8+oVX+dXdjTuHl/tF5hfzVCUeI4aJ3yNybOWKGVLlHQVwR+WFCcvsMQ7bVKXi+DSnR ieEMT0BbnCRGI0bPLWyIvAK+J3tCCUC6fJSJkSoJYyYGCx1pWslIN54Q6P7amKSU7f8f 0Fp+phNEtP39RRlnPqpj5peHSAGMjkUhtKvC6l2eEQqQDpgdSRgatGXNG5f7d51SalGz j9Bg==
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=9i38ZMLtv4zg+VySVpKzGWfH6UyLCKQW6B0pN974pis=; b=Fff4RX9zYBwZ/QUC9ZAS066va7AEvfyUMvdMLfuZQZiDtsluSlmNJliTuXtX6xkazE /K952aYEKQBi6oRwlO/7/C3GPIMfBfP6GlpwPDWqgcok8GD8MCdUI3poldyQuBUrs6Ax d0EEko9E3qpJtmqpuz1429bEVWxQsyAci6deiNqZzwGrxv0L1quWRrrUH0gCeNUG0oFE P8fb6YUD/v7sH8zy9g+1IE32Mo4y4kAH76hpiz1lD2RSLABybEb8pM1gPtf8AFk8nH8K 8Wp2BU/gKeKWYfzZFlOh5TWBQCkg2Ko3vIdibPZ3eE75q0NzWiZ2sX2NCrbKg9xA5A26 iUKg==
X-Gm-Message-State: AGi0PubysqrqzZfs88RUh+JqQLzL4RGUIGfSd9JTW8M4Cq5EI8evmPw0 /DPYys9V2Cbc1kwqmDib1j7KKW6nnQlEkv/E3DmweiEu
X-Google-Smtp-Source: APiQypIg3APub5QpgtrOAyMiLSPomh6g2QCr8ZKsfGwtSWYbYOp1yTUCAr1TgYOmWrAqvO3gZgW0L3EkotOzeR2L7jw=
X-Received: by 2002:a17:906:5347:: with SMTP id j7mr2234947ejo.173.1588335014489; Fri, 01 May 2020 05:10:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Fri, 01 May 2020 08:10:02 -0400
Message-ID: <>
To: Ted Lemon <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="00000000000052b4fd05a4951018"
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: Fri, 01 May 2020 12:10:18 -0000

On Thu, Apr 30, 2020 at 11:14 AM Ted Lemon <> wrote:

> To be clear, I think that if we’ve been asked to do DNSSEC, we should
> always validate what we can when the answer includes some data that is
> provably insecure and some data that is provably secure and can be
> validated. I just don’t think the specs explicitly say that, so I’m
> wondering if people agree with me on this.

Yes, I completely agree.

Whether or not the specs (clearly) state this is debatable. I quickly
scanned 4035 again, and I believe it is implied, from a combination of :

* Section 3.2.3 saying _all_ RRsets in the answer section, and relevant
RRsets in the authority section need to be authenticated before determining
whether AD=1 can be set, and the further statement that the resolver MUST
follow the procedure in Section 5 to determine whether the RRs are

* Section 5 , which describes full chain DNSSEC authentication.

This implies to me that _any_ RRset that the validator is processing needs
to be subjected to the full DNSSEC validation algorithm to determine its
security state.

CNAME redirections aren't explicitly described, but are arguably covered by
the above. The only mention of the CNAME case, is the exception to 3.2.3
that allows unsigned CNAMEs to be included in the answer and assessed to be
authentic because they were provably synthesized by a signed DNAME.