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
- Re: [DNSOP] RCODE and CNAME chain Mark Andrews
- Re: [DNSOP] RCODE and CNAME chain Jan Včelák
- Re: [DNSOP] RCODE and CNAME chain Mark Andrews
- Re: [DNSOP] RCODE and CNAME chain Jan Včelák
- Re: [DNSOP] RCODE and CNAME chain Florian Weimer
- Re: [DNSOP] RCODE and CNAME chain Mark Andrews
- [DNSOP] RCODE and CNAME chain Mukund Sivaraman
- Re: [DNSOP] RCODE and CNAME chain Mukund Sivaraman
- Re: [DNSOP] RCODE and CNAME chain Peter van Dijk
- Re: [DNSOP] RCODE and CNAME chain Mark Andrews
- Re: [DNSOP] [Ext] RCODE and CNAME chain Edward Lewis
- Re: [DNSOP] [Ext] RCODE and CNAME chain Donald Eastlake
- Re: [DNSOP] [Ext] RCODE and CNAME chain Mukund Sivaraman
- Re: [DNSOP] [Ext] RCODE and CNAME chain Edward Lewis