Subject: [dns-privacy] [[email-masked]: I-D Action: draft-bortzmeyer-dns-qname-minimisation-00.txt]

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Mar 2014 11:33:55 +0100

Per popular request, qname minimisation, one of the techniques that
may be used to improve DNS privacy, now has its own Internet-Draft.

Subject: I-D Action: draft-bortzmeyer-dns-qname-minimisation-00.txt
From: [email-masked]
To: [email-masked]
Date: Thu, 20 Mar 2014 03:12:11 -0700
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : DNS query name minimisation to improve privacy
        Author          : Stephane Bortzmeyer
	Filename        : draft-bortzmeyer-dns-qname-minimisation-00.txt
	Pages           : 4
	Date            : 2014-03-20

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

   Discussions of the document should currently take place on the dns-
   privacy mailing list [dns-privacy].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bortzmeyer-dns-qname-minimisation/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bortzmeyer-dns-qname-minimisation-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Mar 2014 11:04:13 +0000

> may be used to improve DNS privacy, now has its own Internet-Draft.

Ace :-)

You say "[RFC2181] suggests an algorithm to find the zone cut" but
although it describes what a zone cut looks like I can't see any clear
description of an algorithm for finding them. There are evidently
subtleties in this algorithm; for example, do you abort early if you get
an NXDOMAIN response, or do you treat that as NOERROR/NODATA? Is there
enough buggy handling of empty non-terminals that you have to do the
latter? And if so what are the privacy implications?

Also,

   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.

This is incorrect. RFC 2181 again:

                  The NS records that indicate a zone cut are the
   property of the child zone created, as are any other records for the
   origin of that child zone, or any sub-domains of it.  A server for a
   zone should not return authoritative answers for queries related to
   names in another zone, which includes the NS, and perhaps A, records
   at a zone cut, unless it also happens to be a server for the other
   zone.

Later on,

                                    However, qname minimisation may
   still work with such domains since they are only leaf domains (no
   need to send them NS requests).

This goes back to subtleties in the algorithm :-)

You will send NS queries for www.ratp.fr to the servers of ratp.fr so you
should never trigger the brokenness in the www.ratp.fr load balancer.

This brings up a question about zone cuts at the leaf like this one:
should your query sequence look like

  fr          IN NS ?
  ratp.fr     IN NS ?
  www.ratp.fr IN NS ?
  www.ratp.fr IN A ?
  www.ratp.fr IN AAAA ?

Or should you skip the third query?

Skipping the third query would improve latency in most cases (when there
isn't a zone cut at the leaf), but it leads to leakage. For example,
consider a domain like google.com: do you want the .com name servers to
know if you are sending mail to Google, rather than just looking at their
web site?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire: Southerly or southwesterly 6 to gale 8,
occasionally severe gale 9 at first in Viking. Rough or very rough. Occasional
rain. Moderate or good, occasionally poor.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Mar 2014 15:20:20 +0100

On Thu, Mar 20, 2014 at 11:04:13AM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 65 lines which said:

> although it describes what a zone cut looks like I can't see any
> clear description of an algorithm for finding them.

The wording in my draft is not perfect. Indeed, DNS RFCs rarely
describe algorithms, probably to let some freedom to the
implementations.

>    in the Authoritative section.

Also a poor wording since it is the Authority section, not the
Authoritative one. (Which, by the way, answers your concern.)

> This goes back to subtleties in the algorithm :-)

Following the general principle of DNS RFCs, I do not think it would
be wise to specify an algorithm for resolution with qname
minimisation, since there is none for traditional resolution.

>   www.ratp.fr IN AAAA ?

You did not mention the zone which will receive the queries. The third
query will work, even with the broken Alteon load balancers, since it
will be sent to the NS of ratp.fr.

> Or should you skip the third query?

It MAY (RFC 2119) be skipped since a zone cut is not possible because
there is just one label more than the previous name.

