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

Brian Dickson <> Tue, 07 February 2017 07:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0E9812941E for <>; Mon, 6 Feb 2017 23:56:01 -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 OBiSuoesxVJY for <>; Mon, 6 Feb 2017 23:56:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39434129488 for <>; Mon, 6 Feb 2017 23:56:00 -0800 (PST)
Received: by with SMTP id c7so73963929itd.1 for <>; Mon, 06 Feb 2017 23:56:00 -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=JXgXkYnDg6cEs7lUZW4Sw/p6c7IDj4UAQMY2TqtlOqE=; b=u1z3bw+x2hf08X8glj1N6h4/H33VOt4qK/S6b/exthtHbZ91hlY3z+kOkqyFnGnQWR Q2Jw5MH8X4qSM+dqHkZGc5vXXRM7nEPWaTtrhCCULbWh1CDsg51iyKhumQ3VKywsrumH wlVhIE3VkRZpUCZUvgsmn79fHDrfEJ/3sa/6cU2W5ButMJpMTvzNo843j7A9aeZk4XhY ZvezmYrZsMEBeHbZW+TtXIFF/ISh04fxWh4icHvjw/mh0eX/7fNfx+f3oBUvsk9W/vRL xaMK/YmmshwksEwriCgaNFB68w0Ty1CKhaQ6ppzKHdUmk9yyTfkIGsrNXt09SHAQWlbX ymRQ==
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=JXgXkYnDg6cEs7lUZW4Sw/p6c7IDj4UAQMY2TqtlOqE=; b=FldJoeAeVtqEokYDftXqbVnhsCZBRABllAMmrGC4oiBu8QuO0hVl5BfZe0yhnh8I4w QTj5bpOUSYUAU8VV44OHCJfOFkHY30eJzfggBlIMSsRklobm0wMTTc5jgSCzQ41uXQLG /TpwUTji+kOEE18S1IV3/fdMwxb/Jb5Knuxf9ck2afT1/FH9q20J3Fu/h+5YmP+PIQ2I yaYPE47uSvegHRaBcUgn8tT6pu5/oRhu8FyAfghWZoTkntu0XvHtdEoylK1U5JH6tBj0 h8vXTun54Z5gDdRWT5sD1AugEkBdMO5NST+v3XFLa/LRpUvghFHhzh/vydQAbYcEMH4H yfTg==
X-Gm-Message-State: AIkVDXISoUyR58xVeU8i/42tTQLxN4BnbLEgJzQQsuyEQHHrN7UNSG9S85/xm+rQA8eIaLRgleYS0mObBCP0Pw==
X-Received: by with SMTP id e142mr10837502itc.95.1486454159540; Mon, 06 Feb 2017 23:55:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Feb 2017 23:55:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Brian Dickson <>
Date: Mon, 06 Feb 2017 23:55:58 -0800
Message-ID: <>
To: Mark Andrews <>
Content-Type: multipart/alternative; boundary="001a113f6fde278e9b0547ec143a"
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 07:56:01 -0000

On Mon, Feb 6, 2017 at 11:27 PM, Mark Andrews <> wrote:

> In message <>, Brian
> Dickson writes:
> > The suggestion of DNAME to involves some subtle details,
> > which IMHO may in combination be the right mix here.
> >
> > The DNAME target is an insecure empty zone.
> >
> > This avoids the validation issue, and facilitates use of local "alt"
> > namespaces.
> No it doesn't.
> > The default response to queries under alt would be unsigned NXDOMAINs.
> No, it would be a secure response saying that foo.alt is covered
> by a DNAME.  The names under are unsigned NXDOMAINs.
> The difference between the two descriptions is critical to why a
> DNAME in the root zone will not work.  You *have* to leak names to
> the root to get a DNAME returned by ordinary processing because the
> DNAME is signed.
> > I am not seeing a problem with this.
> >
> > Am I missing anything?
> Yes.  A solution that *works*.
What are the specific requirements for the solution?

I am inferring that the following are needed:

The ability to have a local authority server for *.alt, where responses to
queries with DO=1 do not include any DNSSEC RRs, i.e. unsigned responses.

The ability to have validating forwarders configured to point to one or
more resolvers, where the resolvers are configured to use these alt
server(s) (directly or indirectly)

The ability of validating stub resolvers to accept the answers received
(not BOGUS).

Does the existence of query rewriting matter, as long as the end result
RDATA is the expected value?
I.e. If the query is "", returns a combo of "alt DNAME" plus " <RRTYPE> <RRDATA>",
is that acceptable, as long as there is no validation failure?

Whatever initiated the DNS call, via the stub, would get back <RRDATA>, and
presumably be unaware of the presence of the DNAME.

I just want to be sure what is or is not acceptable, and what is explicitly
within the requirements for a working solution.