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

Brian Dickson <> Tue, 07 February 2017 03:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34E1512988F for <>; Mon, 6 Feb 2017 19:37:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 RauqDFtj0fmE for <>; Mon, 6 Feb 2017 19:37:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 422DE129882 for <>; Mon, 6 Feb 2017 19:37:26 -0800 (PST)
Received: by with SMTP id v96so81271896ioi.0 for <>; Mon, 06 Feb 2017 19:37:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BOsqZFkhnY3ULJNj4itClOoH9Mf/56sJSjdAVH+fcmQ=; b=UY88CUuXAXoCoyW4MHzt7/lHsgZfzKSHfOKR3rDm9GM7jMUkNFFqZo4Df0Paso4KwI t09ts93ZNeqLwps91Xa614p1moMBunHIW9iVb9jYXnglQHLjNxePktHDTEB1r0z4sq7U m8xqOoaEOx5/Dc/VNJle7F/s05R4Leb6unxnUyroTYq5vwHOZau8URcdJ2cAfgeRW6g0 nTrBt9WvwMWaKROI+MpMrwihCu+rUMcR/6DjcNMj0Bu513vjxbo20TS+CA5TFn0Baj26 LzTkZgOK9wFJD9AeeXxYX7EtEWzCvuSmfocqUZfCMkrJ6GLJ81z9EmzlIIbyMzsBdhuH fJYg==
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=BOsqZFkhnY3ULJNj4itClOoH9Mf/56sJSjdAVH+fcmQ=; b=f9vr+4YcWLyHLqKwQmNtfuM42jz/pALPnrceei/RVyQbJeXv+CRIjbXyj8eVUbfRqs +m0KMurehLoOPe3sCpFrWMDU8BRUXfDoBvoQV4/Nl+CK4L95aJNL66ViduC3MNnf3mJm 2u0VRhWOFg/t1qiHSpT6IdSaOiIRXHFq9BkcXvhhOmsgTYoMOJMidCINM2UD9wR+y4LU wnsGrg0Qw7rcBcYNF4TVnmCSDA4hjhUvZYftJcAaKRgExzWQUS0X+g/RDJ85OY1N9oJE ywWPeO+gNaVyG+Fj1U52fsCBdNhf54skhn55bl6ucbRkNz6cqCZwLJeEaM7uUmrXsWIO Oupw==
X-Gm-Message-State: AMke39lCho/TV5RXELVr2Z/hMecSlKF+Kps0GZmGmTYAmVdBIc5LesihsUvqLCM8jKdJWtCPiUhoEn8myiysGQ==
X-Received: by with SMTP id y14mr2229645ioi.164.1486438645540; Mon, 06 Feb 2017 19:37:25 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Feb 2017 19:37:24 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Brian Dickson <>
Date: Mon, 06 Feb 2017 19:37:24 -0800
Message-ID: <>
To: Mark Andrews <>
Content-Type: multipart/alternative; boundary="001a113fece272cf3b0547e877d3"
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 03:37:28 -0000

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@
> , 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
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".