[DNSOP] Please review the definitions around "recursive" in terminology-bis
"Paul Hoffman" <paul.hoffman@vpnc.org> Mon, 12 March 2018 15:09 UTC
Return-Path: <paul.hoffman@vpnc.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 E3CF41205F0 for <dnsop@ietfa.amsl.com>; Mon, 12 Mar 2018 08:09:32 -0700 (PDT)
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] 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 cPRR-rTVRCDv for <dnsop@ietfa.amsl.com>; Mon, 12 Mar 2018 08:09:30 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 B07CE1201FA for <dnsop@ietf.org>; Mon, 12 Mar 2018 08:09:30 -0700 (PDT)
Received: from [10.32.60.132] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w2CF8w0J041361 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dnsop@ietf.org>; Mon, 12 Mar 2018 08:08:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.132]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: dnsop <dnsop@ietf.org>
Date: Mon, 12 Mar 2018 08:09:27 -0700
X-Mailer: MailMate (1.10r5443)
Message-ID: <5495D079-93C8-4A61-9329-DBB3AD3D2B67@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3bNkhiKmkudJP6rRSYK0C1jQ7kU>
Subject: [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 15:09:33 -0000
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. --Paul Hoffman
- [DNSOP] Please review the definitions around "rec… Paul Hoffman
- Re: [DNSOP] Please review the definitions around … Joe Abley
- Re: [DNSOP] Please review the definitions around … P Vix
- Re: [DNSOP] Please review the definitions around … Paul Hoffman
- Re: [DNSOP] Please review the definitions around … Evan Hunt
- Re: [DNSOP] Please review the definitions around … Paul Vixie