Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

Andrew Sullivan <> Tue, 18 July 2017 14:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 662A81286B2 for <>; Tue, 18 Jul 2017 07:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=GfkV+Q6Q; dkim=pass (1024-bit key) header.b=jpxmc6Eb
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2TrGTLgE264q for <>; Tue, 18 Jul 2017 07:13:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A58A112706D for <>; Tue, 18 Jul 2017 07:13:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4620BD996 for <>; Tue, 18 Jul 2017 14:13:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1500387208; bh=Rnfbyiqn4r10hja/ZLLuG/jjC50bRIYqxGOPwnfiUwU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GfkV+Q6QrA5A0QnPMMbcclEMec1lEV4h3jLKCbC/ubzkjOgpOnk3XC4m69UtGUhT5 NnCZZHgQt46yA65hEdsc0iB9oV0xu+rORzEnUfMuzgljiBRTsHuI23zUEITxgAFSE7 tandLjPtm8omR8YVhcZoJZchIUepaxBJ7+SFlpkM=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kghadL9VTC-S for <>; Tue, 18 Jul 2017 14:13:27 +0000 (UTC)
Date: Tue, 18 Jul 2017 10:13:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1500387207; bh=Rnfbyiqn4r10hja/ZLLuG/jjC50bRIYqxGOPwnfiUwU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=jpxmc6EbEJosfP/C0Ef8t81xZKXGMvSpiCsScNOoMLYRJBb0BfzdwXjC+byb8Ig1L TbFwStgnOr4sqn05dT1tRJ224zBwzYrsuxkfhwiVE1xYMu+ffoaM8i+WWGZYiFZlQb Onm1bfsUL9/aZ6B2uTqMuzEDfMbkLBw8a+Hz70Yk=
From: Andrew Sullivan <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jul 2017 14:14:01 -0000

Dear colleagues,

I managed to delete instead of sending my note on this topic earlier
today, and my brain is sufficiently soft that I couldn't just re-type
it out.  Nevertheless,

On Tue, Jul 18, 2017 at 03:19:44PM +0200, Willem Toorop wrote:
> I support trying to come up with a standards solution for alias names at
> the apex.  But....

I agree with this, and

> The dependency on online signing is a little more then just a technical
> issue.

also this.  

> Currently all DNS Resource Records support the "offline" domain-name
> holder signed zones mode of DNSSEC.  There is another provisioning
> oriented resource record: DNAME.  For DNAME, it is described how
> validators can verify that the followed referral matches. The same thing
> should be done for ANAME.

The problem is that DNAME has another feature that ANAME (and other
things like BNAME) can't: RFC 6672 gives the reasons why all
validators must also be able to cope with DNAME.  This was a fact (or
maybe accident) of history.  It is just not true of ANAME, and that
means that much of section 3 of the I-D is far too weak.  It needs to
say that, if you can't sign online, then you will break DNSSEC.

It is very strange for us to suggest this, but I think there are only
two options: either DNSSEC means we can never do any more aliasing, or
else we have to accept that some kinds of innovation in the DNS is
going to break DNSSEC sometimes, and allow zone operators to decide
whether they want to break validation (and therefore lose the
connections) or whether they want to serve everyone.

Alternatively, of course, we can follow the multiple-algorithm
approach that others have suggested.  This has the disadvantage of
bloating the DNSKEY RRset for anyone who wants to use these features,
of course, so it is also not free.

I'm also slightly concerned about this at the end of 3.3:

   The type bit map SHOULD only include address types which are known
   to exist at the <target>

Is the advice really to ask for both and then incorporate what is
known?  That seems maybe safer advice.

I also wonder whether the document would be easier to understand if it
were broken up into smaller chunks dealing separately with the
authorities, intermediates, and stubs.  It could be that nobody else
find these items too tangled in the current I-D, but if others do I
can propose text.


Andrew Sullivan