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

[Hugo Maxwell Connery <[e-mail]>]

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 [[e-mail]]
Sent: Monday, 26 January 2015 01:01
To: Christian Grothoff
Cc: Hugo Maxwell Connery; [e-mail]; [e-mail]
Subject: Re: Complying with draft-grothoff-iesg-special-use-p2p-names

[cid:[e-mail]]
Christian Grothoff<mailto:[e-mail]>
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