Subject: [DNSOP] Adoption and Working Group Last Call for draft-ietf-dnsop-dns-terminology/

From: Tim WIcinski <[email-masked]>
Date: Fri, 17 Apr 2015 06:48:29 -0400

Greetings,

While we've never had a formal call for adoption, this draft has had a 
lot of comments about the contents, but never about the need for this 
document. The need has been clear.

The chairs made the move of adopting the document directly, and we're 
now opening a Working Group Last Call on this document.

The draft can be found here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-terminology/

http://www.ietf.org/id/draft-ietf-dnsop-dns-terminology-00.txt

Please review the draft and offer relevant comments. Remember: This 
draft is not attempting to redefine any definitions, but to collect and 
formalize the definitions which do exist.

Because of the nature of the WGLC, we're making this a three week 
window.  The working group last call will end on Friday May 8th.

thanks
tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Apr 2015 15:43:35 +0200

On Fri, Apr 17, 2015 at 06:48:29AM -0400,
 Tim WIcinski <[email-masked]> wrote 
 a message of 30 lines which said:

> draft is not attempting to redefine any definitions, but to collect
> and formalize the definitions which do exist.
> 

IMHO, the text can NOT be published with its definition of Forwarder.

The definition of Forwarder is still both confused and
self-contradictory. For instance, the current text says that the
forwarder "sends on the resulting query (usually to a recursive
resolver)" and later that "The forwarder typically either has better
access to the internet, or maintains a bigger cache which may be
shared amongst many resolvers" If it has a better access, why does it
send to another recursive resolver? It really seems the current
definition mixes the downstream forwarder and the upstream resolver.

My proposal:

Forwarder -- A DNS resolver that receives a DNS query from another
resolver, sends it (usually to authoritative name servers), and
returns the resulting response to the source of the query.  Section 1
of [RFC2308] describes a forwarder as "a nameserver used to resolve
queries instead of directly using the authoritative nameserver chain".
[RFC2308] further says "The forwarder typically either has better
access to the internet, or maintains a bigger cache which may be
shared amongst many resolvers."

I also suggest to delete the entry "Open forwarder" which has the same
issues.

Other remarks which are not, in my opinion, blocking for the
publication:

> Public suffix

Two small text additions. 1) cite "DNS Administrative Boundaries
Problem Statement" draft-sullivan-dbound-problem-statement 2) "Note
there is zero indication, in the domaine name, that it is a public
suffix or not. It can only be learned from outside means."

> Non-consensual policy-implementing resolver [...] The difference
> between this and a consensual policy- implementing resolver is that
> users of this resolver are not expected to know that there is a
> policy to change the answers it returns.

Dangerous legal and political issues here. If Joe Sysadmin configures
the DHCP server to tell the users' machines to use 192.0.2.53 and this
resolver rewrites answers, can we honestly say that the users "are
expected to know"? Technically, there is no difference between
Consensual policy-implementing resolver and Non-consensual
policy-implementing resolver and I would merge the definitions.

> Passive DNS -- A mechanism to collect large amounts of DNS data by
> storing queries and responses from recursive servers.

Most passive DNS servcies collect only the responses, which is good
for privacy.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Apr 2015 09:57:06 -0700

On Apr 20, 2015, at 6:43 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> self-contradictory.

Yes. There are differences between the explicit definition for DNS forwarder in RFC 2308 and the strongly implied definition in RFC 5625. The WG needs to decide which definition it prefers, and an explanation of why (because both definitions exist). For comparison:

RFC 2308:
   "FORWARDER" - a nameserver used to resolve queries instead of
   directly using the authoritative nameserver chain.  The forwarder
   typically either has better access to the internet, or maintains a
   bigger cache which may be shared amongst many resolvers.  How a
   server is identified as a FORWARDER, or knows it is a FORWARDER is
   outside the scope of this document.  However if you are being used as
   a forwarder the query will have the recursion desired flag set.

RFC 5625:
   These proxies are usually simple DNS forwarders, but typically do not
   have any caching capabilities.  The proxy serves as a convenient
   default DNS resolver for clients on the LAN, but relies on an
   upstream resolver (e.g., at an ISP) to perform recursive DNS lookups.

> For instance, the current text says that the

The definition in the draft includes ideas from RFC 5625, which seems to be the much more common definition of "forwarder" used today. However, the WG is free to define this however they want.

> shared amongst many resolvers."

My proposal goes the other way: to use the more common definition of a forwarder being what we see in gazillions of SOHO devices.

> I also suggest to delete the entry "Open forwarder" which has the same

I agree with deleting "Open forwarded", but for different reasons: the term doesn't appear in any RFC to date, so it isn't needed.

> suffix or not. It can only be learned from outside means."

For #1, Citing a draft could cause delay in publication of this RFC, but we can instead point to the WG and say work is underway now. I like the addition in #2.

> policy-implementing resolver and I would merge the definitions.

Please propose specific wording for the merge so the WG can see if they like it better.

> Most passive DNS servcies collect only the responses, which is good

Some passive DNS services collect the query too. Given the privacy issue you mention, we should make people aware of that.

--Paul Hoffman

---

