Subject: [DNSOP] Complying with draft-grothoff-iesg-special-use-p2p-names

From: Hugo Maxwell Connery <[email-masked]>
Date: Sun, 25 Jan 2015 13:32:53 +0000

Hi,

Below I show a trivial amount of work for compliance with
draft-grothoff-iesg-special-use-p2p-names by caching
recursive resolvers which have implemented Response
Policy Zones (i.e BIND and numerous others).  I am not
claiming that this is the best solution, or that it
is the best way to do this with RPZ, only that it
works, is efficient, is a one time job, and is trivial.

Summary for BIND:

* copy and paste to create one new zone file
* copy and paste about 10 lines into named.conf
* rndc reload

Following the config presented, I add more verbiage.

named.conf:

options
{
  // much other stuff ....

  response-policy
  {
     // pseudo-TLDs
     zone "pTLD"       policy NXDOMAIN;
  }
}

zone "pTLD" in
{
  type master;
  file "pTLD.zone";
};

pTLD.zone: attached, and reprinted at the end.

I have been working with Response Policy Zones for several
years now, and consider it an essential part of our network
defence, preventing access to purely nasty domains, and 
serving as a anti-phishing defence.

Here it is efficiently serving an entirely different purpose.

I have also been participating in the DPRIVE IEFT WG mailing
list looking at privacy for DNS.  IMHO it is impossible to take all of
DNS as it is now and deliver the sorts of privacy which some
may wish.  Various differing strategies to privacy in DNS are
well discussed in a recent academic publication available at:

  https://gnunet.org/sites/default/files/mcb-en.pdf

and/or see the [email-masked] mailing list archives :)

The issue at hand is that different communities have
different threat models, and no one technical model meets
the balances between Freedom, Security and Convenience (cf.
Dan Geer) that differ amongst the communities.

Where communities are developing solutions that meet
their needs whilst complying with standards, and expending
effort to participate in standardisation processes,
I suggest that we pay them the courtesy of considering
their input.

Overlay networks have a role to play in this space, providing
solutions for differing threat models which a 'one size
fits all' model cannot.

It may be clear that I support:

  draft-grothoff-iesg-special-use-p2p-names

Regards,  Hugo Connery
--
Technical University of Denmark

pTLD.zone:

$TTL    86400
@               IN SOA  @       root (
                                        42              ; serial (d. adams)
                                        3H              ; refresh
                                        15M             ; retry
                                        1W              ; expiry
                                        1D )            ; minimum

                IN NS            LOCALHOST.
;
; Psuedo-TLDs as per draft-grothoff-iesg-special-use-p2p-names
;
; Torproject
onion           IN CNAME .
*.onion         IN CNAME .
exit            IN CNAME .
*.exit          IN CNAME .
; GNUnet
gnu             IN CNAME .
*.gnu           IN CNAME .
zkey            IN CNAME .
*.zkey          IN CNAME .
; Namecoin
bit             IN CNAME .
*.bit           IN CNAME .
; I2P
i2p             IN CNAME .
*.i2p           IN CNAME .

---

From: Paul Vixie <[email-masked]>
Date: Sun, 25 Jan 2015 12:15:53 -0800

> Hugo Maxwell Connery <mailto:[email-masked]>
> Sunday, January 25, 2015 5:32 AM
> Hi,
>
> Policy Zones (i.e BIND and numerous others).

sadly, i remain unaware of any non-BIND implementation of RPZ. if there
are any, please tell us, so that we can update the
<https://dnsrpz.info/> web site.

> ...

