Subject: [DNSOP] Bi-weekly reminder of the documents for the WG

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Oct 2014 12:04:50 -0700

Greetings again. This is a reminder that the documents that this WG is working on, and may or may not be working on in the future, is at
 https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html
It helps the WG chairs to know which documents have enough people willing to review them to move them forwards. If you would like to volunteer to be a reviewer for any of the documents, please let me know so I can list you.

In the past two weeks, a few additional people have volunteered to review some of the documents. It would be grand if more people would offer to review other documents as well. Also, the documents that are going to be part of the new DPRIVE WG were removed from the list.

If you want to add a document to the list, contact the WG chairs.

--Paul Hoffman, secretary

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 30 Oct 2014 11:02:35 +0100

On Wed, Oct 29, 2014 at 12:04:50PM -0700,
 Paul Hoffman <[email-masked]> wrote 

>  https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html

draft-bortzmeyer-dns-qname-minimisation is now
draft-ietf-dnsop-qname-minimisation.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 30 Oct 2014 15:29:21 -0400

Line #  https://tools.ietf.org/id/draft-ietf-dnsop-qname-minimisation-00.txt
     1	##Network Working Group                                      S. Bortzmeyer

Should be DNSOP WG

     7	##             DNS query name minimisation to improve privacy

I suggest shortening the name to "DNS Query Name Minimi[s|z]ation" but I have
a feeling that there is a more appropriate word to use. Because, as described
this proposal would increase the number of queries sent in search of a name.

Perhaps "DNS Query Localization".  A query is issued mindful of its data space
location.

    12	##   This document describes one of the techniques that could be used to
    13	##   improve DNS privacy (see [I-D.bortzmeyer-dnsop-dns-privacy]), a
    14	##   technique called "qname minimisation".

This isn't a topic to discuss here, but my concern with privacy is that acheiving
that goal tends to make network management and operations that much harder.  I
mention this misgiving in the sense that perhaps there is no need to make this
proposal only about privacy.

What is proposed is that an interating client asks only what it thinks the server
will know.  I don't know if that is a benefit to any client other than those
trying to hide their tracks.

    89	##   It follows the principle explained in section 6.1 of [RFC6973]: the
    90	##   less data you send out, the less privacy problems you'll get.

I don't know that the amount of "privacy problems" is something DNSOP is suited
to address.  One of my concerns of using privacy to set up the use case.

    92	##2.  Qname minimisation

   113	##   To do such minimisation, the resolver needs to know the zone cut
   114	##   [RFC2181].  There is not a zone cut at every label boundary.  If we
   115	##   take the name www.foo.bar.example, it is possible that there is a
   116	##   zone cut between "foo" and "bar" but not between "bar" and "example".
   117	##   So, assuming the resolver already knows the name servers of .example,
   118	##   when it receives the query "What is the AAAA record of
   119	##   www.foo.bar.example", it does not always know if the request should
   120	##   be sent to the name servers of bar.example or to those of example.
   121	##   [RFC2181] suggests a method to find the zone cut (section 6), so
   122	##   resolvers may try it.

This sounds like something related to work attempted in the DBound mail list,
work which hasn't crystalized into anything (yet).  If a client could know a
priori where the zone, err, server cuts were in the "path" of a domain name,
localizing the query and minimizing the number of queries could be plausible.

   128	##   It can be noted that minimising the amount of data sent also
   129	##   partially addresses the case of a wire sniffer, not just the case of
   130	##   privacy invasion by the servers.

Before using arguments like this, terms such as "privacy invasion" need to be defined.

   132	##   One should note that the behaviour suggested here (minimising the
   133	##   amount of data sent in qnames) is NOT forbidden by the [RFC1034]
   134	##   (section 5.3.3) or [RFC1035] (section 7.2).  Sending the full qname
   135	##   to the authoritative name server is a tradition, not a protocol
   136	##   requirment.

