Re: [DNSOP] Please review the definitions around "recursive" in terminology-bis

Evan Hunt <each@isc.org> Mon, 12 March 2018 18:10 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 BDB451200C5 for <dnsop@ietfa.amsl.com>; Mon, 12 Mar 2018 11:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XPPfZarMn763 for <dnsop@ietfa.amsl.com>; Mon, 12 Mar 2018 11:10:38 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 952011200B9 for <dnsop@ietf.org>; Mon, 12 Mar 2018 11:10:38 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.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 0F3383AB044; Mon, 12 Mar 2018 18:10:35 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id EA0E0216C1C; Mon, 12 Mar 2018 18:10:34 +0000 (UTC)
Date: Mon, 12 Mar 2018 18:10:34 +0000
From: Evan Hunt <each@isc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: dnsop <dnsop@ietf.org>
Message-ID: <20180312181034.GA12659@isc.org>
References: <5495D079-93C8-4A61-9329-DBB3AD3D2B67@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5495D079-93C8-4A61-9329-DBB3AD3D2B67@vpnc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JNrqgM3hWFfu-v1qAhjUiv3scdY>
Subject: Re: [DNSOP] Please review the definitions around "recursive" in terminology-bis
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, 12 Mar 2018 18:10:40 -0000

Yes please. I'd start off by noting that "recursive" (like "resolver") is
used in several different ways and a single clear definition isn't
possible.

"Recursive mode" is currently defined as "receiving a query and then either
answering from a cache or sending a query to other servers" -- which seems
overly broad to me; it could include a caching forwarder, which isn't what
I think of as "recursion", though of course others may differ.

The RA and RD bits are defined as "recursion desired" and "recursion
available", which at least implicitly suggests that "recursion" means
whatever a server does in response to those bits.

RFC 1034 discussed "recursive" and "iterative" as separate and distinct
concepts in distributed database design... but the DNS uses an iterative
process to implement recursion. A "recursive resolver", "iterative
resolver", and "full resolver" are pretty likely to be the same thing.
(This isn't very clear from the definitions of either "recursive mode" or
"iterative mode" in the current text, btw. See the terminology section in
RFC 4697.)

I don't think any one explanation can meaningfully reconcile all of
these; I think we need a list of possible meanings, and maybe a
Venn diagram, discussing the various shades of meaning in "stub",
"recursive/recursion", "iterative/iterating", "forwarder/forwarding",
"validator/validating", "cache/caching", and "resolver", so that
there's a good chance someone can guess at the meaning when several
of those words are chained together, as they often are.

I don't have any text to offer at the moment, but I'll give it some
thought.

On Mon, Mar 12, 2018 at 08:09:27AM -0700, Paul Hoffman wrote:
> Greetings. The definition of "recursive resolver" has been problematic 
> both in RFC 7719 and in draft-ietf-dnsop-terminology-bis. Section 6 of 
> draft-ietf-dnsop-terminology-bis defines a bunch of terms about servers, 
> including "recursive mode" and "recursive resolver". The current text 
> gives:
> 
>     Recursive mode:  A resolution mode of a server that receives DNS
>        queries and either responds to those queries from a local cache 
> or
>        sends queries to other servers in order to get the final answers
>        to the original queries.  Section 2.3 of [RFC1034] describes this
>        as "The first server pursues the query for the client at another
>        server".  A server operating in recursive mode may be thought of
>        as having a name server side (which is what answers the query) 
> and
>        a resolver side (which performs the resolution function).  
> Systems
>        operating in this mode are commonly called "recursive servers".
>        Sometimes they are called "recursive resolvers".  While strictly
>        the difference between these is that one of them sends queries to
>        another recursive server and the other does not, in practice it 
> is
>        not possible to know in advance whether the server that one is
>        querying will also perform recursion; both terms can be observed
>        in use interchangeably.
> 
>     Recursive resolver:  A resolver that acts in recursive mode.  In
>        general, a recursive resolver is expected to cache the answers it
>        receives (which would make it a full-service resolver), but some
>        recursive resolvers might not cache.
> 
> That is, "recursive mode" is only barely defined in RFC 1034, and 
> "recursive resolver" is defined almost trivially.
> 
> Can these be improved on? This is one of the core ideas in the DNS 
> protocol and it seems a bit weird that we don't have a crisp set of 
> definitions. If there is more text from RFCs to quote, that would 
> possibly be a big help.

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