Re: [DNSOP] Minimum viable ANAME

Tony Finch <> Tue, 26 March 2019 20:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7554C120B66 for <>; Tue, 26 Mar 2019 13:54:10 -0700 (PDT)
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 uejLydhmeeuF for <>; Tue, 26 Mar 2019 13:54:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 030A31208C7 for <>; Tue, 26 Mar 2019 13:54:08 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 4A22B221CF; Tue, 26 Mar 2019 16:54:07 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Tue, 26 Mar 2019 16:54:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=QIVf29qA1lCz+d+K1cU/prrDqV6u7DJ0fsZqmWeMD Po=; b=GMrWTY1hNEJii9QavcMSY1L+cbC2VLDrmSysxE3T+cvcHoY9bBywpeByM AlfV06jkaQb0Mf5Svcl+YKUwuzJEbFGlzMPj8n3UxYn38JiQfprWZNSSlkRlOBmr AYy+6H27vL5Ql69Q2YmtCq9HNsG+Duji47XJ5VnwqYURUjYcGfpKGKNo1Hg9EU6g JE2i5zvt4qp9poIvUiWssUQZ7aRtPC5X3jvj5j7ViHun+ntHtxY8vES6xgafYDg6 QUj0CNxUc55atGWJZ4GwYUQoc65BONIJcKRKZ2woxwHet0TkTjlT/8FLJj9fYm9G MZ7HTghgex0LDf7xT2h+feDnWCKRw==
X-ME-Sender: <xms:bpGaXIUurtk1p-B-Fi8E6lBPJA50U3Y3CNX_twUYEsnkF2ok00g1FA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedtgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhofgjfffgkfhfvfesthhqmhdthhdtjeenucfhrhhomhepvfhonhih ucfhihhntghhuceoughothesughothgrthdrrghtqeenucffohhmrghinhepughothgrth drrghtpdgtrghnihhushgvrdgtohhmnecukfhppeduleehrddugeejrdefgedrvddutden ucfrrghrrghmpehmrghilhhfrhhomhepughothesughothgrthdrrghtnecuvehluhhsth gvrhfuihiivgeptd
X-ME-Proxy: <xmx:bpGaXGhtXU-oDMpqvHySwP4kt-wYWxamVFI6KIGlmv5odVaos23ghg> <xmx:bpGaXCsvHqVc1DzkgXx-8B5afjgnQ5vzN2Z4VpEg7R_hNXMq8wOgwg> <xmx:bpGaXN1NAfD0zqiDedfve2nWJU2S_t_ERHg17TRDVJKCwG3t5Zg1Qw> <xmx:b5GaXEoSiqc_Z2n-9C0fMeqlUx9CdkEE9efQ3hAwnh-aj96Yj6roIQ>
Received: from [] (unknown []) by (Postfix) with ESMTPA id 38629E4210; Tue, 26 Mar 2019 16:54:06 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Tony Finch <>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <>
Date: Tue, 26 Mar 2019 20:54:04 +0000
Cc: Olli Vanhoja <>, =?utf-8?Q?Vladim=C3=ADr_=C4=8Cun=C3=A1t?= <>, dnsop <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20180919201401.8E0C220051382A@ary.qy> <> <20180920061343.GA754@jurassic> <> <> <> <> <> <> <> <> <>
To: Brian Dickson <>
Archived-At: <>
Subject: Re: [DNSOP] Minimum viable ANAME
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Mar 2019 20:54:11 -0000

> On 26 Mar 2019, at 18:23, Brian Dickson <> wrote:
> The options are, new RRtypes that require resolver upgrades, or RRtypes that are handled by the client application (browser), which benefit from (but do not require) resolver upgrades.

The current draft is neither of those (and I think maybe you excluded it from your list because you don’t consider it viable, for good reasons, but...)

Whatever new thing we come up with, my view is that it will need sibling address records for backwards compatibility, otherwise no-one can deploy it. (Or at least, that new thing won’t make my job easier any time soon.) So there has to be some kind of provisioning or authoritative hack to make it easy to automatically add address records that have the same effect as the ANAME or HTTP record that they are supporting. (Remember, the existing non-standard alias stuff exists because it is easier than standard DNS.)

Ray Bellis thinks (quite reasonably) that there is a good chance that an HTTP specific record can be deployed fairly quickly, because browser upgrades are impressively fast these days. I’m less enthusiastic about telling DNS admins to look at before they decide whether to put in an HTTP record.

(On the gripping hand, based on the support queries I have answered, an HTTP302 record [an http redirect in the dns] would be a lot closer to what many webmasters expect!)

f.anthony.n.finch  <>