Re: [DNSOP] refer-down

Mukund Sivaraman <muks@isc.org> Mon, 28 May 2018 17:47 UTC

Return-Path: <muks@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 40B97126DCA for <dnsop@ietfa.amsl.com>; Mon, 28 May 2018 10:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 zJFY98ro1ABn for <dnsop@ietfa.amsl.com>; Mon, 28 May 2018 10:47:44 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6D138126B6E for <dnsop@ietf.org>; Mon, 28 May 2018 10:47:44 -0700 (PDT)
Received: from jurassic (unknown [182.156.98.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 744CB32C06F2; Mon, 28 May 2018 17:47:40 +0000 (UTC)
Date: Mon, 28 May 2018 23:17:33 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Cc: dnsop@ietf.org
Message-ID: <20180528174733.GA26171@jurassic>
References: <20180528172212.GE12038@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180528172212.GE12038@mx4.yitter.info>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4t3wlhzEMhpcZHM9mTMRMRT7N2k>
Subject: Re: [DNSOP] refer-down
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: Mon, 28 May 2018 18:06:36 -0000

Hi Andrew

On Mon, May 28, 2018 at 01:22:12PM -0400, Andrew Sullivan wrote:
> Dear colleagues,
> 
> As a consequence of some of the discussion about clarifying the term
> "referrals" in terminology-bis, it became clear that we didn't really
> have a place that said not to do upward referrals.  So, Joe Abley and
> I put this little draft together:
> 
> https://tools.ietf.org/html/draft-sullivan-dnsop-refer-down-00
> 
> I _think_ it is useful, but it didn't get much comment when we put it
> out because everyone was paying attention to the terminology
> document.  Does anyone else think it's useful?  If so, and some people
> are prepared to do some reviews, I'm prepared to work on it.  But it's
> about to expire, and if nobody else thinks it's worth the wasted
> electrons I don't feel strongly enough about it to have the fight.

RFC 1034 mentions how to handle upward referrals - ignore them. Section
5.3.3:

If the response shows a delegation, the resolver should check to see
that the delegation is "closer" to the answer than the servers in SLIST
are.  This can be done by comparing the match count in SLIST with that
computed from SNAME and the NS RRs in the delegation.  If not, the reply
is bogus and should be ignored.  If the delegation is valid the NS
delegation RRs and any address RRs for the servers should be cached.
The name servers are entered in the SLIST, and the search is restarted.

But I do note the difference that your document is about "don't create
upward referrals" whereas the above is "don't accept upward referrals".

		Mukund