Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Ted Lemon writes:
>
> On Feb 7, 2017, at 11:45 AM, Warren Kumari <[e-mail]> 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: [phone]                 INTERNET: [e-mail]