From: Ray Bellis <[email-masked]>
Date: Tue, 21 Apr 2015 08:11:55 +0000

> On 20 Apr 2015, at 17:57, Paul Hoffman <[email-masked]> wrote:
> 

As the author of the latter text, I feel it may be important to make a distinction between forwarders that actively participate in the protocol (that is, they parse requests and responses, and act as a "hop", c.f. BIND configured to use a forwarder) vs those that simply punt (UDP) packets in both directions without regard to the content.

Ray

---

From: Tony Finch <[email-masked]>
Date: Tue, 21 Apr 2015 10:57:43 +0100

Paul Hoffman <[email-masked]> wrote:
>
> Yes. There are differences between the explicit definition for DNS
> forwarder in RFC 2308 and the strongly implied definition in RFC 5625.

The difference here is that RFC 2308 uses "forwarder" to mean the target
of forwarded queries, whereas RFC 5625 is talking about the process of
forwarding queries. The RFC 2308 usage matches how you configure BIND to
forward queries: you use a "forwarders" clause to configure the target
servers.

The problem with the RFC 2308 usage is that the nominated server is just a
recursive server: the fact that you are forwarding queries to it implies
nothing about its configuration. It might do iterative resolution; it
might forward queries again. If you look at RFC 2308 you will see that
whenever it uses the term, it is talking about other servers that are the
target of queries forwarded by the server under discussion.

I suggest defining "forwarding" and "forwarder" separately.

forwarding: The process of sending a recursive query (RD=1) to another
server (a "forwarder") to resolve a recursive query received by this
server. (As opposed to using iterative resolution.) Forwarding is a
function of a DNS resolver (as opposed to simple relaying done by a DNS
proxy).

forwarder: [RFC 2308 definition]

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight: Northwest 5 to 7, perhaps gale 8 later. Slight or
moderate, becoming moderate or rough. Fog patches for a time. Moderate,
occasionally very poor for a time.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 22 Apr 2015 14:33:54 +0200

On Mon, Apr 20, 2015 at 09:57:06AM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 98 lines which said:

> The definition in the draft includes ideas from RFC 5625, which
> seems to be the much more common definition of "forwarder" used
> today. However, the WG is free to define this however they want.

I disagree with "much more common". The two definitions can be
summarized as:

1) a forwarder is the machine which forwards
2) a forwarder is the machine which receives the forwarded request

I find 2) much more common, because it is the meaning it has in BIND.

> My proposal goes the other way: to use the more common definition of
> a forwarder being what we see in gazillions of SOHO devices.

And then we will have thousands of BIND configs to patch...

Anyway, _today_, in draft-ietf-dnsop-dns-terminology-00, the
definition of "forwarder" is not 1) or 2) but a strange mix of both.

> > Dangerous legal and political issues here. If Joe Sysadmin
> > configures the DHCP server to tell the users' machines to use
> > 192.0.2.53 and this resolver rewrites answers, can we honestly say
> > that the users "are expected to know"? Technically, there is no
> > difference between Consensual policy-implementing resolver and
> > Non-consensual policy-implementing resolver and I would merge the
> > definitions.
> 

Policy-implementing resolver -- A resolver that changes some answers
it returns based on policy criteria, such as to prevent access to
malware sites.  This is just a technical definition: such a
policy-implementing resolver can be installed by various actors, for
various reasons, and users may or may not be aware of its
policy. [Some people prefer to be direct and call it a lying
resolver.]

> >> Passive DNS -- A mechanism to collect large amounts of DNS data
> >> by storing queries and responses from recursive servers.
> > 
> Some passive DNS services collect the query too. Given the privacy
> issue you mention, we should make people aware of that.

Passive DNS -- A mechanism to collect large amounts of DNS data by
storing responses from servers. Some of these systems also collect
queries, which can raise privacy issues.

---

From: Hugo Connery <[email-masked]>
Date: Wed, 22 Apr 2015 15:28:04 +0200

On 04/22/2015 02:33 PM, Stephane Bortzmeyer wrote:

[snip].
> policy. [Some people prefer to be direct and call it a lying
Policy-implementing resolver -- A recursive resolver that modifies
authoritative responses in accordance with locally specified, and generally
organization wide, policy for accessible sites.  Modifications vary
from denial of the existence of the queried DNS record to modifying
the destination specified in the authoritative response.
Policies can range from malware protection, often via dynamically updated
reputation based data, to only allowing narrowly selected sites.
This process is also known as DNS filtering.  A synonym for a
Policy-implementing resolver is a DNS Firewall.
> queries, which can raise privacy issues.
+1

/Hugo Connery

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 22 Apr 2015 16:56:22 -0400

> queries, which can raise privacy issues.

When collecting "below the recursive" passive DNS data, both queries and
responses can raise the same privacy issues, since the response usually
contains a superset of the information in the query.  "Above the
recursive" (or "inter-server" in Florian Weimer's original paper), one
could collect only responses, but unless queries are also collected and
matched to the corresponding responses, the passive DNS system can be
trivially poisoned by blindly spoofed responses.

So, maybe query vs response is not the right distinction to make for
"can raise privacy issues".  Maybe "queries from recursive clients"
would be better than plain "queries"?

-- 
Robert Edmonds