we also used RPZ in the response to "DNS Changer" (see
http://www.circleid.com/posts/20120327_dns_changer/), so, it's safe to
say that RPZ is now a real tool -- because it's been used used and/or
abused in ways its designers never contemplated.

i have two questions. first, why would you want to pre-distribute a
"master" zone file containing these DNS cutouts, rather than operating
an AXFR server and inviting interested parties to "slave" the RPZ from
you in case the set of cutouts is changed some time in the future (adds,
deletes, renames?)

> ; Psuedo-TLDs as per draft-grothoff-iesg-special-use-p2p-names
it appears here that your concern is to resolve any future collision
between an ICANN gTLD and a "p2p" gTLD, in favour of the "p2p" gTLD, and
that you'd like to enforce this by having those queries never arrive at
any IANA root name server in the first place. (because, today, those
queries would all be answered with NXDOMAIN). my question is: why do
this, rather than passing a law ("adopting an RFC") that reserves these
names within the IANA system, such that the NXDOMAIN source can reliably
be the IANA root name servers?

thanks again for your kind words about RPZ.

-- 
Paul Vixie

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Jan 2015 15:23:12 -0500

> be the IANA root name servers?

Indeed, if something like the draft in question were to be published
as an RFC (and as I've already argued, I think the names in there
ought to be treated independently, but people of good will can
disagree), the reservation would be exactly that result.  The proposal
to use a widespread configuration of RPZ to chip away at the
legitimate answers from root name servers strikes me as a rather
dangerous arrogation of control over the root zone and contrary to the
observations in RFC 2826.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Christian Grothoff <[email-masked]>
Date: Sun, 25 Jan 2015 21:29:11 +0100

On 01/25/2015 09:15 PM, Paul Vixie wrote:> my question is: why do this,
rather than passing a law ("adopting an
> RFC") that reserves these names within the IANA system, such that the
NXDOMAIN
> source can reliably be the IANA root name servers?

Dear Paul,

We are also trying to "pass that law", and as Hugo said he supported that.

Now, even with such a rule, his suggestion still makes sense given our
privacy goals: While the IANA root name servers might afterwards be
relied upon for the NXDOMAIN, merely asking the IANA root name servers
might leak private information (like say, the existence of a particular
.onion), especially as the user does not expect to use DNS for those
TLDs. So the less we send traffic for those over the network, the better
(some harm might have happened already, but we can avoid making it
worse). Naturally, query minimization would help here as well, but until
that is broadly implemented, just not asking is also a good idea.

Furthermore, while we expect this to be rare in the first place, people
voiced concern about the additional traffic at the root zone from the
pTLDs, so using this configuration we can make sure that doesn't happen
(even though I personally can't imagine this to be a real issue in
practice).

Naturally, you are right in that Hugo's configuration is merely a
supporting action, the first and most important thing is getting the
draft adopted and thus ensuring the root servers won't have a
conflicting definition in the future.

Best regards,

Christian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Jan 2015 15:30:42 -0500

On Jan 25, 2015, at 3:15 PM, Paul Vixie <[email-masked]> wrote:
> sadly, i remain unaware of any non-BIND implementation of RPZ. if there are any, please tell us, so that we can update the<https://dnsrpz.info/> web site.

Nominum offers a similar feature in our caching nameservers, unless I am missing something.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Jan 2015 08:26:48 +1100

You don't need rpz to solve the privacy problem.  A local copy of
the root zone does that.  It also solves the leaked unqualified
names problem.

Mark

masters f.root-servers.net { 192.5.5.241; 2001:500:2f::f; };

zone "." {
	type slave;
	masters { f.root-servers.net; };
	file "root.db";
	notify no;
};

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sun, 25 Jan 2015 15:55:32 -0800

> Ted Lemon <mailto:[email-masked]>
> Sunday, January 25, 2015 12:30 PM
>
>> Paul Vixie <mailto:[email-masked]>
>> Sunday, January 25, 2015 12:15 PM
>>
>>
>> sadly, i remain unaware of any non-BIND implementation of RPZ. if
>> there are any, please tell us, so that we can update the

the difference is, RPZ is an open and common policy language for RDNS,
and is not vendor-specific. it's possible for any security policy feed
producer to generate threat intelligence in the RPZ format, and make it
available to any RDNS operator whose name server understands RPZ.
nominum has been doing policy feeds in its recursive name service
product for many years, but the format is not open, and it's not meant
to be a generic publish-subscribe method for any RDNS operator (whether
or not they are a nominum customer) to subscribe and for any security
policy feed producer (whether or not they are a nominum partner) to publish.

beyond that, there may be more or fewer features in the nominum caching
name server than are described by RPZ. i don't know the details of the
nominum product, and i have not seen any side-by-side comparison. i
would very much like to see nominum customers gain the ability to
subscribe to RPZ feeds. but i'm going to work primarily with the open
source DNS providers first, since a vibrant ecosystem would be my best
argument for adoption.

TL;DR: nominum has had similar functionality to RPZ in their proprietary
caching name server, for many years longer than RPZ has existed, but
nominum's goal was apparently not an open multi-vendor policy
marketplace, therefore RPZ has a place in the world, even though coming
very late from nominum's perspective.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Sun, 25 Jan 2015 16:01:33 -0800

> Christian Grothoff <mailto:[email-masked]>
> Sunday, January 25, 2015 12:29 PM
> ...
>

as marka@ISC pointed out, an RDNS operator with QNAME privacy concerns
can also just slave the DNS root, as was done by default in freebsd a
few years ago, and as is described in the kumari/hoffman internet draft
now circulating. slaving the root zone has its own tradeoffs, but i
think equal or higher benefits with obviously lower risks than a widely
distributed RPZ-based (static configuration) approach would have.
(TL;DR: pretty much everything we ever hard-code comes back to bite us
in the a$$.)
> conflicting definition in the future.

well then in spite of how much i like to see RPZ get used, i suggest
that you put the horse first, cart second, which means: get the IETF to
recommend to IANA that these names be reserved, and then and only then,
workshop the various methods of implementing that reservation. you'll be
in a world of hurt if somebody does early-adoption on your RPZ-based
suggestion, only to find that the IANA reserves a slightly different set
of names (or no names at all) compared to what you asked for.

-- 
Paul Vixie

---

From: hellekin <[email-masked]>
Date: Sun, 25 Jan 2015 23:07:07 -0300

On 01/25/2015 09:01 PM, Paul Vixie wrote:
> 
> get the IETF to recommend to IANA that these names be reserved
>
*** Yes indeed.  Can we get back to the draft-04?  It sure will bring up
some interesting if not controversial comments, as some parts changed
substantially to address most of the previous comments.

Regards,

==
hk

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Mon, 26 Jan 2015 10:47:32 +0000

Hi,

"For every complex problem there is a simple, efficient
solution which is wrong".

And that seems to be the case for my suggestion for
compliance.

Persons wiser than me have suggested that the real solution
is that which the overlay community (tor, i2p, gnunet etc.)
have been working on: using the standardisation process
to ask the IANA to reserve these names.

One hopes that the governing body can understand that
these communities are addressing in the DNS privacy  
problems that the DPRIVE WG has been asked to consider,
and that their existence and implementations can
support the WG's efforts.

Thanks to all for their input, especially Mark (ISC)
and Vixie.

Regards,  Hugo Connery

________________________________________
From: Paul Vixie [[email-masked]]
Sent: Monday, 26 January 2015 01:01
To: Christian Grothoff
Cc: Hugo Maxwell Connery; [email-masked]; [email-masked]
Subject: Re: Complying with draft-grothoff-iesg-special-use-p2p-names

Christian Grothoff<mailto:[email-masked]>
Sunday, January 25, 2015 12:29 PM

...

as marka@ISC pointed out, an RDNS operator with QNAME privacy concerns can also just slave the DNS root, as was done by default in freebsd a few years ago, and as is described in the kumari/hoffman internet draft now circulating. slaving the root zone has its own tradeoffs, but i think equal or higher benefits with obviously lower risks than a widely distributed RPZ-based (static configuration) approach would have. (TL;DR: pretty much everything we ever hard-code comes back to bite us in the a$$.)

well then in spite of how much i like to see RPZ get used, i suggest that you put the horse first, cart second, which means: get the IETF to recommend to IANA that these names be reserved, and then and only then, workshop the various methods of implementing that reservation. you'll be in a world of hurt if somebody does early-adoption on your RPZ-based suggestion, only to find that the IANA reserves a slightly different set of names (or no names at all) compared to what you asked for.

--
Paul Vixie