Subject: Re: [DNSOP] New version of the DNS terminology draft

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Feb 2015 17:09:13 +0100

On Mon, Jan 19, 2015 at 02:16:47PM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 17 lines which said:

> Greetings again. Andrew, Kazunori, and I have done a massive
> revision on the DNS terminology draft based on the input we got on
> the -00. We're sure we have further to go, but we wanted people to
> look over the new version and give feedback.

I find the definition of Forwarder still confused. I suggest to
rewrite it as:

   DNS forwarder -- When a first resolver receives a DNS query (and
   cannot directly answers it), then sends the
   query to a second recursive resolver, instead of directly to the
   authoritative name servers, this second resolver is called a
   forwarder. Section 1
   of RFC 2308 describes a forwarder as "a nameserver used to resolve queries
   instead of directly using the authoritative nameserver chain".  RFC
   further says "The forwarder typically either has better access to
   the internet, or maintains a bigger cache which may be shared amongst
   many resolvers."

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 4 Feb 2015 11:29:53 -0500

> On Feb 4, 2015, at 11:09 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 
>   many resolvers.”

I do not think this helps. 
Forwarding is not always a capacity/access issue but policy decision to improve
site resolution cache hit ratio among a farm of resolvers.
Forwarding resolver by policy does not do recursion but requests upstream to perform recursion. 

Olafur

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Feb 2015 17:06:52 +0000

> upstream to perform recursion.

Aargh no.

A forwarding resolver makes RD=1 queries to an upstream resolver. This is
a recursive query. The upstream resolver replies with RA=1 which means it
supports recursive clients (and so in common parlance it is a recursive
server). The upstream resolver performs iterative resolution.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Northwest veering north 5 to 7, occasionally gale 8 at first. Rough
or very rough. Showers. Mainly good.

---

From: "Jeremy C. Reed" <[email-masked]>
Date: Wed, 4 Feb 2015 13:09:27 -0600 (CST)

A few years ago at ISC, we spent some hours discussing that the generic 
term "forwarders" really had multiple different meanings:

https://www.isc.org/blogs/dns-forwarders/

(To give credit, I think most of that is from Jelte and Shane.)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Feb 2015 10:53:15 -0800

On Jan 20, 2015, at 7:56 AM, Declan Ma <[email-masked]> wrote:
> As for 'DNS Servers', I think we should set aside space for 'Cache-only DNS Server' which is pervasive in all kinds of DNS document. 

Can you clarify what you think a "cache-only DNS server" is? I'm not seeing how a server can be cache-only without it also doing recursive queries.

> And as in 'Zones', you mentioned 'Origin'. So, I suggest adding a paragraph to describe 'Default TTL', which is represented as $TTL in zone file.

We can add that.

> Still, 'Stub Zone' is yet another common expression in DNS context. We may put it into this document. 

I don't find "stub zone" mentioned in any RFC, so I can't really imagine what that is. Please clarify.

--Paul Hoffman

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Wed, 25 Feb 2015 22:54:02 +0000

I understand "cache-only" or "caching-only" DNS server as being, strictly speaking, one which loads *no* authoritative data. Typically, this is a resolver which populates its cache by initially priming with some "root hints" configuration, and then walking down the namespace hierarchy via iterative queries for everything else, but I suppose, arguably, a forwarder could also qualify as a "cache-only" or "caching-only" DNS server too. Sometimes I've heard the term -- despite being absolute -- being bent to include nameservers which only load a *minimal*, "convenience" set of authoritative zones, e.g. for "localhost", "1.0.0.127.in-addr.arpa", zones of that nature, each of which are usually intended to provide resolution for a single, non-globally-unique name. 

A "stub zone" is one in which the source of zone information -- typically in the form of IP addresses from which to fetch the data -- is defined statically within the nameserver configuration, but *not* involving full replication of the zone *or* recursive resolution towards that source, hence distinguishing it from being a slave for the zone, or engaging in any form of "forwarding", respectively. Because there is no full replication, whatever contents of the zone exist on the instance configured as a "stub" for it, are not considered "authoritative" and the instance does not respond authoritatively for the zone.

											- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Tuesday, February 24, 2015 1:53 PM
To: Declan Ma
Cc: IETF DNSOP WG
Subject: Re: [DNSOP] New version of the DNS terminology draft

We can add that.

--Paul Hoffman
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop