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

Bob Harold <rharolde@umich.edu> Tue, 07 February 2017 15:01 UTC

Return-Path: <rharolde@umich.edu>
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 D9429129C8C for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2017 07:01:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 n4vbDBBYWBa2 for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2017 07:01:25 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C80129BC5 for <dnsop@ietf.org>; Tue, 7 Feb 2017 07:01:25 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id w75so68166348ywg.1 for <dnsop@ietf.org>; Tue, 07 Feb 2017 07:01:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+FxmRYiC3foaeqSTjCC5S45uwXdXnYPDTMSNaBKH1JY=; b=CqdQmmX/aRmzecqXUFqgandMs+5F04nQxmEFQQYJ1LyRNTLCAW0WjY5hmugAFFIIgx kd7NKdvLpsYi0HPANcjAvf7nehBZF4z75IlDmzxkYrpY3dA8pps8UG5uJqCDXUiH6a89 rLI14gtGm4yRuqk2MFkiBJyh2xET8+wsJzofPqf1eTew/5YLQ0AqQlwYLiRnQArJlgNf rIlPUygdfrZGSnE7j+xob+9GkgVFBKrWo9TU3WYQReLKF6/Y5HucNXvKcd8ZDuuYWrw0 uNfxdQYXVL4LrEW/U2lHqLu1uPmnj0vPfx8q4Bz55uJY9gOEGZ/6BbWGn6LaG9l1g9SX pozA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+FxmRYiC3foaeqSTjCC5S45uwXdXnYPDTMSNaBKH1JY=; b=FVC+9a9jplDIY48PgXgJnnu4vuxR4CSzMm5302HXtZ7c/nE+MYlftAyDv/9hZNV9rJ 5G8lblX3Xh3DAarZTVs0NC1xKFh2W+XBFW1Hymc/GkEcgmaQIc7olK/HOBaM9JMDK5AV g1uIXxJXC8EW2S+mXfr86Eh/KoW1P2dgkasf+7PU3EDEZVADusL5aZZGuNM5hJAw4J6D czfScqwiD0FKBX2xX7LLEra1KH9lBQ7OX9L1TMdLepIE+zTCGN05JTyuDDWFJ9SRgLyD 0xcHlInbA6wyn8f8RXPUbsu3MvE67DXP4IaYJ8AUTYoYC/2buDPPffxD3McntLc/ceQQ L7hw==
X-Gm-Message-State: AMke39l8oMJmfRPEuLcSSXBrKi07c2H3Ij8hr72I6ZtBIYkwH1wuvtTejCANjrUwmv9x4t+caBJrFYD06Z917KYe
X-Received: by 10.129.81.12 with SMTP id f12mr11162864ywb.80.1486479684500; Tue, 07 Feb 2017 07:01:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.237.68 with HTTP; Tue, 7 Feb 2017 07:01:23 -0800 (PST)
In-Reply-To: <CAH1iCipKwcOsMQY3kjvSZ42LMK37GLD6GP2AVtnWK0c83k-RiA@mail.gmail.com>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <20170203210922.7286C618213C@rock.dv.isc.org> <CAH1iCipKwcOsMQY3kjvSZ42LMK37GLD6GP2AVtnWK0c83k-RiA@mail.gmail.com>
From: Bob Harold <rharolde@umich.edu>
Date: Tue, 7 Feb 2017 10:01:23 -0500
Message-ID: <CA+nkc8DGSs+bEEYMerckx3SGV+ZQGgEfd5+4FM4xSfoeG=-SGA@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Content-Type: multipart/alternative; boundary=001a114630188fb7460547f2055c
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ttPOXPsgXQhnSk-_es87yPY8DY8>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
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 15:01:31 -0000

On Mon, Feb 6, 2017 at 10:37 PM, Brian Dickson <
brian.peter.dickson@gmail.com> wrote:

> TL;DR: it is possible to have a signed DNAME in the root for alt (to
> empty.as112.arpa), AND have a local signed alt. Things under this local alt
> can be signed or unsigned.
>
> On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews <marka@isc.org> wrote:
>
>>
>> In message <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.
>> gmail.com>
>> , Brian Dickson writes:
>> >
>> >    - I am in favor of AS112 for ALT
>> >    - For AS112, I prefer the AS112++ method (DNAME)
>> >    - I do not see why the DNAME would/should not be DNSSEC signed
>> >    - Any local use of ALT can be served locally and signed using an
>> >    alternative trust anchor
>>
>> You need a insecure delegation for ALT for the purposes we want to
>> use ALT for.
>>
>> Go setup a test rig where you have a signed root with ALT as you
>> described.  A validiting recursive server which also serves foo.alt.
>> A second validating recursive server which forwards all queries to
>> the first recursive server.  All servers are configured with a trust
>> anchor for the test root zone and are validating responses.  Try
>> to perform a lookup on foo.alt.
>>
>
> I spent some time mocking up a variety of configurations.
>
> My original assertion stands; the particulars on making it work are
> perhaps not interesting to everyone.
> However, it falls in the "pics or it didn't happen" category, so here's
> what I did to make it work.
>
> 1 - set up a general resolver with the standard ICANN root trust anchor.
> Call it "X".
> 2 - set up a local "fake root server" which delegates to a "local alt
> server". Call this fake root server "F"
> 3 - set up a local "alt server" which serves the local "alt" domain
> (including any delegations, etc). Cal this "A".
> 3 - set up a second resolver, with appropriate trust anchor(s), that uses
> a "fake root server" instead of the real root. Call this "Y".
> 4 - set up a forwarder, which is configured to always forward to "X",
> except for the zone "alt", where it forwards to "Y". Make sure the
> necessary trust anchors are configured. Call this "Z".
>
> Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust
> anchors)
> Z->X otherwise (and validates using the ICANN root trust anchor).
>
> When I do this, I get real answers for everything but "alt". For anything
> at or under "alt", I get my own local copy.
>
> Everything validates (or is from below an insecure delegation point).
>
>
>>
>> The second recursive server is the validating client that needs to
>> be able to get a answer other than BOGUS.  As we want to allow
>> foo.alt to be unsigned there can't be any other trust anchors,
>> including negative, configured.
>>
>
> In the above scenario, you CAN have an unsigned foo.alt, and it will not
> get BOGUS.
>
> If you want me to send you configs, just drop me a line.
>
>>
>> Only solutions which allow content from the foo.alt zone to be
>> successfully resolved are acceptable.
>>
>> The following will not work with the above rig:
>> * No delegation for ALT.
>> * A secure delegation for ALT.
>> * A DNAME for ALT in the root zone.
>>
>> Mark
>
>
> The problem is with your set-up, not the ability to have a working
> local-alt set-up.
>
> You need to put "foo.alt" somewhere OTHER than on the validating recursive
> server (which knows how to find the local "alt" stuff.)
>
> TIL you can't mix authority and recursive on the same server, when you are
> the target of a forwarder.
>
> If the two are separated, it works correctly, including using an alternate
> trust anchor for "alt".
>
> Brian
>
> That's a lot of overhead just to get a local .alt domain.

What I envision for the future is an insecure delegation of .alt, and an
option in future cable modems to enable a local "homenet.alt" domain, which
would just work, even if some stub resolvers in the house are validating.
The cable modem is already a recursive resolver or forwarder, and dhcp
server, so it seems a logical place for the local domain.

-- 
Bob Harold