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