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

Erik Nygren <> Tue, 19 June 2018 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72C03130DEC for <>; Tue, 19 Jun 2018 08:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QbN208maHSpF for <>; Tue, 19 Jun 2018 08:58:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C056812777C for <>; Tue, 19 Jun 2018 08:58:48 -0700 (PDT)
Received: by with SMTP id u4-v6so1116395itg.0 for <>; Tue, 19 Jun 2018 08:58:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E7hozFomH3fDNjo6sOCP65uq+w0QrwD1q6625r9lIxU=; b=m7p3nRF3eJiO+hk7RYWh/rFcBekAV1cyElGeGU/u+zqTLEpnVYo932EIT4lrAkvwP9 OdSO+PPT7+9e2l+MlAinjnqTu0z6rPv9RlJXggO5TxzwZyI2/PHb0KdwC8uRBDi6p/bI qzX5uhWsxOCjOYYGrgs1sySnUqHH6LPqR2Y0teSr+08YrPgCyqrRn8S7CuRhRX7IgRtG uigfxxKxg5IxzxNCYqzGG0Kr65zSAiO9yLXUf+DnivFhWhEkQ/Pp6Gv055IZYJDe4Zbp OLQUitVjlwekLwZc/YvPeC84Z3M4KXFdXVsB2oAQ7FvzszDFtf+sjysotRcOKM9PLQeU nA3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=E7hozFomH3fDNjo6sOCP65uq+w0QrwD1q6625r9lIxU=; b=PooCWfYkZvd2vyqgDFaKuLvYhFfLarCBSjJ/Sk6lLZ1qkh6FTXTo4xxgsTgS3ASaO3 39Bfs+sc/s1cn2rdRaJURSyOu9Yh9f2ONgn25LKvyNlTD5N5OBphMo7Oz3T4mL2bgQTa Nwcp51F3GD+wM9NM+ZJRxykUTXXMXV97v6EwLqJGty7ABapWXOLE5apLXAARg/+xFbfY LpG/Gf+RmacqRR3QOAUS9VAfpMR2G04Et9h9Z3qdz03YT2Vva1EqeEY/NseXuvZb8gRF LIeH9xtNTQiG/Pn9umVUpefRdxueDNrmnDamTBXktXtbUqVREgy2waUUSz5wCVDCjjRq 4PZg==
X-Gm-Message-State: APt69E0ZVG1np1X/jxDFoGZBUzsb8lsWbNmssz3AMr08lu/1Wu/y55Z6 IE3pghc3H0lKQRnURmytzOXmzM1PbZsifzP++v2+2A==
X-Google-Smtp-Source: ADUXVKL/K3nqy7cv1f7jAPnOORDVcO+BQg8wsWzaoaT9L+uu+lWMVxFEKL7FvS9HUGywHM0CobaMEwrJ52wIiCqDZ9I=
X-Received: by 2002:a02:2e14:: with SMTP id i20-v6mr14337197jaa.104.1529423927896; Tue, 19 Jun 2018 08:58:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:d1cc:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 08:58:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Erik Nygren <>
Date: Tue, 19 Jun 2018 11:58:47 -0400
X-Google-Sender-Auth: MXjdIsMNr0ZLfYS58y6WuBDjO1g
Message-ID: <>
To: Ray Bellis <>, Ben Schwartz <>, Mike Bishop <>
Cc: dnsop WG <>
Content-Type: multipart/alternative; boundary="000000000000eef64f056f00c1ec"
Archived-At: <>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Jun 2018 15:58:51 -0000

On Tue, Jun 19, 2018 at 11:24 AM, Ray Bellis <> wrote:

> On 19/06/2018 15:43, tjw ietf wrote:
> > I find it personally appalling we can spend so many cycles injecting
> > dns into http but we can’t be bothered to fix what end users want.
> It's the HTTP folks that are putting most of those cycles into DNS into
> It's also their intransigence re: SRV which has caused the CNAME at the
> Apex issue.   CNAME was *never* the right answer for doing application
> level indirection in HTTP space.

SRV has enough limitations that the risk/reward for adding it into the DNS
lookup chain made it hard to swallow for many HTTP/browser folks.

The most recent proposal on this front for an ALTSVC DNS record:

adds value well beyond what SRV does and seems much more likely to
get interest/traction from browsers from discussions.

Although it is more annoying for users than just CNAME'ign the apex,
the ALTSVC DNS record would solve the problem for the HTTP case
where there's the most practival issues today.  The ALTSVC DNS record
approach also has minimal camel impact on the DNS side as it
doesn't require special handling by resolvers or authorities.

I think we should seriously consider seeing if we the ALTSVC DNS
record case covers enough of the use-cases of ANAME that we can
abandon ANAME and focus effort there instead?  Having multiple
mechanisms solutions to the same problem means we may not
get critical implementation mass on any of them.