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

Mark Andrews <marka@isc.org> Tue, 07 February 2017 20:56 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24490129411 for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2017 12:56:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1kFYhKEW3Hz for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2017 12:56:04 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7891A1293FF for <dnsop@ietf.org>; Tue, 7 Feb 2017 12:56:04 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id B72481FCB02; Tue, 7 Feb 2017 20:56:00 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7114B160054; Tue, 7 Feb 2017 20:55:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4F505160077; Tue, 7 Feb 2017 20:55:59 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r9WdFCv4UpSL; Tue, 7 Feb 2017 20:55:59 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DD8CC160054; Tue, 7 Feb 2017 20:55:58 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B6974633BE40; Wed, 8 Feb 2017 07:55:54 +1100 (EST)
To: Ted Lemon <mellon@fugue.com>
From: Mark Andrews <marka@isc.org>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <20170203210922.7286C618213C@rock.dv.isc.org> <CAH1iCipKwcOsMQY3kjvSZ42LMK37GLD6GP2AVtnWK0c83k-RiA@mail.gmail.com> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <D4C0D518-A3ED-4555-93DA-2EA12D82A662@fugue.com> <CAHw9_iK7Vt+ZNw8=E-b+w9gGhwB9fZNqHYp2pqKqT__RgcDttQ@mail.gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com>
In-reply-to: Your message of "Tue, 07 Feb 2017 12:18:23 -0500." <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com>
Date: Wed, 08 Feb 2017 07:55:54 +1100
Message-Id: <20170207205554.B6974633BE40@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/p5S3POc326MYVlYm5fzE35U7co4>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2017 20:56:06 -0000

In message <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com>, Ted Lemon writes:
>
> On Feb 7, 2017, at 11:45 AM, Warren Kumari <warren@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: marka@isc.org