In message <5ca637ee-c0b6-4e5c-a446-a84431176...@fugue.com>, Ted Lemon writes: > > On Feb 7, 2017, at 11:45 AM, Warren Kumari <war...@kumari.net> wrote: > > I don't think I've seen a good argument for NOT doing the above -- why > > (other thabn the sunk time / effort) don't we do two? > > Right, this just seems obvious to me. If we do two, we can tailor each > solution to the need it is intended to fill, rather than trying to come > up with some compromise that isn't ideal for either case.
Because we want to prevent the names leaking any further than we have to and to not have the leaked names get SERVFAIL the solution to both is the same. The delegation properties are driven by privacy and the DNS protocol which includes DNSSEC because that is where the leaked names are being looked up. If you really do want to spend the time and effort to create two delegations when only one is needed the only difference is does the recursive server always instantiate the local empty zone or not. i.e. is it recursing rather than iterating to get answers for *.alt. The delegation in the root zone needs the same properties in both cases. For RFC 1918 zones named only instantiates the empty zone when the recursive server will iterate for answers. If it always forwards to another recursive server then the instantiation is blocked. You will note that 10.in-addr.arpa has a insecure delegation in the global dns namespace like every other locally served zone. They have such a delegations so that recursive server can give answers which can be validated regardless of whether the RFC 1918 address space is in use or not. We did good engineering for locally served zones (RFC 6303). Lets follow the good engineering there rather that religiously demand that the delegation be signed because the later does not work. The E in IETF is for ENGINEERING. 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
