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

Bob Harold <> Tue, 07 February 2017 15:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9429129C8C for <>; Tue, 7 Feb 2017 07:01:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n4vbDBBYWBa2 for <>; Tue, 7 Feb 2017 07:01:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2C80129BC5 for <>; Tue, 7 Feb 2017 07:01:25 -0800 (PST)
Received: by with SMTP id w75so68166348ywg.1 for <>; Tue, 07 Feb 2017 07:01:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id f12mr11162864ywb.80.1486479684500; Tue, 07 Feb 2017 07:01:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 7 Feb 2017 07:01:23 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Bob Harold <>
Date: Tue, 07 Feb 2017 10:01:23 -0500
Message-ID: <>
To: Brian Dickson <>
Content-Type: multipart/alternative; boundary="001a114630188fb7460547f2055c"
Archived-At: <>
Cc: " WG" <>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Feb 2017 15:01:31 -0000

On Mon, Feb 6, 2017 at 10:37 PM, Brian Dickson <> wrote:

> TL;DR: it is possible to have a signed DNAME in the root for alt (to
>, 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 <> wrote:
>> In message <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.
>> , 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