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

From: Tony Finch <[email-masked]>
Date: Tue, 9 Dec 2014 11:28:44 +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  <[email-masked]>  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.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 9 Dec 2014 17:10:56 +0000

> it isn't necessary to find the addresses of the NS targets!)

I've seen "glue" used generically to describe any record returned in
a response from an authoritative server for which that server is not
itself authoritative; that *would* include delegation NS RRsets, as
well as associated address records.  I've also seen it used to describe
any record in a parent zone that describes a child, even if the parent
*is* authoritative, as with "DS glue".

Not saying either of those definitions is correct; just that they're
not obviously wrong.  It would be a good idea to nail it down.

> part of the iterative process.

I call this "delegation following" (or sometimes "delegation chasing"),
but I don't recall where I first encountered the term, and there may
be a better one out there.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 21 Dec 2014 11:29:35 +0100

On Fri, Nov 28, 2014 at 07:28:15AM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 33 lines which said:

> Greetings. Andrew and Kazunori and I have prepared the first draft
> of what will hopefully be a useful document collecting definitions
> that useful in the DNS community. 

Good, let's bikeshed a lot :-)

Missing items:

It does not seem there is a discussion of the difference between
"domain name" and "host name". This is one of the least understood
terminology issues in the DNS, and the basis for many
misunderstandings (for instance, in the IDN discussions, people
claiming that the DNS is 7-bits...) Speaking of that, there is not
even a definition of "domain name" in the draft. Is it because you
regard the definitions of sections 3.1 (domain name) and section 3.5
(host name) of RFC 1034 as sufficient? In that case, may be they
should be quoted, so the future Terminology RFC would be complete.

Also, I do not see a definition of ENT (Empty Non-Terminal), something
which comes often in DNS discussions. 

> 2.  DNS Message Format
> Some common ones [response codes] are:

I agree that NODATA (as a shorthand for NOERROR/ANSWER=0) should be
mentioned (see Andreas Gustafsson's message on Dec. 1st).

> RRset -- A set of resource records with the same label, class and
> type,

"same label" is not clear (yes, it is in RFC 2181, I know, but RFC
2181 use "label" in a new and undefined way, different from RFC 1034)
since many nodes in the domain name tree have the same label... Better
to say "same owner name". Or "same FQDN".

> DNS forwarder -- A system receives a DNS query, possibly changes the
>   query, sends the resulting query to a recursive resolver,

That's not the definition of RFC 2308 ("The forwarder typically either
has better access to the internet, or maintains a bigger cache which
may be shared amongst many resolvers."). If you have Alice's machine
using a SOHO router (whose IP address is announced via DHCP as the DNS
resolver to use) which forwards every DNS query to Google Public DNS,
8.8.8.8 is the forwarder, not the SOHO router (which is a relay). This
is consistent with BIND's "forwarder" directive, which list the
recursive resolvers used to resolve the query.

> Authoritative data -- RRsets in a DNS response that has the AA bit in
> the response header set to 1.

Even the additional section? If I query:

% dig +nodnssec @b.gtld-servers.net NS com               

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +nodnssec @b.gtld-servers.net NS com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58418
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 16
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;com.			IN NS

;; ANSWER SECTION:
com.			172800 IN NS m.gtld-servers.net.
com.			172800 IN NS i.gtld-servers.net.
com.			172800 IN NS f.gtld-servers.net.
com.			172800 IN NS c.gtld-servers.net.
com.			172800 IN NS h.gtld-servers.net.
com.			172800 IN NS d.gtld-servers.net.
com.			172800 IN NS j.gtld-servers.net.
com.			172800 IN NS k.gtld-servers.net.
com.			172800 IN NS g.gtld-servers.net.
com.			172800 IN NS l.gtld-servers.net.
com.			172800 IN NS e.gtld-servers.net.
com.			172800 IN NS b.gtld-servers.net.
com.			172800 IN NS a.gtld-servers.net.

;; ADDITIONAL SECTION:
m.gtld-servers.net.	172800 IN A 192.55.83.30
i.gtld-servers.net.	172800 IN A 192.43.172.30
f.gtld-servers.net.	172800 IN A 192.35.51.30
c.gtld-servers.net.	172800 IN A 192.26.92.30
h.gtld-servers.net.	172800 IN A 192.54.112.30
d.gtld-servers.net.	172800 IN A 192.31.80.30
j.gtld-servers.net.	172800 IN A 192.48.79.30
k.gtld-servers.net.	172800 IN A 192.52.178.30
g.gtld-servers.net.	172800 IN A 192.42.93.30
l.gtld-servers.net.	172800 IN A 192.41.162.30
e.gtld-servers.net.	172800 IN A 192.12.94.30
b.gtld-servers.net.	172800 IN A 192.33.14.30
b.gtld-servers.net.	172800 IN AAAA 2001:503:231d::2:30
a.gtld-servers.net.	172800 IN A 192.5.6.30
a.gtld-servers.net.	172800 IN AAAA 2001:503:a83e::2:30

;; Query time: 47 msec
;; SERVER: 2001:503:231d::2:30#53(2001:503:231d::2:30)
;; WHEN: Sun Dec 21 11:26:44 2014
;; MSG SIZE  rcvd: 520

Are the IP addresses in the additional section "authoritative data"?
This server is not authoritative for gtld-servers.net...

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 21 Dec 2014 11:46:38 +0100

Now at last I have had time to read this...sorry for the late response.

Let me suggest first of all a change in the structure of the document.

For example, in section 2 where you talk about "message format", just talk about the message format. Query, Answer, Additional information etc. How these play in queries and responses. How EDNS0 fit into this. What header flags are and what they mean.

Then you go into resource record sets.

And then resource records.

That is for the DNS server side and you can move to the client side.

And if you define a term like "owner", then you should use it yourself and not say "label" as you do in definition of resource record type (or vice versa) :-)

   Patrik