I tend to disagree with that.  While "requirement" is a strong word, in the days
before the global public DNS settled on a top-level domain/second-level domain
data model and in some places still today, the need for the full qname was to 
be as opportunistic as possible.  And I don't mean "opporunistic security", I
mean to be as efficient in finding an answer.

In particular, during the days when COM and NET would perform a "hybrid" response
to a query for an address of a server that was in the glue - the hybird being
a partially cache answer (no AA bit) and partially a referral (authority
section indicated the more authoritative location), the full qname was needed.
This hybrid wasn't a registry just being "nice" it was related to old code not
being able to handle some referral chains (specifically into the in-addr.arpa
subtree).  Not only is the buggy code (largely gone), signing COM and NET forced
the end of the hybrid responses.

Effectively, yes, not a requirement, but more than a tradition.

   138	##3.  Operational considerations
   139	##
   143	##   qtypes).  On the other hand, it will decrease their legal
   144	##   responsability, in many cases.

How any statement be made about "legal responsibility" if it is never defined?

   149	##   queries but send REFUSED to queries "NS www.ratp.fr".  This behaviour
   150	##   is a gross protocol violation and there is no need to stop improving

This ignores that local policy trumps all others in the DNS.  The recipient of a
query has no duty to respond to it.  There's an expectation on the sender side
and if the recipient decides to follow the protocol they will respond.  But
following a tradition of "there's no protocol police" we can't say there is
a violation, much less a "gross" one.

I will say that once I was enraged by servers that did not respond to every query.
It was explained to me that some implementers feel out of target responses are
threats.  Eventually I became convinced that it was thier perogative to answer
as they see fit and adjusted my operational probes accordingly (looking for lame
servers).  And then RRL came about ... ;)  A server has the right to withhold
answers - and a duty when you consider that we live with a network where people
shout for BCP 38 deployment.

   153	##   need to send them NS requests).  Anyway, such setup breaks many
   154	##   things (besides qname minimisation), it breaks negative answers as
   155	##   the servers don't return the correct SOA.  It also breaks anything
   156	##   that depends on NS and SOA records existing at the top of the zone.

The SOA is "just a convention" too (in negative answers) and if the zone does
not make use of NOTIFY/AXFR/IXFR, the SOA serial number doesn't matter either.

   172	##   Other strange and illegal practice may pose a problem: for instance,

At this point the current proposal seems more and more like a bad idea.

(Once again - illegal practice?)

This is getting into hacking at one part of the architecture to spite another
hack at the architecture.

   210	##4.  Other advantages
   211	##
   228	##   priori that neither B.CORP or C.CORP could exist.  Thus in this
   229	##   common case the total number of upstream queries under query
   230	##   minimisation would be counter-intuitively less than the number of
   231	##   queries under the traditional iteration (as described in the DNS
   232	##   standard).

With DNSSEC, we'd get that anyway. Let's face it, worrying about queries just
doesn't matter.  We know that in practice.

   239	##6.  Acknowledgments
   240	##
   241	##   Thanks to Olaf Kolkman for the original idea.

No need to throw him under the bus first.

   292	##Appendix A.  An algorithm to find the zone cut

It's not the zone cut that matters, it's what zones the server answers that matters.

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Thu, 30 Oct 2014 19:42:02 +0000

Some form of "optimization", perhaps?

I too have been tempted to comment on the fact that there is no QNAME that is being "minimized" here (which would imply making it shorter; not the gist of the proposal at all).

If we're stuck on the term "minimization", make it clear that it's not the QNAME itself that's being "minimized", but the actual number of query transactions being minimized. Although "query-transaction volume minimization" is a bit of a mouthful...

                                                                                                                                                                - Kevin

From: DNSOP [mailto:[email-masked]] On Behalf Of Edward Lewis
Sent: Thursday, October 30, 2014 3:29 PM
To: dnsop
Cc: [email-masked]
Subject: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt

