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

Tony Finch <dot@dotat.at> Tue, 09 December 2014 11:28 UTC

Return-Path: <fanf2@hermes.cam.ac.uk>
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 CDDD11A1BCF for <dnsop@ietfa.amsl.com>; Tue, 9 Dec 2014 03:28:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 0YQONNQ_zGb3 for <dnsop@ietfa.amsl.com>; Tue, 9 Dec 2014 03:28:47 -0800 (PST)
Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) (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 1EB8A1A1BC4 for <dnsop@ietf.org>; Tue, 9 Dec 2014 03:28:46 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53979) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1XyIyC-00007n-Yz (Exim 4.82_3-c0e5623) (return-path <fanf2@hermes.cam.ac.uk>); Tue, 09 Dec 2014 11:28:44 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1XyIyC-0000PO-Pp (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Tue, 09 Dec 2014 11:28:44 +0000
Date: Tue, 09 Dec 2014 11:28:44 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <BD6A54D2-B3AF-40C9-8890-B5AF347E9516@vpnc.org>
Message-ID: <alpine.LSU.2.00.1412091027460.28934@hermes-1.csi.cam.ac.uk>
References: <20141128152445.12986.10641.idtracker@ietfa.amsl.com> <BD6A54D2-B3AF-40C9-8890-B5AF347E9516@vpnc.org>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/mhY5UOovmr2gvBGL0BjY9FT8hAA
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Fwd: 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: Tue, 09 Dec 2014 11:28:50 -0000

Re "recursive queries", an interesting thing came up yesterday...

http://www.unbound.net/downloads/CVE-2014-8602.txt

> Resolvers fetch the content for domain names by sending queries to
> authority servers on the internet.  One of the responses that authority
> servers can return is a referral response, which points to further
> servers to continue the lookup.  To continue the lookup, resolvers
> may have to perform recursion, where new names, called glue, from the
> referral response have to be looked up to continue the query resolution.

This is not the usual DNS meaning of recursion. Referrals occur during
*iterative* resolution. (Also, tangential to the point of this message,
delegation NS records are not glue - if there is glue in the response,
it isn't necessary to find the addresses of the NS targets!)

I have spent a little time trying to see what these sub-queries are called
in other contexts.

RFC 1034 section 5.3.3 says:

> The top level algorithm has four steps:
>
>    1. See if the answer is in local information, and if so return
>       it to the client.
>
>    2. Find the best servers to ask.
>
>    3. Send them queries until one returns a response.
>
>    4. Analyze the response, [...]

The question is, what do you call the queries made in step 2?

BIND has various functions with "find" in the name which deal with finding
name server addresses. I don't think it has a more special name for this
part of the iterative process.

I can see why Unbound calls them "recursive" queries, from the structure
of the process, but it is a really unhelpful choice of word given its
other very different meaning in the context of the DNS.

There are a few places in the RFCs where these are referred to as
"parallel" queries, e.g. later in RFC 1034 section 5.3.3,

> The resolver has many choices here; the best is to start parallel
> resolver processes looking for the addresses while continuing onward
> with the addresses which are available.

and RFC 1035 section 7.1 (noted by Peter van Dijk),

>     Note that if the resolver structure allows one request to
>     start others in parallel, such as when the need to access a
>     name server for one request causes a parallel resolve for the
>     name server's addresses, the spawned request should be started
>     with a lower counter.  This prevents circular references in
>     the database from starting a chain reaction of resolver
>     activity.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Rockall, Malin, Hebrides, Bailey, Fair Isle: South veering west or southwest,
gale 8 to storm 10, occasionally violent storm 11 in Rockall and Bailey later.
Very rough or high, becoming very high or phenomenal. Rain, then squally
wintry showers. Moderate or poor, occasionally good.