Re: [DNSOP] Minimum viable ANAME

Brian Dickson <> Tue, 26 March 2019 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB59012087A for <>; Tue, 26 Mar 2019 11:23:20 -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 htP1mhlPfwvQ for <>; Tue, 26 Mar 2019 11:23:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F736120878 for <>; Tue, 26 Mar 2019 11:23:18 -0700 (PDT)
Received: by with SMTP id z76so8221638qkb.12 for <>; Tue, 26 Mar 2019 11:23:18 -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=G3w1Ultu4hqAyAywEd63PrU4Y6c4sEECl3cndxgEpY0=; b=Ew9nXi7Qta+/I0f8xkkyovZ3a+PbHlemYIiSLFG/JD0vH7O8MabSb0YKyzsvZXfub0 jgen4B/zs8v0eIKnyZ1dk5jfbTGLuqud+4ADa5vb3ZdmydMJnOWVP91XmRHLEHn5AO/F KDLpixHProVkYpyOWfbYaAxhGRdjvxNynYajUJfPdwFMCkOR8jxRg/+goRSs6nPufIpP L7y6j798/v7atjnr0a9fpzmCAJd1ROTyh20RDWgQHVy+iEDBZtnoxvFGfQ1XE9QYr+pb rgnrjx0sv4L8tWMdJL2M09v6SfJ0/cYgBQXs25H+kXybyrWzDEuPW51DTe+cfILW3jAw GfGQ==
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=G3w1Ultu4hqAyAywEd63PrU4Y6c4sEECl3cndxgEpY0=; b=K5myEBwOTwHbr85GvgZZ/q5+8J5ck3pqErdZRJ3/gxXw8wL1OAsOAxjsCIDDMRW8Ui ZHHC8j8jOTmHNgwuIOprjMt5KOLweuqiwIfi77qWUvbyZ5kthcsReZDim0+VPUZ4o6VW Wf7SRFZwoN2aKmcHcTFPyypCaKeAXqAIDfpwt9qY23u0nzVixj8HbWK5oLyuazkdXTYg /6Uh6nNZmkpOs3/nKvzuMVpiGaYZR+Qq/AqrWHzMKEh6qifNHx/9X4dSndmcWu5tHzRg Psx2mrejZtaYmS90XJQ7AjT5tx8Op2sVmZA+7T8pD+I2q4mBMvhp2+NWSKODQp0O+ih/ BA/A==
X-Gm-Message-State: APjAAAWZwz6gwhfpJN/y+UDQL1vhHjGLytoftlHOdju/MePvqou9t/kP Az/9ehP8zdfbagEvkzxmijV+DF7wTK+7OJLR9oU=
X-Google-Smtp-Source: APXvYqxpA5rhDdiPtSFnpzxCREdeKRCk/F2chXkWfOuucHSoqEHZf3vwW8+lVyVCRN25MKUrXCyE5Lb4+2u5on5VgO4=
X-Received: by 2002:a37:d85:: with SMTP id 127mr25186405qkn.139.1553624597669; Tue, 26 Mar 2019 11:23:17 -0700 (PDT)
MIME-Version: 1.0
References: <20180919201401.8E0C220051382A@ary.qy> <> <20180920061343.GA754@jurassic> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Tue, 26 Mar 2019 19:23:06 +0100
Message-ID: <>
To: Olli Vanhoja <>
Cc: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <>, Tony Finch <>, dnsop <>
Content-Type: multipart/alternative; boundary="000000000000422c970585036a2f"
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: Tue, 26 Mar 2019 18:23:21 -0000

On Tue, Mar 26, 2019 at 6:02 PM Olli Vanhoja <> wrote:

> On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát <>
> wrote:
> >
> > I'm not convinced that the resolver parts will be important, regardless
> of what exact mechanism will be chosen.  My reasoning is that you can't
> rely on any changes there being widely deployed soon, and there might not
> be enough incentive to implement and deploy.  On the authoritative side, on
> the other hand, it's enough to just get support on all servers *you* use,
> and the incentives seem much stronger, too.
> >
> > --Vladimir
> I think it's totally wrong to *choose* here what we think is the best
> method to solve the issue. Note that ANAME/ALIAS/whatever is already
> widely deployed on the authoritative side i.e. DNS providers like AWS,
> PointDNS, DNSMadeEasy, Constellix, Cloudflare (on enterprise plans),
> and probably many others.

The problem with this assessment, is that those providers are *not* DNS
They are providers of incompatible, vertically integrated walled gardens.

As far as I understand it, even most of those providers would prefer a
standardized solution.

There are a number of problems around the current solutions, including
lock-in, inability to go multi-provider (on DNS), scalability, and a bunch
of other things.

Doing anything that looks and feels like taking any/all of their solutions,
putting them in an opaque box, wrapping it up, and putting a bow on it,
does nothing to address those issues.
That activity may be many things, but it is not the design of standards, it
is not interoperability, and it most certainly is not "DNS operations".

So, I have to say specifically, "I beg to differ."

We need to start with the base requirements, which is, "I want an apex RR
that allows HTTP browser indirection just as if there was a CNAME there".
Sibling records do not behave like CNAMEs, no matter what extra hacks get
applied; CNAME processing is done by the resolver.
The options are, new RRtypes that require resolver upgrades, or RRtypes
that are handled by the client application (browser), which benefit from
(but do not require) resolver upgrades.

(The above is the "Cliff Notes" version. If you want the long version, go
back in your email or on the WG mailing list archives, and look at the
thread from November of last year.)

BTW, I am happy to actually work on future drafts on this stuff, and even
to contribute code for PoC work. My coding is probably not quite up to
snuff for full implementation, but PoC, sure.