Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Warren Kumari <warren@kumari.net> Fri, 22 June 2018 19:03 UTC

Return-Path: <warren@kumari.net>
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 3EE31130ECE for <dnsop@ietfa.amsl.com>; Fri, 22 Jun 2018 12:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 MTT8Yx6dk_bW for <dnsop@ietfa.amsl.com>; Fri, 22 Jun 2018 12:03:14 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 3B196130EC0 for <dnsop@ietf.org>; Fri, 22 Jun 2018 12:03:14 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id h10-v6so7633011wrq.8 for <dnsop@ietf.org>; Fri, 22 Jun 2018 12:03:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1uZrrq9pO7mNu1AQfwZdKLH7iWSSFvYLlX5rrvgGkzI=; b=QjVeks4audmtBrv7g2kWXtBvxebEQTEjFpZKk0qXfc2FzPt4VcjqD/NM3+zfzlh7Ok GrpjCIHdz+uDzlRL+aNxd9VgEV70kHRf2f74xRNJroZIzG7MdwaDkxRVqeCFjw2pA+VY V2YGJKKTokk7xEsD8VwF3cPNbiLJPDemEKIOTEApfYF/VuOSjQQU1/TUZmgRKD4h29EO GwyAduzak0l4cNCDeCuZ62/eAC4/KR2iR+OrmACOwUIjKa3DoSYRSfJo7c5TWoacbuIx juteIO0AVrw4tgtiKCLb+7Ojmu/NhJ6q/jWvYJBPdKeBsBy75OgTmSFCVuTxcIRRcDOE W13w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1uZrrq9pO7mNu1AQfwZdKLH7iWSSFvYLlX5rrvgGkzI=; b=Y0XnKB2ECnKePaPkztOCMHQ5ljYh6xIhuiP/h9kplxzCBmDIXx1PBJuapwgbBY1YvH kTUoNqLExATyEa/+avgBe/EVk2doRghaZGjBhKTJrPcb2SXlecPzWnxnRzhqEWH3XDML iBXbWXV7e9mIMAO7OchkjuKzuu/R7ZWW7gfZvPStqgBiXZrIblGsIZMWAqUCMpBZhrUQ bLHzgdXfqufBO5lIDBz6gpv/fRtGfJr5NKj+eFivUXgt9bWw7AokQH8ElOsk5k03pNDj FJ62sc37xfXSYTH67/+oH+aUc5qJ6J6/Mi1uH1pii2XKiHRWQomsRXyr9fYvyeuHHRbx a17A==
X-Gm-Message-State: APt69E1QrRM8ubukqX9D6SONlIo9026gEe9rLXpcqDMdyLy1pjFCecnB cuGcWNG/ZR4GUe/RAZeZ/iA05WeFZPQGOSwydYt7IyJDRmc=
X-Google-Smtp-Source: AAOMgpeFGBkHIH15r3bwcTevWJSNMSeOK+k4rVDaSr++jVNfG8o/ImmEOnPpz//2nYysjGAC2t+Duy8YUGzFjMJeWUc=
X-Received: by 2002:a5d:4843:: with SMTP id n3-v6mr2514367wrs.24.1529694192392; Fri, 22 Jun 2018 12:03:12 -0700 (PDT)
MIME-Version: 1.0
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk> <691FC45D-E5B6-4131-95BF-878520351F3A@gmail.com> <bf0ba568-1a18-f8cf-c1a0-3f547d642a78@bellis.me.uk> <0438207E-A4C2-434D-9507-9D9F54765CFB@puck.nether.net> <alpine.DEB.2.11.1806191649350.916@grey.csi.cam.ac.uk> <9a0d1bae-dc58-99b5-40d1-caa7737dbfb1@bellis.me.uk> <1B7B2BB4-F0AE-4188-B89B-DF032BE7A237@automagic.org>
In-Reply-To: <1B7B2BB4-F0AE-4188-B89B-DF032BE7A237@automagic.org>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 22 Jun 2018 15:02:35 -0400
Message-ID: <CAHw9_iKWhRjK6yzSSWVsCBqjdVfTnzVkUh8PMYC5nwQUb_=yvw@mail.gmail.com>
To: jabley@automagic.org
Cc: Ray Bellis <ray@bellis.me.uk>, Tony Finch <dot@dotat.at>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f3f4ff056f3faebc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8guCdn5LKPhkpqLM3AI2DUjb_Yw>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 22 Jun 2018 19:03:18 -0000

On Fri, Jun 22, 2018 at 8:57 AM Joe Abley <jabley@automagic.org>; wrote:

> On 19 Jun 2018, at 17:03, Ray Bellis <ray@bellis.me.uk>; wrote:
>
> > On 19/06/2018 17:44, Tony Finch wrote:
> >
> >> SRV should have been part of the fix (and it was invented early
> >> enough to be!) but it wasn't a complete fix without support from the
> >> application protocols.
> >
> > AIUI, a large part of the supposed issue with SRV was the inertia of the
> > installed base of browsers that wouldn't know how to access them.
> >
> > Ironically the proposed fix seems to require upgrades to the
> > installed base of one of the most important network infrastructure
> > services on the planet.
> >
> > Meanwhile, a very large portion of the installed base of web browsers
> > gets automatically and silently upgraded every month or so...
>
> I think so long as there's a fallback for clients that don't yet have SRV
> implemented (e.g. publish A/AAAA RRSets at the same owner name as the SRV
> RRSet, and specify the behaviour by SRV-compliant servers in the event that
> both are present) this is not a plausible engineering argument.
>
> Processing an SRV might require additional DNS lookups to get name -> SRV
> -> SRV target -> address, but that's a one-time hit per TTL and I think
> it's a stretch to paint that as definitely a problem. Modelling is required
> and worst cases remain to be understood.
>

​It certainly is the ​case that a number of browser / large web properties
have stated that an additional DNS lookup is a price that they are not
willing to pay, especially for something not "critical".

I believe that this also would require firing off simultaneous lookups for
SRV along with the A and AAAA (or, even worse, firing off a SRV, waiting
for the "nooerror" error and *then* trying for the A / AAAA) and waiting
for the long tail before you even know of you need to resolve the target.

The DNS lookup from my house (behind Comcast, in NoVa, using 8.8.8.8) for
SRV www.afilias.com was Query time: 125 msec.

That is probably not a fair test - there is no SRV for www.afailias.com and
so it wouldn't be cached, but just querying for A www.afilias.com gives
me ;; Query time: 62 msec. This is from a relatively well connected
residential network, and is noticeably worse in many other places in the
world.

Anyway, adding ~60ms is definitely something that many will say is a
problem, especially because all of this falls into the "before first byte"
bucket, and so the user cannot be distracted with progressive rendering,
etc.

I'd note that things like
https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05 (and
similar) would allow you to bundle the SRV and the target of the SRV so
that you *could* do this in one DNS transaction...



>
> If there are definitive problems it would be good to hear what they are.
> It has always sounded to me like the problem is "this is not how we did
> things before". Perhaps the cost of change is not actually in the client,
> but in the provisioning/client education/product packaging across all web
> and hosting services?
>

​I think that the problem boils down to:
A: a chicken and egg issue and
B: extreme sensitivity to latency, especially "avoidable" latency.

W


>
>
> Joe
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf