> On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews <ma...@isc.org> wrote: > > In message <a6839264-7054-4a08-828b-66bfa6c94...@fugue.com>, Ted Lemon writes: > > > > On Feb 8, 2017, at 3:30 PM, Mark Andrews <ma...@isc.org> wrote: > > > And if the service has the same privacy issues as .onion has? > > > > > > So we leak names until every recursive server in the world is > > > validating (what % is that today?) and supports agressive negative > > > caching (still a I-D). > > > > I feel like I am arguing with a wall, so if this doesn't work I will just > > give up. But if it's okay for us to ask resolvers to make a chance, it > > is okay for us to ask resolvers to make the right change. And if they > > don't, yes, it's possible that some queries will leak. There is nothing > > we can do to prevent that other than harden caching servers and stub > > resolvers; if we are going to do that, we might as well do it right, by > > caching the full proof of nonexistence, rather lying about what's in the > > root zone. > > Actually we can do something that doesn't require that validation > be enabled. We don't have to create that linkage. It's not like > the names are not supposed to exist. They do/will exist and not > as in they are/will be squatted upon. > > I'm confused here. > > The point of ALT (and/or LCL if a 2nd draft is created), and ONION, is > that they exist ONLY within their own (local) scope, if they exist at all. > > From the viewpoint of the global DNS, they do not exist, and the point > of those I-Ds/RFCs is to enforce that non-existence, in the global scope. > > My problem with what you are proposes, is that it removes the mechanism > for that enforcement. > > Here's a thought - for any/all validating stubs, use CD=1 for names in the > set of "things that are meant to be local", and turn off validation of > those. That *should*, if I understand 4035's directives for CD=1, prevent > validation by the recursive resolver in use by the client, and will return > whatever answers are present, with or without DNSSEC records. > > Or, perhaps the organizations that represent the requestor of the 6761 > names, could establish something like a "distrust anchor" - a trust > anchor which is only to be used for signing negative assertions > about the TLD name, or assertions about its insecure status to enable > local service of the TLD name, and which can be published to the > community, along with a static DNS zone file to be served by the > <name>-aware resolvers? > > Again, just to reiterate, in the global root zone, and for any resolvers > which are not yet onion-aware, onion does not exist and must not exist. > > For onion-aware resolvers, everything related to onion is just an > optimization; avoiding leakage for privacy reasons might be an issue > for some folks, but IMHO must not tread on the previous requirement > - that onion must not exist in the root, and must not appear to exist > to any onion-unaware resolvers. > > If you want to find a way to fix that, without resulting in BOGUS or > SERVFAIL, there may be ways that aren't easy, but the one way not > permitted by the published RFCs is, an unsigned delegation in the root. >
I would like to just throw this out there again.. what about a new RR type to actively flag the owner as officially not-existing? I could even volunteer to write this if it seems reasonable. It seems to me this issue has come up a number of times (.onion, etc.) and it keeps needing to be solved each time. The 6761, etc. and related special-use registry contains a number of 'SHOULD' and 'SHOULD NOT' requirements that need to be compiled into software, why not generalize this a bit more just in case it happens again. There is also the small matter of money vs. free. If a zone is "simply" delegated in the root zone, at some future point this delegation "could" become a free service. Without definitive "technical" rational for name use, this is a difficult sell. By defining an RR type purposefully preventing this condition, it might be an easier pitch. Just a thought. Thanks, John > I'm not sure why you disagree with this, it is clear as day in the > relevant RFCs. > > Brian > > > > > Oh sorry, you can't have privacy unless you validate. And only > because people are too scared to ask for changes to the root > zone to add a delegation. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
