Re: [DNSOP] Minimum viable ANAME

Tim Wicinski <> Wed, 03 October 2018 10:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 289CD131047 for <>; Wed, 3 Oct 2018 03:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 m_mO-l_YsG6m for <>; Wed, 3 Oct 2018 03:29:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D293F130F89 for <>; Wed, 3 Oct 2018 03:29:12 -0700 (PDT)
Received: by with SMTP id q4-v6so4570426iob.8 for <>; Wed, 03 Oct 2018 03:29:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LMtEZK4EOVGcFiDOGzNhDZKwM0+rkEcreto9o07/RHI=; b=AL8kA/YR7mErXmNwK+bSH6CbW9ah1O4uT8nfyvHYlK3A+wrWfbess03sz0HpoFx4ih wHoQNiot/+lxgh7QNAZRybTwL/48pub+Eqh6T9CcIhw1GjdPdRRzfJ6TsvQsSAJUXEyK kmlpkRoTNMCK4+KuFLcu7WDxNdgl0J/bOzEStZx3sWNWJHt93hruE2UoFSZ1dy7O/Ru6 /9z0Mywl5luuVBhgObaX0SGBwPSk4WmtS0qqNahZaxQ174eOjO4B9kDwdvI4Rqur8+Kc nS4YXJdVZ/QPqKQA/ib490nr5RHrGu+rtxvnyd7uomO22qmZB4vS/VgpxmllikXh7GeQ x3Cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LMtEZK4EOVGcFiDOGzNhDZKwM0+rkEcreto9o07/RHI=; b=agRjjAZ11lwje82W2rLENBK/VPjZ9BJhxNEmkKqi3Rj0zuv5BwBOOWN03c+jwW32lp MSLLRzWQaMsY0zDUTCNOb6B1nIfk6zip4ictrwMatf9SxVDGEY2F2ChdRWPz0QrNUHd6 pIeuckzNM9PVZVN+f2sbX12f7KHQgGkpBXmRqdBz6ozOIE1fibDiG3tyP7c59U/44aVq cikd8iTyNOgQR0T53Y7wBZlpE7DiKOakgeK8Q1PAZjdImA3jsOsO27Bx6FC9Mg/+VHZB Q3neTUw+Vpp9tst47F/HVg4ty7Bjq6v29+SldVDMWCNa7xjTZSmAGARVsyA41egf+WxA w0Sg==
X-Gm-Message-State: ABuFfohKUF7uOjSPVaPhJKc/Ie4gcmn6Kpv0XfvRIQPggcYXBdsjiUJV 5Twcwn6HhxSUyKXZ/9rMnQZzkqpzo6R/v56rcc8=
X-Google-Smtp-Source: ACcGV60/XvwVgeqlfF8b2kcmFFfVb1Cf0zQAlZDcolbCwaSJXACV4lSESUbl3eihTQJc6617EU99XgqYUYdzNrNbVcg=
X-Received: by 2002:a6b:4117:: with SMTP id n23-v6mr494748ioa.150.1538562552209; Wed, 03 Oct 2018 03:29:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tim Wicinski <>
Date: Wed, 3 Oct 2018 06:29:01 -0400
Message-ID: <>
Cc: Ray Bellis <>, dnsop <>
Content-Type: multipart/alternative; boundary="00000000000063a7950577508245"
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: Wed, 03 Oct 2018 10:29:15 -0000

To bring this dead horse back to life...

What I said in Montreal is SRV works great if you are a robot, but when
humans are involved it never ends well.

I do like where Mr. Finch is taking this discussion.

I also don't see the issue with online signing, but that is just me.


On Thu, Sep 27, 2018 at 7:27 AM Havard Eidnes <> wrote:

> >> 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".
> Regards,
> - Håvard
> _______________________________________________
> DNSOP mailing list