Re: [DNSOP] Fundamental ANAME problems

Paul Ebersman <> Mon, 05 November 2018 16:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B36F130E0C for <>; Mon, 5 Nov 2018 08:21:48 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L7JMu7yZbNPS for <>; Mon, 5 Nov 2018 08:21:47 -0800 (PST)
Received: from ( [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DF5B130DD4 for <>; Mon, 5 Nov 2018 08:21:47 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id B2B6C3740178; Mon, 5 Nov 2018 08:21:46 -0800 (PST)
Received: by (Postfix, from userid 501) id 096F3D3B74E; Mon, 5 Nov 2018 09:21:46 -0700 (MST)
Received: from fafnir.local (localhost []) by (Postfix) with ESMTP id 02F81D3B74D; Mon, 5 Nov 2018 09:21:45 -0700 (MST)
From: Paul Ebersman <>
To: Joe Abley <>
In-reply-to: <>
References: <> <> <> <>
Comments: In-reply-to Joe Abley <> message dated "Mon, 05 Nov 2018 18:55:58 +0700."
X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21817.1541434905.1@fafnir.local>
Date: Mon, 05 Nov 2018 09:21:45 -0700
Message-Id: <>
Archived-At: <>
Subject: Re: [DNSOP] Fundamental ANAME problems
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: Mon, 05 Nov 2018 16:21:48 -0000

mansaxel> IMNSHO _any_ work on "fixing CNAMES at apex" that gets
mansaxel> traction is a spanner in the works for what we seem to agree
mansaxel> is a better solution. A interim fix will be deployed and stall
mansaxel> every attempt at DTRT.

While I agree with this approach in principle, the reality is we've had
a couple of decades and never come up with anything enough better to get

There are times when an 80% solution is better with 0%, even if it might
slow down perfect.

jabley> So for what it's worth, this is what I think we should be doing:

jabley> 1. Make the existing, proprietary, non-interoperable dumpster
jabley>    fire better if we can (maybe we can't; the way to tell is
jabley>    whether the enterprise DNS people are interested);

Yes. And get buyoff from the browser and large auth folks so it actually
gets used.

jabley> 2. Find a client-side solution to this, and try really hard not
jabley>    to invent something new that is really just SRV with a hat
jabley>    and a false moustache.

Also yes. Folks saying that SRV won't work for them aren't stupid. They
have their own agendas that don't consider DNS to be the most important
thing to them; to them it's a handy tool. We should respect that
attitude and come up with a legit new solution both sides can live with.