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

Tony Finch <> Wed, 31 January 2018 04:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A30C512EAA8 for <>; Tue, 30 Jan 2018 20:35:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 7_bzwxF6yqmS for <>; Tue, 30 Jan 2018 20:35:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4B5213151A for <>; Tue, 30 Jan 2018 20:35:41 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 2715420B49; Tue, 30 Jan 2018 23:35:41 -0500 (EST)
Received: from frontend1 ([]) by compute4.internal (MEProxy); Tue, 30 Jan 2018 23:35:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=HtYJ9e rsgc8vBVDnHPjmIdtxaeuTrBICYqe6yBfKsds=; b=jU6vHdlkcJo3zlfJIZke75 4fgfpQAFGSoM96+QKgbwoA6nb7/uryr/U6sYwtysCq8t8ps0y3JtvrGQ2Uwd+2dm 3Ntz6RA6SGyZqTSJJoF0oIWWPWzW3XC9kmfOFb2EmQ5u9R7in2q3eFozRBgiiFc4 RvFf5YyG5xi227NZA/7i67oeX2lYS33TUTRivPhKhFkYRAPKcpbNodNXv6Qb0XUz ExqQA8/GplDozqeXofrDzqGDXt2LRxuTRDsM7m2me8Ow1GPQRS1UgihN8ig5qhzd VguOC4ZQ3GplcNsCelvsQumhrybNvikdBjmyaFwTmNalmyghDHct6eunrtEureAw ==
X-ME-Sender: <xms:nUdxWonEbQ6i6gtFMc3ScgPg-8842bCjGqnvbFcVar8Z4KxRx2vn3g>
Received: from [] (unknown []) by (Postfix) with ESMTPA id CC3DA7E17D; Tue, 30 Jan 2018 23:35:40 -0500 (EST)
From: Tony Finch <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Wed, 31 Jan 2018 04:35:38 +0000
Message-Id: <>
References: <> <>
In-Reply-To: <>
X-Mailer: iPhone Mail (15C202)
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.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: Wed, 31 Jan 2018 04:35:46 -0000

I realised that the primary/secondary split I talked about in my previous message turned out to be the wrong idea. There were lots of complicating issues that made it clear that auth server ANAME behaviour does not cleanly follow the traditional primary/secondary split.

Instead I think the split should be between active ANAMEs, where an auth server fetches address records from the target, and passive ANAMEs, where the server just uses the addresses it got from the master file or zone transfer etc.

A server can be active if it has the private signing keys or if the zone is unsigned. It has to be passive if the zone is signed and it lacks keys. It doesn’t matter how the zone contents are provided to the server.

I still think it would be helpful to have separate sections in the spec for active and passive auth servers.

This active/passive split could also be extended to recursive servers, tho the logic is a bit different. (See previous message for details.) I don’t know whether or not it makes sense to have auth servers be similarly sensitive to DO and CD.

f.anthony.n.finch  <>