Re: [DNSOP] Clarifying referrals (#35)

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 28 November 2017 19:50 UTC

Return-Path: <ajs@anvilwalrusden.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 A04CB1200CF for <dnsop@ietfa.amsl.com>; Tue, 28 Nov 2017 11:50:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Yz7dwYQE; dkim=pass (1024-bit key) header.d=yitter.info header.b=Rc8U5sE8
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 c9fjvyskn4t2 for <dnsop@ietfa.amsl.com>; Tue, 28 Nov 2017 11:50:29 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4F3128B88 for <dnsop@ietf.org>; Tue, 28 Nov 2017 11:50:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 19545C06D0 for <dnsop@ietf.org>; Tue, 28 Nov 2017 19:50:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511898628; bh=SZqygspf426Pi/9UzmOWIeU+5VQe8BBTGdyI3h5MguU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Yz7dwYQE1gIFNCTaC3//VFI0b5wd0ZR9l4JYdRtMrb9RhvPBE4tYLcsmrhSvvq0Ar S3KOakj/qsj8OpvUfUfDrT6+VBJVqYv/oRvD7+RO/pFcgjitKNTMtK8wqo0monPvs1 QwYxiOfuP6mgsfrl26QUBTHFr82mP57/AnHfFjxc=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC9TO5c38ztp for <dnsop@ietf.org>; Tue, 28 Nov 2017 19:50:26 +0000 (UTC)
Date: Tue, 28 Nov 2017 14:50:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511898626; bh=SZqygspf426Pi/9UzmOWIeU+5VQe8BBTGdyI3h5MguU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Rc8U5sE8Taukl5RUaxPA8iftzYwurCmn1EOrIBgehWA+Kah9ps2yACwChCtiAFv4U WEXFwSgdFy+3Xa2W9usPuQAs75r9NcLQwXrsqh5soU09hEguhbeczxYtm0UpmWngQm GC6vOkomz1XlxvH8SVQ9+5fMH8we0vvO/Hdz0H5k=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info>
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9QbkjXEWl-r2peZ6tlU2l617GOw>
Subject: Re: [DNSOP] Clarifying referrals (#35)
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: Tue, 28 Nov 2017 19:50:30 -0000

Dear colleagues,

Joe Abley and I have just submitted a draft
(https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
that is intended to capture the discussion here about referrals and
how to describe them.  It is intended for BCP, and it discourages
upward referrals by authoritative servers.

That leaves the task of the referrals definition.  I have some new
text below:

---%<---cut here---

Referral: A type of response in which a server, signalling that it is
not authoritative for an answer, provides the querying resolver with
an alternative place to send its query.  A referral contains an empty
answer section.  It contains the NS RRset for the referred-to zone in
the authority section.  It may contain RRs that provide addresses in
the additional section.  The AA bit is clear.

There are two types of referral response.  The first is a downward
referral (sometimes described as "delegation response"), where the
server is authoritative for some portion of the QNAME.  The Authority
section RRset's RDATA contains the name servers specified at the
referred-to zone cut.  In normal DNS operation, this kind of response
is required in order to find names beneath a delegation.

The second is an upward referral (sometimes described as "root
referral" or just "referral response", as distinct from the delegation
response above), where the server is not authoritative for any portion
of the QNAME.  When this happens, the referred-to zone in the
Authority section is usually the root zone (.).  In normal DNS
operation, this kind of response is not strictly speaking required to
work, and in practice some authoritative server operators will not
return referral responses beyond those required for delegation.

[optional: see draft-sullivan-dnsop-refer-down-00 or whatever.  We'll
only include this reference if the other draft reaches WG consensus
before terminology-bis]

---cut here--->%---

Comments, please.  Also, Joe and I solicit comments on the referrals
draft proper, but it would be nice to put that in a different thread.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com