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

Shumon Huque <> Thu, 30 April 2020 00:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FF9C3A0AF5 for <>; Wed, 29 Apr 2020 17:01:53 -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 93nM0GR451X7 for <>; Wed, 29 Apr 2020 17:01:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07DC63A0ADA for <>; Wed, 29 Apr 2020 17:01:50 -0700 (PDT)
Received: by with SMTP id t12so3064639edw.3 for <>; Wed, 29 Apr 2020 17:01:50 -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=KU1r7FU6WjBn+tJbzP7Kfd15R+YOAROEKdXyP5mdZ6Q=; b=HfykLDTO3/uzSRN/KjmqDVLoGoqtdNL6iKsi2oq+X7fOxRWCTvK9Y8CsMB25ewLgb5 8w2vOisQIsdvOs91ynzTcoDOU1owQK9MgO/WSZaqSVAt7OIw9fEX+NEpad7LUULmcx65 hjRC29NXoTs/khi8sAwtzRfrcaQuhqB/MDmffkhxV61L6mpOSnSWWsZx7o5LVNLdfN/d fRS4zwCpGj39P0WJl8s1D4kSj/azmrSQIYESWEUmnVXOUfxHUqNf4Gko7FOjJg0rcZKX 8UXHSNw4iUt6AhvK/bl8EaRjs0T3J+KNJmEezTtw82wry+hRPX5/lkvPT7J01qQ/rD0G 6owQ==
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=KU1r7FU6WjBn+tJbzP7Kfd15R+YOAROEKdXyP5mdZ6Q=; b=IGEx8vxzHrejWSoTezeJEpjI9PeH3qGUPcO0tsZJL9ldpPO0nsSgY22zuePzkPu8DO eTcEldZz4bLvNb65Qca6vl27vxS4BOF8269NKRnilOju2u/pxG3DSUYArWFifU8BA4M/ k8Xy0K+0dsqE2ylM16k32a3cT1cv9yxOBJfjiXXrEeg5KT3tyE3kZElMR8BxuJ3+NbrO cC0cajQLtvPLvWDIoofhB4LZBHYMCnPgZzJvvOTz1O/WvpU0OYdRaECToluYonNhCc/e ukjCfxPXHKlMiWx9QTFLKEdslVDhO31UtPJPfISnsL/oPNB5xr7ccA3i5cUg3+mvfdtO cfjA==
X-Gm-Message-State: AGi0PuZ2ENR0xPV2ROWHlfG7skYu0dIKcGMHp3edov+4uDB59p+QFCdI 6unQ68g0lOVFhQCjw7rVF5VIbNtEnCbxWVYgWnI=
X-Google-Smtp-Source: APiQypLPbjgppr5n0aifCJz5wGMs8tSSwhu3DBx87KDnjrLPzL3SsxFMXChA8GbmTte6CK7BSD+JUUdSh7xpRIcRYFE=
X-Received: by 2002:a50:9547:: with SMTP id v7mr436073eda.324.1588204909027; Wed, 29 Apr 2020 17:01:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Wed, 29 Apr 2020 20:01:37 -0400
Message-ID: <>
To: Ted Lemon <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="0000000000006ee4f605a476c537"
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: Thu, 30 Apr 2020 00:02:01 -0000

On Wed, Apr 29, 2020 at 7:30 PM Ted Lemon <> wrote:

> The question is, if the stub resolver can validate, and has been asked to
> validate, in that case what do we do if the CNAME is not in a secure zone?
> Your response makes it sound like you know the answer, but I don’t think
> it’s specified anywhere. So I’m asking (a) if anybody knows that is
> specified somewhere, and if so where, and (b) if it is not specified, what
> do we all think the correct answer is.

If there is an unsigned CNAME (or DNAME) in the path the answer, then I'm
100% sure that the answer cannot be deemed authenticated. You may be right
that this case is not clearly explained in the spec (I can't recall really,
maybe some else can quote specific text if they know). But conceptually,
DNSSEC requires you to prove an unbroken chain of authenticated signatures
from the queried name back to the trust anchor (including paths redirected
via aliases). Otherwise attackers have a trivial points (the unsigned
aliases) at which to spoof answers.

The answer obtained is still viable, just insecure. Downstream clients of
the stub that need confirmed authenticated answers (e.g. DANE) could
determine this by inspecting the AD bit in the response from the stub.

Your answer actually brings up a second, also interesting, question: if a
> stub resolver sets the DO bit, and the CNAME is not in a secure zone, but
> the answer is in a secure zone, do we set the AD bit? It looks like
> according to RFC4035, section 3.2.3, we do not. So in that case, is the
> resolver obliged to validate the answer it gets by following the CNAME? It
> can’t set the AD bit in this case, right?

It definitely can't set the AD bit. So, I suppose your argument is why
bother authenticating the target. That's a defensible question. It might be
reasonable behavior if the stub has no cache. But I'd expect validating
stubs to have some sort of cache to amortize the cost of extra queries and
computation. If it's caching, then the unvalidated target cannot reasonably
be returned if a subsequent query comes directly for the target, so why
would it not bother to validate it earlier.