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<mailto:christ...@grothoff.org> 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