> Skipping the third query would improve latency in most cases (when
> there isn't a zone cut at the leaf), but it leads to leakage. For
> example, consider a domain like google.com: do you want the .com
> name servers to know if you are sending mail to Google, rather than
> just looking at their web site?

I do not understand. Do you refer to gmail.com/google.com? If so,
indeed, a resolver has no way of knowing that the two domains are
related and so leakage will occur. If you refer to
mail.google.com/www.google.com, then, assuming mail.google.com is
subdelegated, the list of queries for "A mail.google.com" will be:

(to .) NS com.
(to com.) NS google.com
OPTIONAL (to google.com) NS mail.google.com
(to google.com or to mail.google.com) A mail.google.com

And then for "A www.google.com":

OPTIONAL (to google.com) NS www.google.com
(to google.com or to www.google.com) A www.google.com

I see no leakage. Of course, the DNSmaster of google.com will learn
things but there is no way to avoid that.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 20 Mar 2014 15:30:41 +0100

* Tony Finch:

> description of an algorithm for finding them.

Yeah, I noticed that as well.

> There are evidently subtleties in this algorithm; for example, do
> you abort early if you get an NXDOMAIN response, or do you treat
> that as NOERROR/NODATA?

If we want to stop the 1.E164.ARPA leak, we'd have to stop at an
NXDOMAIN response, at least if the zone is signed.

> Or should you skip the third query?

I believe you can always query with QTYPE=A.  This only leaves the
empty non-terminal case open to ambiguity.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Mar 2014 10:30:59 -0400

> describe algorithms, probably to let some freedom to the

I think this is a very important effort. But we probably need to think
of it in terms of the proposed DBOUND work rather than tell people to
try to discover the zone cut through heuristics.

Heuristics are OK as a transition strategy but I don't like them as a
long term fixture.

The problem I have with the current DBOUND discussion is that it is
being driven by a use case I think is completely unhelpful. There are
no occasions where I think it is safe to share cookies across domains.
So trying to come up with rules for when it is safe is a losing
proposition and so is trying to develop a technology to meet that
goal.

DNS Privacy is a much better defined concern and one that we have a
good chance of addressing with something like DBOUND.

-- 
Website: http://hallambaker.com/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Mar 2014 15:45:27 +0100

On Thu, Mar 20, 2014 at 10:30:59AM -0400,
 Phillip Hallam-Baker <[email-masked]> wrote 
 a message of 35 lines which said:

> But we probably need to think of it in terms of the proposed DBOUND
> work

No, this is completely unrelated. Dbound is concerned about
_administrative_ boundaries. Qname minimisation needs only to know the
_technical_ boundaries.

Example: fr and gouv.fr are technically in the same zone (so, requests
with qname minimisation On will go to the same set of name servers)
but they are in different admistrative areas (a HTTP server for
gouv.fr certainly cannot set cookies in fr).

> Heuristics are OK as a transition strategy but I don't like them as a

It's not heuristics since it will always produce the same result. And,
more important, it is what all validating resolvers already do. (They
need to know the zone cut to know where to send DNSKEY and DS
requests.)

---

From: Casey Deccio <[email-masked]>
Date: Thu, 20 Mar 2014 10:54:01 -0400

> empty non-terminal case open to ambiguity.

Queries with qtype=A may not themselves be an issue, but in the context of
other problematic queries they too can yield false results.  For example,
recently I encountered a case in which a query for www.foo.example/A
returned an A record response, but www.foo.example/NS returned NXDOMAIN
(seemed to be a load balancer at fault).  If www.foo.example/NS was queried
first by the caching resolver, then subsequent queries to the cache for the
A record of the same name would return NXDOMAIN, until the negative cache
TTL expired.

Casey

---

From: Florian Weimer <[email-masked]>
Date: Thu, 20 Mar 2014 15:57:22 +0100

> Queries with qtype=A may not themselves be an issue, but in the
> context of other problematic queries they too can yield false
> results.

Sure, but it's probably safer to keep the original QTYPE when
searching the delegation.

> If www.foo.example/NS was queried first by the caching resolver,
> then subsequent queries to the cache for the A record of the same
> name would return NXDOMAIN, until the negative cache TTL expired.

Assuming that the negative answer is actually cachable—many irregular
NXDOMAIN answers do not include a SOA record carrying the negative
caching TTL.

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Mar 2014 15:06:48 +0000

> Authoritative one. (Which, by the way, answers your concern.)

I'm not worried about the spelling error: it is wrong to say that an NS
query sent to parent name servers gets an answer rather than a referral.
For example:

; <<>> DiG 9.10.0b1 <<>> +norec +noadditional ns ac.uk @nsa.nic.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3480
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ac.uk.                         IN      NS

;; AUTHORITY SECTION:
ac.uk.                  172800  IN      NS      auth03.ns.uu.net.
ac.uk.                  172800  IN      NS      ns3.ja.net.
ac.uk.                  172800  IN      NS      ns2.ja.net.
ac.uk.                  172800  IN      NS      ws-fra1.win-ip.dfn.de.
ac.uk.                  172800  IN      NS      ns1.surfnet.nl.
ac.uk.                  172800  IN      NS      ns4.ja.net.
ac.uk.                  172800  IN      NS      ns0.ja.net.

;; Query time: 14 msec
;; SERVER: 2001:502:ad09::3#53(2001:502:ad09::3)
;; WHEN: Thu Mar 20 14:27:41 GMT 2014
;; MSG SIZE  rcvd: 202

; <<>> DiG 9.10.0b1 <<>> +norec +noadditional ns ac.uk @ns0.ja.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28108
;; flags: qr aa; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ac.uk.                         IN      NS

;; ANSWER SECTION:
ac.uk.                  86400   IN      NS      ns0.ja.net.
ac.uk.                  86400   IN      NS      ws-fra1.win-ip.dfn.de.
ac.uk.                  86400   IN      NS      ns3.ja.net.
ac.uk.                  86400   IN      NS      ns2.ja.net.
ac.uk.                  86400   IN      NS      ns4.ja.net.
ac.uk.                  86400   IN      NS      auth03.ns.uu.net.
ac.uk.                  86400   IN      NS      ns1.surfnet.nl.

;; Query time: 6 msec
;; SERVER: 2001:630:0:8::14#53(2001:630:0:8::14)
;; WHEN: Thu Mar 20 14:27:34 GMT 2014
;; MSG SIZE  rcvd: 466

> minimisation, since there is none for traditional resolution.

RFC 1034 section 4.3.2.

> will be sent to the NS of ratp.fr.

Right.

> there is just one label more than the previous name.

But there *is* a zone cut here.

> I do not understand. Do you refer to gmail.com/google.com?

No, I mean, if I go to http://google.com in my browser, I will make A and
AAAA queries for google.com, but if I send mail to a Google employee I
will make MX queries for google.com.

So if you skip the NS query for google.com (because it is the whole of the
QNAME in this case) you will leak the A vs MX difference to the .com
servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking: Southwest 7 to severe gale 9. Rough or very rough. Rain then showers.
Moderate or good.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Mar 2014 11:09:34 -0400

> searching the delegation.

One of the concerns that just came to mind is that absent policy
requirements from ICANN, minimization might well cause registries to
take countermeasures if minimization was to affect their business
models.

So for example, imagine that the .greed domain has a contract to sell
the DNS traffic to the Evil Security Agency (ESA) and/or some
advertising network. At the moment their servers support NS queries.
But if minimization is introduced they might change policy and start
blocking.

Not a show stopper, but the code might want to consider counter
strategies. For example, if the request is for A records from
secret.example.evil, it might query for A records as follows

? A, _.evil
? A, _.example.evil
? A, www.example.evil

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Mar 2014 16:27:38 +0100

On Thu, Mar 20, 2014 at 03:06:48PM +0000,
 Tony Finch <[email-masked]> wrote 

> ac.uk.                  172800  IN      NS      auth03.ns.uu.net.

OK, I get it, sorry. Paragraph deleted from my local copy of the
draft.

> > minimisation, since there is none for traditional resolution.

OK, but it won't help since it is for authoritative name
servers. Resolvers are at section 5.3.3 and the algorithm is so
sketchy that it does not even mention the content of the query sent to
authoritative name servers.

Also, qname minimisation is _not_ a change in the protocol, it's more
an unilateral best practice ("privacy optimization"), and therefore
does not need to be specified by an algorithm. If several resolvers
implement it slightly differently, it is not a problem.

> QNAME in this case) you will leak the A vs MX difference to the .com

