Re: [DNSOP] Fundamental ANAME problems

Joe Abley <jabley@hopcount.ca> Mon, 05 November 2018 11:56 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE79128CFD for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 03:56:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwaCGmuFRyNx for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 03:56:02 -0800 (PST)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96251277CC for <dnsop@ietf.org>; Mon, 5 Nov 2018 03:56:02 -0800 (PST)
Received: by mail-pl1-x62a.google.com with SMTP id q19-v6so1367468pll.7 for <dnsop@ietf.org>; Mon, 05 Nov 2018 03:56:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TE2DfinvACDaiKVOkvBOqhYa8vl9Hjw10eH9sro/As0=; b=d7DSEVV90RO9wDlgGc1Qmc2MaK8ce8B+ox2zLNHdftxgHlJTutCS/ZkrhKYBwameag 2qo2Iec5MlPAcUE+mBX7GlRa9d51P45TxXpnFzHdACnov+ia4lXA9PKU5t3eI7i4G4mq DW1LM9RoBoJNNPCaEXzsxXJ5V3YHayFYBhsWw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TE2DfinvACDaiKVOkvBOqhYa8vl9Hjw10eH9sro/As0=; b=WzN80EyEKGpUXbmjuW+cPqK/70TZJ2wdnoZi5VhsSn6BNaxkaoC5X8Y9KhqpI9KNOk Ak9VEYQigdpwcDih9LWLQATsT3/9aP9ZH7PXLXtUrZep/uYlXYlrfTiZP+jrBfBjXKiQ ntk3ZkmUXiV9MXKhGkDSENLFtksTy2jR652as3CKQzD56+JhKtsVnl/2Ok9iAP8aQRhu 9a0IipjWYa1K3ZqahEo8mDjRz0DR8M8P7JQEE/arlSWeRUbLDgnf0jvBMhwpsfE6PfS9 PQ/QBO01G3xW9vC9e3Hy9+sKqyozpP6fe1ZfG3PVLBjlwZgvsgqoTiGTK5EO4Z7HOqUb /61A==
X-Gm-Message-State: AGRZ1gL9yIOAZCHKIJr+as9PszBcnfLJrFgXDYuVeaEwkrld+SSJpzdq C+wjdaOl+tNEfvoVioOxbA7ip59hS0M=
X-Google-Smtp-Source: AJdET5eEdGIKQUMQHrwMqq39py85fLuiZP0kF2JlOftGq/c7SGA8Qj2NjKyiu3NeHyLLj1cIj2QrQA==
X-Received: by 2002:a17:902:e28a:: with SMTP id cf10-v6mr22265284plb.81.1541418962012; Mon, 05 Nov 2018 03:56:02 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:5541:24be:b3e9:c10? ([2001:67c:1232:144:5541:24be:b3e9:c10]) by smtp.gmail.com with ESMTPSA id h70-v6sm13360122pfe.65.2018.11.05.03.56.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 03:56:00 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Joe Abley <jabley@hopcount.ca>
X-Mailer: iPad Mail (16B92)
In-Reply-To: <20181105083526.GA12204@besserwisser.org>
Date: Mon, 05 Nov 2018 18:55:58 +0700
Cc: Tony Finch <dot@dotat.at>, "dnsop@ietf.org WG" <dnsop@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7704C350-256A-42E3-B718-38FD449A2ADE@hopcount.ca>
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com> <alpine.DEB.2.20.1811021543210.24450@grey.csi.cam.ac.uk> <20181105083526.GA12204@besserwisser.org>
To: Måns Nilsson <mansaxel@besserwisser.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2bnJdKXjhUAg4AIYW3IHNRDFQEE>
Subject: Re: [DNSOP] Fundamental ANAME problems
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 11:56:06 -0000

On Nov 5, 2018, at 15:35, Måns Nilsson <mansaxel@besserwisser.org> wrote:

>> I think a resolver-side or client-side alternative (like the various
>> web-specific record types we have been discussing) is defintely soemthing
>> we should aim for in the long term, but that isn't what this work is
>> about.
> 
> IMNSHO _any_ work on "fixing CNAMES at apex" that gets traction is 
> a spanner in the works for what we seem to agree is a better solution.
> A interim fix will be deployed and stall every attempt at DTRT.

I think you are both right.

First, pragmatically speaking, there is clearly demand for something that can do "CNAME at apex". DNS companies sell it, people buy it. It already exists, but in as many flavours as there are providers that support it, so interop is difficult. Having multiple providers is good; interop makes that easier. Maybe there's work that the IETF could do here, but I would suggest that a solution that nobody implements is not much use. A reasonable starting point would be to survey the existing implementations and ideally get the enterprise DNS providers responsible to join in.

Second, what is the longer-term solution that seems least likely to cause painful intestinal cramping and bleeding eyes? I agree that if we want a clean answer we should be looking at the clients, not the authority servers. We have application-specific records like this for mail; I think we can confidently call MX a good solution for that problem. We decided that creating an unbounded set of application-specific RRTYPEs for this (each with their own semantics, each implemented separately) was idiotic, and and hence SRV. Let's not abandon that thinking unless we really have to.

Various people have expressed dubious arguments against the use of SRV for this. I don't think the answer to that is to create something functionally identical with a different name and somehow expect to be able to trick people with sleight of hand. I think the answer is to document the use-cases and dispassionately assess each of the arguments and work out whether they are real. My suspicion is that for a significant proportion of the problem space SRV is quite sufficient, and that in pragmatic terms we're really only talking about something like three client-side codebases that would need to implement it before we could call it universally-deployed.

But I could be wrong and maybe there really is a convincing reason to design something HTTP-specific. Either way, I think we need to show our working here, and by "we" I mean web people and DNS people who are prepared to work together.

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

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

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


Joe