Should be DNSOP WG

   115   ##   take the name www.foo.bar.example<http://www.foo.bar.example>, it is possible that there is a
   119   ##   www.foo.bar.example<http://www.foo.bar.example>", it does not always know if the request should

   149   ##   queries but send REFUSED to queries "NS www.ratp.fr<http://www.ratp.fr>".  This behaviour
   150   ##   is a gross protocol violation and there is no need to stop improving

   239   ##6.  Acknowledgments
   240   ##

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Oct 2014 13:35:28 -0700

the term "query minimization" appeals to me since each server, during
iteration, sees the minimum substring of the qname needed.

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Thu, 30 Oct 2014 20:46:37 +0000

Isn't "doing the minimum necessary to get the job done" pretty much the definition of "optimization" (or, for that matter, "efficiency")? "Minimize" means, basically, only "to make small"; whereas "optimization" or "efficiency" means to reduce something, relative to something else, for a particular purpose or to achieve a particular end.

_De_gustabis_. I don't have any strong preferences one way or the other, I just think shortening QNAMEs is an odd way to _introduce_ what the proposal purports to do. Once one comprehends the gist of the proposal, then it makes sense, but for historical reference and information retrieval, one wants to choose a title that most intuitively yet concisely describes what is/was proposed.

												- Kevin

-----Original Message-----
From: Paul Vixie [mailto:[email-masked]] 
Sent: Thursday, October 30, 2014 4:35 PM
To: Darcy Kevin (FCA)
Cc: dnsop
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt

the term "query minimization" appeals to me since each server, during iteration, sees the minimum substring of the qname needed.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 30 Oct 2014 17:02:21 -0400

> iteration, sees the minimum substring of the qname needed.

Ed's point is not wrong, however -- in one fairly natural meaning, the
technique is actually "query maximization".  If one called it "query
disclosure minimization" or something like that it'd be closer to
describing what happens.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 31 Oct 2014 12:08:04 +0100

On Thu, Oct 30, 2014 at 03:29:21PM -0400,
 Edward Lewis <[email-masked]> wrote 

> Should be DNSOP WG

Boilerplate from XML2RFC. I have to read the documentation.

> Because, as described this proposal would increase the number of
> queries sent in search of a name.

It's minimisation of the data sent. And, in most cases, there would be
no increase of the query numbers.

> I don't know that the amount of "privacy problems" is something
> DNSOP is suited to address.

