Re: [DNSOP] Minimum viable ANAME

Havard Eidnes <> Thu, 27 September 2018 11:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BB61130E4D for <>; Thu, 27 Sep 2018 04:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cr6zmu0_qVle for <>; Thu, 27 Sep 2018 04:27:29 -0700 (PDT)
Received: from ( [IPv6:2001:700:1:0:eeb1:d7ff:fe59:fbaa]) by (Postfix) with ESMTP id 3CC89130E5D for <>; Thu, 27 Sep 2018 04:27:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C15EE43EA54; Thu, 27 Sep 2018 13:27:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=he201803; t=1538047646; bh=ydG+C3wtxb6Smyw3+xmqXVtUXsEKXHOPQWHgwlj8Qxg=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=na7DxTdC1QSF0t+vCrJHVqCrWtNYN5aZsyW/2Qq1PVdORlFMgvldD8eeST9MZXEWZ bIgQCvzBSD46EzWaNqe3pui9Ln5IVUw3lFSnPtgion6rHvw5In/vV4BRHpaJICfunK EfQnGV20UqKuUI9TvfZBCxXgPihYcVCa0LsDiypk=
Date: Thu, 27 Sep 2018 13:27:26 +0200 (CEST)
Message-Id: <>
From: Havard Eidnes <>
In-Reply-To: <>
References: <> <>
X-Mailer: Mew version 6.8 on Emacs 26.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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: Thu, 27 Sep 2018 11:27:32 -0000

>> I also feel from this discussion, we are all roughly on the same
>> page.  We want SRV as the long term solution ...
> except that we heard at the side meeting in Montreal (albeit from
> browser people rather than content people) that they *don't* want
> SRV, because it has fields that are not compatible with the web
> security model.

Can you summarize the particulars of the web security model (I'm not
sufficiently well versed in that area to immediately key off that
phrase) which makes use of SRV non-attractive?  Is the aspect that a
URL can contain a port number part of the problem, or is it
something (a lot?) more involved?

When defining the use of SRV for the web protocols (something which
remains to be done), one could of course standardize "ignore the
port number in the SRV record, use the port number from the URL, or
whatever http and https defaults to", especially if that makes the
problem go away.

> I still want to define a new RR that does have mutually agreed
> semantics that's specifically for use by HTTP(s), but so far no
> takers.

SRV is widely supported today in provisioning frontends, name
servers and resolvers.  Defining a new RR which is SRV-like is going
to seriously prolong the "time to useful deployment".


- Håvard