In message <9b6211a9-20b5-4b15-a8fd-a1390dad7...@fugue.com>, Ted Lemon writes: > > On Feb 3, 2017, at 4:09 PM, Mark Andrews <ma...@isc.org> wrote: > > You need a insecure delegation for ALT for the purposes we want to > > use ALT for. > > I don't think there's consensus on what we want to use ALT for. I see > Ralph arguing that ALT is never used to resolve things using the DNS > protocol, and I see you saying that that's one of the uses we have in > mind. We need to figure out which of these we are actually trying to do.
I think there is a consensus for a play space. I think there is consenus on there not being any delegations under this play space with iterating down from the root. I think there is consenus that leaked queries of the form foo.alt should be getting NXDOMAIN responses from a recursive server which would otherwise be iterating down from the root for this namespace. > If you are right, we need an insecure delegation in the root, and ALT > queries will by default be answered using DNS (in the sense that existing > resolvers have no special-case handling for ALT). If Ralph is right, > you can still use the DNS protocol to resolve names in .ALT, but you have > to use a specially modified resolver to do it: one that ignores the > secure denial of existence from the root. So you want to ban BYOD from the solution space? Remember adding a alt zone to a recursive server is modifying the resolver. It is changing its observed behaviour. It isn't code but it is a modification. Why does this working group feel the need to add extra proscriptions on how this play space is to be used? I've been arguing for the broadest solution space. Its also the simplest. A insecure delegation for ALT. It is also the easist one for recursive servers which are iterating from the root that are not participating in the experiment to filter leaked queries with. 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
