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

[Hugo Maxwell Connery]

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 dns-priv...@ietf.org 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:

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

IN NSLOCALHOST.
;
; Psuedo-TLDs as per draft-grothoff-iesg-special-use-p2p-names
;
; Torproject
onion   IN CNAME .
*.onion IN CNAME .
exitIN CNAME .
*.exit  IN CNAME .
; GNUnet
gnu IN CNAME .
*.gnu   IN CNAME .
zkeyIN CNAME .
*.zkey  IN CNAME .
; Namecoin
bit IN CNAME .
*.bit   IN CNAME .
; I2P
i2p IN CNAME .
*.i2p   IN CNAME .
$TTL86400
@   IN SOA  @   root (
42  ; serial (d. adams)
3H  ; refresh
15M ; retry
1W  ; expiry
1D ); minimum

IN NSLOCALHOST.
;
; Psuedo-TLDs as per draft-grothoff-iesg-special-use-p2p-names
;
; Torproject
onion   IN CNAME .
*.onion IN CNAME .
exitIN CNAME .
*.exit  IN CNAME .
; GNUnet
gnu IN CNAME .
*.gnu   IN CNAME .
zkeyIN CNAME .
*.zkey  IN CNAME .
; Namecoin
bit IN CNAME .
*.bit   IN CNAME .
; I2P
i2p IN CNAME .
*.i2p   IN CNAME .
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

> Hugo Maxwell Connery 
> Sunday, January 25, 2015 5:32 AM
> 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).

sadly, i remain unaware of any non-BIND implementation of RPZ. if there
are any, please tell us, so that we can update the
 web site.

> ...
> 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.

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?)

second:

> ;
> ; 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 .
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Christian Grothoff]

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




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Jan 25, 2015, at 3:15 PM, Paul Vixie  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 web site.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

> Ted Lemon 
> Sunday, January 25, 2015 12:30 PM
>
>> Paul Vixie 
>> Sunday, January 25, 2015 12:15 PM
>>
>>
>>> Hugo Maxwell Connery 
>>> Sunday, January 25, 2015 5:32 AM
>>> 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).
>>
>> sadly, i remain unaware of any non-BIND implementation of RPZ. if
>> there are any, please tell us, so that we can update the
>>  web site.
>
> Nominum offers a similar feature in our caching nameservers, unless I
> am missing something.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

> Christian Grothoff 
> Sunday, January 25, 2015 12:29 PM
> ...
>
> 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).

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$$.)
>
> 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.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJUxaE/XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9fUAP/RWiebtpevUa0dpNsSAppUgr
nivORo9Yn0rs0EEnMaF/578V4/bdfJo2trCJmH2hmWb4ELXOIKPLKzErQCQFzTE6
ykVdE82WNgUhexRCyq78D0i2/XO9ER5jAcECh9Bx63fd36qqXFy0w0guVF2OVTDp
3hO9RCVC6ExZK+bFPlS0It67cYwWoQK0sbkZ6zzyc21ao6fACpwjrg0hT8+t49k/
+9k3tIobdzU4vAWOhhaf6TiIPZizBqdWnJ3y73YRXu6IYjas1nymHy6dWK7qIdKt
ccCdEL6zAkPdRuAS7TNaq29W5YMFvnj6m6k8uEMR6YHbKuOe2KFAVY3QYeZohr2O
onCm5AtJ2P6Iv/byEoYCoqljG0ujGobUT2N9IhFVkt2vpPbaIUjAVFhk0/mqjC99
RmLqUhWQg+jN43PqWYjPZDA7KKm77uWeniqIFdEy9mKFAcrrmyObSiH8xJkquM28
gRLltFW6DwvDVRvtbNHi+cdQVKcQU4eHpLUAGBdBeF2oqPmXLAWFf7LcJ96CP78U
AMFirFoQEq2QWtWP1CUei+rY3V6DrEb/JslonwTuI5/TWEyVdvBSKMlYG10O4k44
DnVogrDcaJNDpv4/I1rhMtdA05Dvvx8viP/EWpzC8BVxnXxldD5MvtbxlYRToxUl
xaPZIdwmmClM6CIXBhzx
=H+G7
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Hugo Maxwell Connery]

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
--
Technical University of Denmark


From: Paul Vixie [p...@redbarn.org]
Sent: Monday, 26 January 2015 01:01
To: Christian Grothoff
Cc: Hugo Maxwell Connery; dnsop@ietf.org; dns-priv...@ietf.org
Subject: Re: Complying with draft-grothoff-iesg-special-use-p2p-names

[cid:part1.06030909.07040101@redbarn.org]
Christian Grothoff
Sunday, January 25, 2015 12:29 PM

...

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).

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$$.)



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.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop