Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

Evan Hunt <each@isc.org> Fri, 13 April 2018 17:35 UTC

Return-Path: <each@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 738F3127369 for <dnsop@ietfa.amsl.com>; Fri, 13 Apr 2018 10:35:22 -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, 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 e1a1zaqfT5zB for <dnsop@ietfa.amsl.com>; Fri, 13 Apr 2018 10:35:20 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29DC127010 for <dnsop@ietf.org>; Fri, 13 Apr 2018 10:35:20 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CDA7B3AB042; Fri, 13 Apr 2018 17:35:14 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id B534B216C1C; Fri, 13 Apr 2018 17:35:14 +0000 (UTC)
Date: Fri, 13 Apr 2018 17:35:14 +0000
From: Evan Hunt <each@isc.org>
To: Mukund Sivaraman <muks@mukund.org>
Cc: bert hubert <bert.hubert@powerdns.com>, dnsop@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Message-ID: <20180413173514.GA29212@isc.org>
References: <20180413144707.GA4767@server.ds9a.nl> <623F11C7-6E4D-40F5-8AD1-8F7E92C8C7F9@vpnc.org> <20180413151152.GB4767@server.ds9a.nl> <20180413163135.GA28695@isc.org> <20180413171330.GA7241@ponyo.lan.banu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180413171330.GA7241@ponyo.lan.banu.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gAlO1KXRBNPEO9Uxnsb-xaRV6UQ>
Subject: Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested
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: Fri, 13 Apr 2018 17:35:22 -0000

On Sat, Apr 14, 2018 at 01:13:30AM +0800, Mukund Sivaraman wrote:
> On Fri, Apr 13, 2018 at 04:31:35PM +0000, Evan Hunt wrote:
> > I could have sworn there was an RFC published several years ago concerning
> > the prevention of cache poisoning, which specified that resolvers had to
> > ignore out of zone CNAMEs and re-query, but I can't find it now. Poor
> > google skills, or did I dream the whole thing?
> 
> RFC 2181

That was a "should", not a MUST. I thought I remembered something that
upgraded it to MUST, but I can't find it now.

It's possible I was thinking of RFC 5452 (which I now see was authored by
the person whose question I was answering -- *this* is how you suck eggs,
grandma).  It says, "Care must be taken to only accept data if it is known
that the originator is authoritative for the QNAME or a parent of the
QNAME.  One very simple way to achieve this is to only accept data if it is
part of the domain for which the query was intended." This is less
strongly-worded than what I remembered, but at least it does strongly hint
that returning out-of-zone CNAMEs is likely to be a waste of effort.

When we do the 1034 bis I'd like to see this made more explicit.

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.