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:

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

Reply via email to