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

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Nov 2014 07:28:15 -0800

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.

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 28 Nov 2014 11:03:37 -0500

I wanted to say thanks for following up on this though I seemed to have 
forgotten it in the meeting minutes.

Since I've been editing/shepherding a number of documents through the 
IETF 'release cycle', I've come across this problem several times, and 
I'm glad this is being addressed.

Do we add pointers to RFC4033 ? Or the definitions from RFC7344?

I urge all to look at this and add suggestions to the list.

tim

On 11/28/14 10:28 AM, Paul Hoffman wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "John Levine" <[email-masked]>
Date: 28 Nov 2014 16:38:18 -0000

>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.

This is long overdue, thanks for putting it together.

For the policy implementing resolvers, I'd suggest less loaded terms than
consensual and non-consensual, since we can rathole forever arguing about
to what degree Comcast's customers consent to having their NXDOMAINs replaced
with search pages.  Something like default vs. non-default or opt-in vs. opt-out
would describe it better.

I'd also add NOERROR for a successful response with no records, and note that
some software erroneously confuses it with NXDOMAIN.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Nov 2014 08:38:40 -0800

> Do we add pointers to RFC4033 ? Or the definitions from RFC7344?

Yes and yes. We already did the latter, and heavily presaged the former.

> I urge all to look at this and add suggestions to the list.

Yes, please!

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Fri, 28 Nov 2014 16:52:24 +0000

I've had a quick look. The resolver terminology needs a bit of work.

   Iterative resolver -- A system that receives DNS queries and responds
   with a referral to another server.  RFC 1034 (section 2.3) describes
   this as, "The server refers the client to another server and lets the
   client pursue the query."

In that quote from RFC 1034, the client is the iterative resolver, and the
server is some authoritative server somewhere.

A better definition would be:

   Iterative resolver -- A system that makes RD=0 queries to authoritative
   servers, and follows referrals to get to the final answer. RFC 1034
   (section 2.3) describes iterative resolution as, "The server refers the
   client to another server and lets the client pursue the query."

For recursive resolvers you need to split it into recursive servers, which
accept RD=1 queries and (usually) perform iterative resolution to answer
them; and recursive clients which issue RD=1 queries. Stub resolvers are
recursive clients.

It is a misnomer to refer to a recursive server as a recursive resolver,
unless it forwards to another recursive server.

The RFC 1034 quote "The first server pursues the query for the client at
another server." is a bit confusing since it seems to be describing a
forwarder, where the first server is accepting RD=1 queries and issuing
RD=1 queries. But I think the point it is trying to make is that the first
server is recursively passing the query to the second server.

Re. full resolver, I think this is as opposed to stub resolver. e.g. (from
RFC 1035)

  Sometimes this is done to offload less capable hosts so that they do not
  have to implement a full resolver. [...] In either case, resolvers are
  replaced with stub resolvers which act as front ends to resolvers
  located in a recursive server in one or more name servers known to
  perform that service.

The "resolvers [that] are replaced with stub resolvers" are full
resolvers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southwest Forties, Cromarty: Southeasterly 5 to 7. Moderate or rough.
Occasional rain. Moderate or good, occasionally poor.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Nov 2014 11:53:06 -0800

> would describe it better.

I don't think "default policy-implementing resolver" makes any sense. While "opt-in policy-implementing resolver" does make sense, "opt-out policy-implementing resolver" does not. I'm not as concerned about the rathole as you are, but I certainly don't want to use terms that make no sense.

> some software erroneously confuses it with NXDOMAIN.

Such a note is beyond the scope of the document (but worthy of its own, maybe), but listing NOERROR seems sensible.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Nov 2014 12:02:18 -0800

> I've had a quick look. The resolver terminology needs a bit of work.

Undoubtedly.

>   client to another server and lets the client pursue the query."

Does an iterative resolver only queries authoritative servers, or does it query any type of server?

> server is recursively passing the query to the second server.

Your definitions sound more precise, but I'm not sure that they are generally agreed to in the community. We will flag this for future discussion, with the hope being that there is consensus on something accurate.

> The "resolvers [that] are replaced with stub resolvers" are full

And thus what would your definition of "full resolver" be?

--Paul Hoffman

---

From: John R Levine <[email-masked]>
Date: Fri, 28 Nov 2014 16:22:03 -0500 (EST)

> I don't think "default policy-implementing resolver" makes any sense. 
> While "opt-in policy-implementing resolver" does make sense, "opt-out 
> policy-implementing resolver" does not. I'm not as concerned about the 
> rathole as you are, but I certainly don't want to use terms that make no 
> sense.

I meant default as in it's the one configured by default for a provider's 
users, e.g., by DHCP.

The ISPs I know of that have policy resolvers to rewrite NXDOMAIN 
configure them by default, but provide some way for users to opt out so 
they get the real result instead.  I don't particularly care what the 
wording is so long as it describes what actually happens rather than how 
we think the users ought to feel.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Nov 2014 18:22:01 -0500

The case you describe is "consensual", because you can change it.  A non-consensual case would be the one where all traffic to port 53 at anything other than the operator's resolver is blocked. 

A
-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

On Nov 28, 2014, at 16:22, John R Levine <[email-masked]> wrote:

> I meant default as in it's the one configured by default for a provider's users, e.g., by DHCP.
> 
> The ISPs I know of that have policy resolvers to rewrite NXDOMAIN configure them by default, but provide some way for users to opt out so they get the real result instead.  I don't particularly care what the wording is so long as it describes what actually happens rather than how we think the users ought to feel.
> 
> Regards,

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 Nov 2014 16:19:49 -0800

> Andrew Sullivan <mailto:[email-masked]>
> Friday, November 28, 2014 3:22 PM
> The case you describe is "consensual", because you can change it. A
> non-consensual case would be the one where all traffic to port 53 at
> anything other than the operator's resolver is blocked.

for exactness, we should have terms that distinguish between "use our
resolver or fail" and "our policy routing captures all of your outbound
dns and directs it to our resolver". both are "blocked" but differently so.

-- 
Paul Vixie

---

From: "John R Levine" <[email-masked]>
Date: 28 Nov 2014 20:01:37 -0500

> anything other than the operator's resolver is blocked.

I think we're conflating a bunch of different things here.

Some networks force all port 53 traffic through their own DNS caches. 
That's clearly non-consensual (give or take the option to use a different 
network), but the networks that do that are all over the place in what 
rewriting they do.  A typical thing is to return the address of their 
login server for all queries until you log in, then they may or may not 
rewrite answers.

My ISP (Time-Warner) has a DNS cache that usually rewrites NXDOMAIN to an 
A record for their search page, but each user can go to a settings page 
and say they want the real answers.  That is the default cache their DHCP 
server provides, and is what most of their customers use, but they don't 
otherwise mess with DNS traffic and you can use an external cache like 
8.8.8.8 or run your own cache if you want.  (I have a little BSD box on my 
LAN running unbound and dhcpd, which serves all the hosts behind my NAT 
router.)  That setup is what I call opt-out.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 Nov 2014 12:06:28 +1100

In message <[email-masked]>, Paul Hoffman writes
> Does an iterative resolver only queries authoritative servers, or does it que

A iterative resolver make RD=0 queries.
A resursive resolver make RD=1 queries.

Some resolvers do both depending upon how they are configured.  The
resolver built into named is a example of this.  By default it is
iterative only.

Note named running as a authoritative only server still uses its
built in resolver to lookup information required to perform its
authoritative only role.  This is a example of where a resolver
doesn't receive a external query to trigger a lookup.

> Your definitions sound more precise, but I'm not sure that they are generally
> agreed to in the community. We will flag this for future discussion, with
> the hope being that there is consensus on something accurate.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 29 Nov 2014 20:45:13 -0500

> 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.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 29 Nov 2014 20:47:43 -0500

> I think we're conflating a bunch of different things here.

Well, one of us is ;-)

> Some networks force all port 53 traffic through their own DNS caches. That's
> clearly non-consensual (give or take the option to use a different network),
> but the networks that do that are all over the place in what rewriting they
> do.

Yes.  If they don't do any rewriting, then they're not doing policy.
If they do a little bit (maybe at the beginning, like a captive
portal), then they're _still_ implementing policy and non-consensual,
but they might shift mode after.

> My ISP (Time-Warner) has a DNS cache that usually rewrites NXDOMAIN to an A
> record for their search page, but each user can go to a settings page and
> say they want the real answers. 

In that case, the user shifts modes.  And if you use the
policy-implementing resolver, then it's consensual: you selected it.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sun, 30 Nov 2014 18:10:27 +1100

> no way to know in advance what sort of server you're querying.

But the answer tells you if you talked to a recursive server (RA=1)
or not.

---

From: Tony Finch <[email-masked]>
Date: Sun, 30 Nov 2014 14:02:40 +0000

> 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  <[email-masked]>  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.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 30 Nov 2014 12:34:06 -0500

I really like this approach.  Thanks!

> On Nov 30, 2014, at 9:02, Tony Finch <[email-masked]> wrote:
>

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 1 Dec 2014 00:00:32 +0200

A couple of days ago, John Levine wrote:
> I'd also add NOERROR for a successful response with no records, and
> note that some software erroneously confuses it with NXDOMAIN.

That's not what NOERROR means.  NOERROR simply means RCODE=0 and says
nothing about whether there are records in the response or not.

The situation of RCODE=0 and no records in the answer section is
sometimes referred to as NOERROR/NODATA (e.g., RFC6840 section 4.3) or
simply NODATA (RFC2308 section 2.2).
-- 
Andreas Gustafsson, [email-masked]