Re: [DNSOP] New Version Notification for draft-hoffman-dns-terminology-00.txt

Andrew Sullivan <ajs@anvilwalrusden.com> Sun, 30 November 2014 17:34 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB251A1A42 for <dnsop@ietfa.amsl.com>; Sun, 30 Nov 2014 09:34:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.459
X-Spam-Level:
X-Spam-Status: No, score=0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_22=0.6] autolearn=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 uUQeJCjm6wcS for <dnsop@ietfa.amsl.com>; Sun, 30 Nov 2014 09:34:05 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2341A1A3C for <dnsop@ietf.org>; Sun, 30 Nov 2014 09:34:04 -0800 (PST)
Received: from [172.16.34.16] (unknown [50.189.173.0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3B9558A031; Sun, 30 Nov 2014 17:34:03 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <alpine.LSU.2.00.1411301352070.10999@hermes-1.csi.cam.ac.uk>
Date: Sun, 30 Nov 2014 12:34:06 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D48235A-56DC-4B28-823B-06F654C428D1@anvilwalrusden.com>
References: <20141128152445.12986.10641.idtracker@ietfa.amsl.com> <BD6A54D2-B3AF-40C9-8890-B5AF347E9516@vpnc.org> <54789CD9.1030202@gmail.com> <alpine.LSU.2.00.1411281611390.26100@hermes-1.csi.cam.ac.uk> <825329A8-802C-4EA8-AEA5-206D8E37D88D@vpnc.org> <20141129010628.B39882485F19@rock.dv.isc.org> <20141130014512.GE13483@mx1.yitter.info> <alpine.LSU.2.00.1411301352070.10999@hermes-1.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/siFssQIGsznqZKbvte07xzrmmaE
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] New Version Notification for draft-hoffman-dns-terminology-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 30 Nov 2014 17:34:06 -0000

I really like this approach.  Thanks!

-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On Nov 30, 2014, at 9:02, Tony Finch <dot@dotat.at> wrote:
> 
> Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>>> On Sat, Nov 29, 2014 at 12:06:28PM +1100, Mark Andrews wrote:
>>> 
>>> A iterative resolver make RD=0 queries.
>>> A resursive resolver make RD=1 queries.
>> 
>> The problem with that definition, though I guess it is technically
>> most accurate, is that it doesn't help anyone who doesn't already
>> understand the difference.  After all, the second of these only says,
>> "a recursive resolver says that it wants recursion", which is hardly
>> elicidating for the uninitiated.
>> 
>> I think Tony's proposal is on the right track (certainly better than
>> the quick excerpt we did from STD 13, which is at least as confusing).
>> But I think Paul put his finger on the problem with that text: there's
>> no way to know in advance what sort of server you're querying.
> 
> I think it is worth noting that RFC 1034 talks about the resolution
> process, i.e. recursive resolution and iterative resolution - it does not
> talk about iterative resolvers or recursive resolvers. Which sort-of makes
> sense since whether a resolver is being iterative or recursive is to a
> large extent a matter of configuration - as Mark said BIND can do both,
> and this is also true for Unbound, ldns, getdns-api, etc. The exception is
> pure stub resolvers (e.g. the libc resolver or adns) which can only
> perform recursive queries.
> 
> So I think to clarify the terminology, first describe the iterative and
> recursive resolution processes, and mention the expected values of the
> RD,RA,AA bits. Then you can describe the distinctions between recursive
> and iterative clients, and between recursive and authoritative servers, in
> terms of the roles they play in the different resolution processes.
> 
> I would say a full resolver is one that contains a cache and is capable of
> iterative resolution [citation needed]. A stub is (traditionally)
> cacheless and recursive only. There are intermediate cases - a lot of
> stubby resolvers have caches.
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Rockall: Southwesterly 4, increasing 5 to 7, occasionally gale 8 in northwest,
> veering northwesterly 4 or 5 later. Moderate or rough, occasionally very rough
> later in northwest. Occasional rain. Good, occasionally poor.