Said otherwise, if you skip the NS query step, and send "A google.com"
to the .com name servers, Verisign's name servers will send you back a
referral and then you'll learn the zone cut (this is what every
resolver already does today). So, there will be a leak only for the
first request (a simple heuristic to avoid this would be to always
send the NS query for the first two labels).

Anyway, I have no problem with saying that you should always send the
NS query to be sure, and too bad for the broken name servers like
those of www.ratp.fr. I even think Mark Andrews will agree with me
here :-)

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Mar 2014 17:41:04 +0000

Stephane doesn't like this because it is too specific, but I thought it
would be useful to have something concrete to discuss...

(0) If the query can be answered from the cache, do so, otherwise iterate
as follows:

(1) Find closest enclosing NS RRset in your cache. The owner of this NS
RRset will be a suffix of the QNAME - the longest suffix of any NS RRset
in the cache. Call this PARENT.

(2) Initialize CHILD to the same as PARENT.

(3) If CHILD is the same as the QNAME, resolve the original query using
PARENT's name servers, and finish.

(4) Otherwise, add a label from the QNAME to the start of CHILD.

(5) If you have a negative cache entry for the NS RRset at CHILD, go back
to step 3.

(6) Query for CHILD IN NS using PARENT's name servers. The response can
be:

(6a) A referral. Cache the NS RRset from the authority section and go back
to step 1.

(6b) An authoritative answer. Cache the NS RRset from the answer section
and go back to step 1.

(6c) An NXDOMAIN answer. Return an NXDOMAIN answer in response to the
original query and stop.

(6d) A NOERROR/NODATA answer. Cache this negative answer and go back to
step 3.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest FitzRoy: Northwesterly 5 or 6, backing westerly or southwesterly 6
to gale 8. Rough or very rough. Showers. Good.