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

Ted Lemon <> Thu, 30 April 2020 15:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA04B3A0AEC for <>; Thu, 30 Apr 2020 08:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ZUiqmgGPY60z for <>; Thu, 30 Apr 2020 08:14:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6C213A0A2A for <>; Thu, 30 Apr 2020 08:14:30 -0700 (PDT)
Received: by with SMTP id h124so5995420qke.11 for <>; Thu, 30 Apr 2020 08:14:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GWZJwxshCoaY5ru1yqFkH5C7slqFVYBPnaHKEsKcbK4=; b=N49l0BU0OwUxzTTVf9ECngg+tT9k57WUHiwTCVl/Yrylednvlvnvoy3JZCBpWzKAmS iqpqfN5G24fhAr7maDZu1GZ3P/BtKx0tlDxC7faFKQji5bTb3PdQKhTgv8357m+OIjYN BCVHllxIJXnM5TjZm4iDnX5rt3eSEv/tGbmF6dOZDjE7RjsIgYPjensHjGUhPvKU4aZw RgenjaxWRL+4gzIvO8pBQncBwubGR7HDp/7Plfx4bgTaAbUb1mLYbwpMS+ajk2sLjAIH 2hoN7AMCaPAA0dChEqiXu3+uaJaf4Cn2S6I6X3gIRxN661ltsGEYK83HnjxblwhKQKIx 4g7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GWZJwxshCoaY5ru1yqFkH5C7slqFVYBPnaHKEsKcbK4=; b=ePVcE0IM8CjHED2YCwBVab06YWHSRoISAOkAF3RevM9L8VWQDHqfEZscIIBd/km1O/ Ba/vWEtXOKJ02UU0czrZUmlYKxcwnZ5oeSau3MlZQB0LEPhdG9Sdc2Km52ItA9YxgPK+ BqMpijEGgsNNCHPkBOIQMqKqo0MWJrIjfbuZfKRZyTC51uxPdWoiB7/NH+dvVmSK2a2g mz4+2xosFOLa1EqwyKPK6nC0jHKSjZtU1/Yh+rtvlR4OnKU377z7mIMspbeknPAPFwBK utHp9P8aJPjl6EPAArTDKKYnZ4w+uTlMCxQzIQbCZCqTVL3WrGSCIeJlmd8aB03b2UFH dxUw==
X-Gm-Message-State: AGi0PuYu96htcirFk9KiskTErmvpIjYH+wCwQ/yNDN2shJgeqpJ8owR+ l/iC8nm+QVg4caMiF9FryKbg9+Nfwk8=
X-Google-Smtp-Source: APiQypIGF90UPpGpeOi3rrzSHoneHRRR4g0BZDHxqY/mK5YVOiuQdIXZnPNNBrrk3PZYnvILoRibMw==
X-Received: by 2002:a37:617:: with SMTP id 23mr4159407qkg.11.1588259669737; Thu, 30 Apr 2020 08:14:29 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:e518:6559:325d:1a5f? ([2601:18b:300:36ee:e518:6559:325d:1a5f]) by with ESMTPSA id o43sm2384434qtb.49.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2020 08:14:29 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FB73E39C-F726-4CAD-B69F-B7383AFBBD56"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3636.0.1\))
Date: Thu, 30 Apr 2020 11:14:26 -0400
In-Reply-To: <>
Cc: dnsop <>
To: Shumon Huque <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3636.0.1)
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 15:14:34 -0000

On Apr 29, 2020, at 8:01 PM, Shumon Huque <> wrote:
> 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. 

I don’t think that’s the issue in this case. The CNAME wasn’t signed, so there was never any question of the answer being protected from spoofing. Your conclusion seems unassailable—this answer can’t be called authentic.

> 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.

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.