>I think I used zone cuts to mean something it's not, I meant >"establish separation lines in DNS that parties (like browsers, or >anyone using PSL) can use to make security decisions about what is an >'open' domain hierarchy with mutually distrusting participants versus >what is a 'shared' domain where all the subdomains are >administratively joined." I (hope) that's closer to what DBOUND is >after.
Well, that's one usage scenario. DBOUND is very difficult because people use the PSL for radically different things, and people who want it for one application have a surprising amount of trouble dealing with the fact that an approach that works for one application may be hopeless for another. >I didn't think you'd have worked with reserved names, but what I'm >curious about is if there could be an easy way to put in a DBOUND >record for (say) onion. with a with flag meaning "This name is >reserved and should not be resolved unless you know how to >specifically handle it." I can't think of any application that plans to use DBOUND to ask whether to try to resove a name at all. After all, the DNS already has a perfectly good way to ask whether a name exists -- you look it up and see if you get an answer or an NXDOMAIN. As I understand it, our goal here is to deal with a situation in which an application uses a name that is intended to be handled in a special way (say blah.onion) but due to misconfiguation is instead sent to a normal DNS resolver. No matter how we implement DBOUND, this would require an extra lookup before every single DNS query, which seems like a really bad idea. If we're going to fix this, it has to be fixed if not at the roots as close to them as possible. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