> On 28 nov 2014, at 16:28, Paul Hoffman <[email-masked]> wrote:
> 
> Greetings. Andrew and Kazunori and I have prepared the first draft of what will hopefully be a useful document collecting definitions that useful in the DNS community. We fully admit that this is quite rough, and didn't even try to do definitions for some of the terms that we expect to be filled in before we are done.
> 
> The idea is that this will be an IETF consensus document, if possible, but we are not yet asking for adoption in the DNSOP WG, and we might not even later. For now, we'd like to hear what additional terms should be added, what clarifications to the terms we already have would be helpful, and so on.
> 
> --Paul Hoffman
> 
>> A new version of I-D, draft-hoffman-dns-terminology-00.txt
>> has been successfully submitted by Paul Hoffman and posted to the
>> IETF repository.
>> 
>> Name:		draft-hoffman-dns-terminology
>> Revision:	00
>> Title:		DNS Terminology
>> Document date:	2014-11-28
>> Group:		Individual Submission
>> Pages:		9
>> URL:            http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/
>> Htmlized:       http://tools.ietf.org/html/draft-hoffman-dns-terminology-00
>> 
>> 
>> Abstract:
>>  The DNS is defined in literally dozens of different RFCs.  The
>>  terminology used in by implementers and developers of DNS protocols,
>>  and by operators of DNS systems, has sometimes changed in the decades
>>  since the DNS was first defined.  This document gives current
>>  definitions for many of the terms used in the DNS in a single
>>  document.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Mon, 22 Dec 2014 10:12:39 +1100

> > the response header set to 1.

The more describes a authoritative answer (AA) which contains
authoritative data as first RRset in the answer section that matches
the query name along with associated DNSSEC proofs.  It also covers
the SOA and NS records in the non-existence cases along with
associated DNSSEC proofs.  This is covered in RFC 103[45].

Authoritative data is the data in the zone for the namespace that
hasn't been delegated way or occulted by DNAME records.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]