Re: [DNSOP] RCODE and CNAME chain

Mark Andrews <marka@isc.org> Thu, 27 April 2017 11:13 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29720129329 for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 04:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJF6Eu9nhD0n for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 04:13:58 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0780128BB7 for <dnsop@ietf.org>; Thu, 27 Apr 2017 04:13:57 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 93EFE24AE08; Thu, 27 Apr 2017 11:12:36 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 67B1016003A; Thu, 27 Apr 2017 11:12:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3ED8E160067; Thu, 27 Apr 2017 11:12:37 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cvDLBz_ZRYEb; Thu, 27 Apr 2017 11:12:37 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C7D7C16003A; Thu, 27 Apr 2017 11:12:36 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 789C86D3FE60; Thu, 27 Apr 2017 21:12:34 +1000 (AEST)
To: Florian Weimer <fweimer@redhat.com>
Cc: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= <jv@fcelda.cz>, dnsop@ietf.org, Peter van Dijk <peter.van.dijk@powerdns.com>, muks@isc.org
From: Mark Andrews <marka@isc.org>
References: <20170405054338.GA15831@jurassic> <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> <CAM1xaJ8OOkxw41DzTOBV6yXVmtJVnKGu=4xsP3FWyQGFt36H1g@mail.gmail.com> <20170426230418.096AF6D06C7D@rock.dv.isc.org> <CAM1xaJ-+mUhqiE=TzpB_uy91bF9sxntUkd+ds019QrVvAdo3uw@mail.gmail.com> <20170427093150.59B086D3F5C9@rock.dv.isc.org> <dc68d2d1-e339-99d7-3e14-7102f19b82cc@redhat.com>
In-reply-to: Your message of "Thu, 27 Apr 2017 12:53:35 +0200." <dc68d2d1-e339-99d7-3e14-7102f19b82cc@redhat.com>
Date: Thu, 27 Apr 2017 21:12:34 +1000
Message-Id: <20170427111234.789C86D3FE60@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0bbEYp9RIGunDS4Vt_MvD2veMHg>
Subject: Re: [DNSOP] RCODE and CNAME chain
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2017 11:13:59 -0000

In message <dc68d2d1-e339-99d7-3e14-7102f19b82cc@redhat.com>om>, Florian Weimer writes:
> On 04/27/2017 11:31 AM, Mark Andrews wrote:
> > If you want to advocate for changes to behaviour that is fine, but
> > advocate for that.  Just saying "shouldn't the rcode be NOERROR"
> > isn't doing that.  Then there is DNSSEC.  If the target zone is
> > signed and DO=1 is set in the query should you include the data
> > from the target zone?
> 
> Do you suggest to use data which is impossible to use under the trust 
> rules because it is cryptographically signed?

Yes.  DNSSEC validators do it all the time.  DNSSEC does not
care who supplies the data.
 
> This would mean that many DNSSEC validation bugs turn into critical 
> cache poisoning bugs because they can be used by off-path attackers to 
> poison caches.

And in the last decade how many DNSSEC validation bugs have there
been that have marked answers as secure when they haven't been? 

B.T.W. named has been returning additional as answer if the RRset
validates as secure for about a decade now.

I devised the trust rules for named 20+ years ago now.  They are
designed for dealing with answers that can't be cryptographically
verified.

> (Usually, a single query for an attacker-controlled name 
> would be enough, and it could likely be a PTR query.)  I'm not sure if 
> saving a server round-trip is worth it.  In particular since the 
> recursive resolver already has the infrastructure records for the target 
> in cache if it can do cryptographic validation, it should know exactly 
> where to fetch the target record anyway.
> 
> In general, cryptography as the single line of defense is a very, very 
> bad idea because it almost never works correctly.
> 
> Thanks,
> Florian
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org