Subject: Re: [DNSOP] DNS privacy : now at least two drafts

From: Florian Weimer <[email-masked]>
Date: Sat, 08 Mar 2014 17:50:55 +0100

* Stephane Bortzmeyer:

> I just posted a new version of the DNS privacy draft,
> draft-bortzmeyer-dnsop-dns-privacy-01. The most important difference
> is that it is now split in two, one pure problem statement,
> draft-bortzmeyer-dnsop-dns-privacy and an exploration of possible
> solutions, draft-bortzmeyer-dnsop-privacy-sol. The first one seems to
> me (and to the AD) well adapted to dnsop. The second one mixes
> solutions that may be in the realm of dnsop (such as qname
> minimization) and solutions that would require a new WG (such as
> encryption of DNS traffic).

The -sol draft mentions QNAME minimization without defining the term.
Is this about sending only as many labels as required to obtain a
delegation from an authoritative server?

There is another privacy-enhancing approach that is not mentioned in
the draft: defensive delegations.  For example, with current resolver
behavior, the lack of a delegation for 1.E164.ARPA means that queries
under that tree are sent to the E164.ARPA servers, which are scattered
around the globe.  With a delegation, the delegation would be cached
and queries could be kept locally in the region.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 8 Mar 2014 16:57:41 +0000

On Sat, Mar 08, 2014 at 05:50:55PM +0100,
 Florian Weimer <[email-masked]> wrote 

> The -sol draft mentions QNAME minimization without defining the

It is. Section 2.2.2

I'll add some more cross-references to make it easier to find it.

---

From: Florian Weimer <[email-masked]>
Date: Sat, 08 Mar 2014 18:07:48 +0100

>> The -sol draft mentions QNAME minimization without defining the

Can you quote it here?  It seems to be missing from the 00 version, or
I'm horribly confused.

> I'll add some more cross-references to make it easier to find it.

Thanks.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 8 Mar 2014 17:34:56 +0000

On Sat, Mar 08, 2014 at 06:07:48PM +0100,
 Florian Weimer <[email-masked]> wrote 
 a message of 17 lines which said:

> Can you quote it here? 

2.2.2.  In the authoritative name servers

   A possible solution would be to minimize the amount of data sent from
   the resolver.  When a resolver receives the query "What is the AAAA
   record for www.example.com?", it sends to the root (assuming a cold
   resolver, whose cache is empty) the very same question.  Sending
   "What are the NS records for .com?"  would be sufficient (since it
   will be the answer from the root anyway).  To do so would be
   compatible with the current DNS system and therefore could be
   deployable, since it is an unilateral change to the resolvers.

   To do so, the resolver needs to know the zone cut [RFC2181].  There
   is not a zone cut at every label boundary.  If we take the name
   www.foo.bar.example, it is possible that there is a zone cut between
   "foo" and "bar" but not between "bar" and "example".  So, assuming
   the resolver already knows the name servers of .example, when it
   receives the query "What is the AAAA record of www.foo.bar.example",
   it does not always know if the request should be sent to the name
   servers of bar.example or to those of example.  [RFC2181] suggests an
   algorithm to find the zone cut, so resolvers may try it.

   Note that DNSSEC-validating resolvers already have access to this
   information, since they have to find the zone cut (the DNSKEY record
   set is just below, the DS record set just above).

   It can be noted that minimizing the amount of data sent also
   partially addresses the case of a wire sniffer.

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

   Another note is that the answer to the NS query, unlike the referral
   sent when the question is a full qname, is in the Answer section, not
   in the Authoritative section.  It has probably no practical
   consequences.

---

From: Florian Weimer <[email-masked]>
Date: Sat, 08 Mar 2014 19:07:43 +0100

> 2.2.2.  In the authoritative name servers

Ahhh, this section heading is wrong, the section is actually
discussing resolver.  The text doesn't explicitly mention
minimization, either. :)

>    deployable, since it is an unilateral change to the resolvers.

There are some odd configurations out there where a query for
www.foo.bar.example/IN/A returns data, but a query for
foo.bar.example/IN/A returns NXDOMAIN.  So it is backwards-compatible
per specification, but a bit thorny to implement in practice.

>    [RFC2181] suggests an

Do you refer to explicit NS queries?

>    set is just below, the DS record set just above).

But they don't obtain this information in a privacy-enhancing way.

>    to the authoritative name server is a tradition, not a protocol
          ^

Typo.

>    in the Authoritative section.  It has probably no practical

Most resolvers do not make NS queries, and some authoritative servers
do not return useful data (or any data at all).  So using NS queries
for zone cut discovery does not work reliably.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Mar 2014 19:00:53 +1100

> per specification, but a bit thorny to implement in practice.

RFC 2535 said there were no names between NXT owner and the next
name leading to a change in behaviour from RFC 103[45] for empty
non terminals in the range (NXDOMAIN rather than NODATA).

RFC 4034 corrected this to say "the next owner name (in the canonical
ordering of the zone) that contains authoritative data or a delegation
point NS RRset" which handles empty non terminal as NODATA and is
consistent with RFC 103[45].

> for zone cut discovery does not work reliably.

Any resolver that is DNSSEC aware will make NS queries (whether
validating or not).  They do not do so very often as the configurations
that require them to be made are rare.  The majority of recursive
servers in the world are DNSSEC aware.

Nameservers that fail to handle NS queries are broken.  More NS
queries would be good for the overall health of the DNS as it would
flush out the broken servers.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Sun, 16 Mar 2014 16:00:08 +0100

> and queries could be kept locally in the region.

And another one: If you make your queries against a local copy of the
DNS tree (which has been made irrespective of future demand), then
nobody else will now which DNS records you are intersted in.

This approach obviously weighs query privacy over database protection
(whether as someone's intellectual property or with regards to domain
owner privacy).

---

From: Florian Weimer <[email-masked]>
Date: Sun, 16 Mar 2014 16:07:20 +0100

* Mark Andrews:

> validating or not).

Really?  Where is this mentioned in the protocol RFCs?

> flush out the broken servers.

Sure, but in practice, no one wants to be the person who exerts this
perssure on zone publishers.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Mar 2014 02:41:43 +1100

> Really?  Where is this mentioned in the protocol RFCs?

RFC 3658
2.2.1.2.  Special processing when child and an ancestor share
          nameserver

---

From: Florian Weimer <[email-masked]>
Date: Mon, 17 Mar 2014 17:19:55 +0100

> 2.2.1.2.  Special processing when child and an ancestor share

I think this section is about DS queries, not NS queries.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Mar 2014 14:58:54 +1100

> I think this section is about DS queries, not NS queries.

You need to discover where to send the DS queries.  That means
discovering the immediate parent zone cut.  The usual and suggested
way is to make NS queries with the left most label stripped.

Mark