Re: [DNSOP] RCODE and CNAME chain

Florian Weimer <fweimer@redhat.com> Thu, 27 April 2017 10:53 UTC

Return-Path: <fweimer@redhat.com>
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 37FAD128B93 for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 03:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level:
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Y1R98-Y1nl_6 for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 03:53:39 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4210128B8E for <dnsop@ietf.org>; Thu, 27 Apr 2017 03:53:39 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2A7097E9F2; Thu, 27 Apr 2017 10:53:39 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2A7097E9F2
Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2A7097E9F2
Received: from oldenburg.str.redhat.com (ovpn-117-221.ams2.redhat.com [10.36.117.221]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D47638909B; Thu, 27 Apr 2017 10:53:36 +0000 (UTC)
To: Mark Andrews <marka@isc.org>, Jan Včelák <jv@fcelda.cz>
Cc: dnsop@ietf.org, Peter van Dijk <peter.van.dijk@powerdns.com>, muks@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>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <dc68d2d1-e339-99d7-3e14-7102f19b82cc@redhat.com>
Date: Thu, 27 Apr 2017 12:53:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <20170427093150.59B086D3F5C9@rock.dv.isc.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 27 Apr 2017 10:53:39 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CYyxeF5uWa_CUPpmhjmGY_a7yH0>
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 10:53:41 -0000

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?

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