Re: [DNSOP] Clarifying referrals (#35)

Florian Weimer <fweimer@redhat.com> Thu, 30 November 2017 11:14 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 695F21271DF for <dnsop@ietfa.amsl.com>; Thu, 30 Nov 2017 03:14:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 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, 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 GNIWwTmkSy7v for <dnsop@ietfa.amsl.com>; Thu, 30 Nov 2017 03:14:29 -0800 (PST)
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 A93CE129431 for <dnsop@ietf.org>; Thu, 30 Nov 2017 03:14:29 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6693E356FF; Thu, 30 Nov 2017 11:14:29 +0000 (UTC)
Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D0DF75D6A9; Thu, 30 Nov 2017 11:14:28 +0000 (UTC)
To: Andrew Sullivan <ajs@anvilwalrusden.com>, dnsop@ietf.org
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <3eb246b2-59bd-ecc3-51f8-98d7e0a5b078@redhat.com>
Date: Thu, 30 Nov 2017 12:14:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info>
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.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 30 Nov 2017 11:14:29 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/p6lyy2neVP74Y_ozpyeQsoPYOEI>
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: Thu, 30 Nov 2017 11:14:32 -0000

On 11/28/2017 08:50 PM, Andrew Sullivan wrote:
> 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.

Is the goal to describe behavior of current (and perhaps past) 
implementations, or what the behavior should be under ideal circumstances?

Thanks,
Florian