There have been a lot of hesitation after Vancouver on where to put
this work (DNSOP, Perpass, a new WG). In the end, it is DNSOP (there
have been a call for adoption by dnsop, with only one opposition
expressed) so, in my opinion, the case is closed (I'm not really
interested in IETF's internal endless process debates).

> This sounds like something related to work attempted in the DBound

Not at all. Dbound (or Mozilla's public suffix list) rely on a priori
knowledge (which can be stale) while Qname m12n relies on dynamically
learning. But, more important, Dbound is for finding out the
_administrative_ boundaries while Qname m12n depend on _technical_
boundaries. For Dbound, the fact that www.ratp.fr is below a zone cut
and not in the same zone than ratp.fr is irrelevant (it's the same
organisation). For Qname m12n, it is crucial.

Doug Barton suggested here to use Dbound-like techniques to optimize
the work of a qname-minimising resolver. I personally don't think this
small improvment would be worth the added complication and risks of
staleness.

> Effectively, yes, not a requirement, but more than a tradition.

May be it's my low level in english but, for me, "tradition" did not
mean that it was irrational or without basis. You say that there were
very good practical reasons for sending the full Qname and I agree. If
we continue to do so while these reasons are no longer there (root
name servers don't serve .com anymore...), it is tradition.

> The SOA is "just a convention" too (in negative answers) and if the
> zone does not make use of NOTIFY/AXFR/IXFR, the SOA serial number
> doesn't matter either.

You say that not sending a SOA (when requested) is legal? 

> (Once again - illegal practice?)

Do you prefer a term less legalese? "Violation of the RFC"?

> It's not the zone cut that matters, it's what zones the server

I disagree. When you want to resolve www.example.com with Qname m12n,
knowing that example.com and com are on different sides of a zone cut
is necessary. Knowing that the .com name servers also serve .net is
useless.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 31 Oct 2014 12:13:09 +0100

On Thu, Oct 30, 2014 at 07:42:02PM +0000,
 Darcy Kevin (FCA) <[email-masked]> wrote 
 a message of 1087 lines which said:

> I too have been tempted to comment on the fact that there is no
> QNAME that is being "minimized" here (which would imply making it
> shorter; not the gist of the proposal at all).

I really do not understand you. With Qname minimisation, the Qname
*will* be shorter.

> If we're stuck on the term "minimization", make it clear that it's
> not the QNAME itself that's being "minimized",

-1

> but the actual number of query transactions being minimized.

-1

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 31 Oct 2014 12:13:46 +0100

On Thu, Oct 30, 2014 at 01:35:28PM -0700,
 Paul Vixie <[email-masked]> wrote 
 a message of 7 lines which said:

> the term "query minimization" appeals to me since each server,
> during iteration, sees the minimum substring of the qname needed.

That's why it is "qname minimisation", not "query minimisation" :-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 31 Oct 2014 12:20:03 +0100

On Thu, Oct 30, 2014 at 08:46:37PM +0000,
 Darcy Kevin (FCA) <[email-masked]> wrote 
 a message of 19 lines which said:

> Isn't "doing the minimum necessary to get the job done" pretty much
> the definition of "optimization" (or, for that matter,
> "efficiency")? "Minimize" means, basically, only "to make small";
> whereas "optimization" or "efficiency" means to reduce something,
> relative to something else, for a particular purpose or to achieve a
> particular end.

"Minimisation" did not came out of the blue. It is a very common term
in privacy work and it is used in RFC 6973 (normative reference for
draft-ietf-dnsop-qname-minimisation-00), section 6.1. Let's not
reinvent terminology.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 31 Oct 2014 12:22:51 +0100

On Thu, Oct 30, 2014 at 05:02:21PM -0400,
 Andrew Sullivan <[email-masked]> wrote 

> disclosure minimization" or something like that it'd be closer to

As I said to Paul Vixie, the Internet-Draft says "qname minimisation",
not "query minimisation".

(There is one - just one - unfortunate occurrence of "query
minimisation" in section 4, which will disappear in the next version.)

---

From: Edward Lewis <[email-masked]>
Date: Fri, 31 Oct 2014 10:58:29 -0400

To clear up a few points.

> small improvment would be worth the added complication and risks of

I had in mind what Doug suggested.

> You say that not sending a SOA (when requested) is legal? 

A server may, at any time, return REFUSED.  If you want to argue based on the RFCs:

See RFC 1035, section 4.1.1. (Header section format), under RCODE, value 5

As far as not returning at all, that isn’t considered an option by the RFCs and protocol designers but is justified in my eyes under the reality of operations.

> is necessary. Knowing that the .com name servers also serve .net is

In this case the point was not made well.  What I mean is for a name like this:

www.localschool.K-12.city.county.province.ccTLD. : one name server might serve these zones:

localschool.K-12.city.county.province.ccTLD.
K-12.city.county.province.ccTLD.
county.province.ccTLD.

It’s not the zones that matter, but the set of zones on the server because if you ask this server the full name you will get to the result much faster than targeting the NS records of the zones.

The DNS does not convey the zones on a server - it does report the servers a zone is to be found on (although we know that it might be inaccurate).

---

From: Edward Lewis <[email-masked]>
Date: Fri, 31 Oct 2014 11:23:57 -0400

> draft-ietf-dnsop-qname-minimisation-00), section 6.1. Let's not

But it’s not a common term in DNS.  A few people have independently commented on it.

Perhaps you should set aside some text to define it and say that it comes from that RFC and the work behind it.