Re: [DNSOP] Minimum viable ANAME

Olli Vanhoja <> Tue, 26 March 2019 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7ADF9120B55 for <>; Tue, 26 Mar 2019 13:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, 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 u6HmH2EBXwJ3 for <>; Tue, 26 Mar 2019 13:46:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C92A3120A0A for <>; Tue, 26 Mar 2019 13:46:53 -0700 (PDT)
Received: by with SMTP id 10so9721810lfr.8 for <>; Tue, 26 Mar 2019 13:46:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uKth4wgCQgTNpyi9kxYGanCLpe+AcoUHWcWw0TAZy2U=; b=sGT32kGuS4DY0p5rD4d5X3Rdvaum0ygMkZfqsUKkby93K/RzQIhwQ0hUBvaUtqXRel zpbNUD4kKA0FA0oKuktp/xm1GVi38f+euErMeQNkVmzDTRI2G2JdDyzS7DmS+EBqnlYv 4BhtSFbrRIBHNuBcOCjWs+jTEV0N64RKFfo+puVWA9asFMN3GxBkCDwWN156pzJPlF4n VC5uq+Z2ehsEMYCpG8585sKcvnNJWh3Oi4QLv6VAuk6OAi44Ks00oR5XZU68HcMh04YM nIPVPM7OJthdg3ki/xVmYqc8Q6whxw0hthY8RycLz4EMZqky3bc4vI7DlpxA6Ye64UsL G1JQ==
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=uKth4wgCQgTNpyi9kxYGanCLpe+AcoUHWcWw0TAZy2U=; b=tA6tJ7cz7WpJ585xlvMrz99whPp9KUw7qevR28vSHdZvHROUvdMl4L2Hhm/e25kAwY 72xYwXKyfTxSwcZ2hkhconQ6wWiOvhf2KmNUFiWyZ7VNuY4wbYsuM+19Ah63mYWZ3lVp foec7nWjuz6RfqGVkyCLFDnd4dAhKbyxxKCbu9EiIK3+4Cy87A+2maiFlClbIIzJgHHz 9SCeqHwN2Wq2+JlItepdP0SzOMbaT/JiwYQy+S9OSB4VRd/9thbjFt6IcEWflPiDxDLI sEBePiC9na9w4meYxgRXI/GbvtyPNbCsJ67Oj+hvvB56adj0Hw2qK/Dz1WlkiqjmRLEd WB4w==
X-Gm-Message-State: APjAAAXjupYYnN4Nqm7H/a5SxcALNatwTFSlJHjtYoH44/jzeLuOoZkj jx0wVPdFbI+qe+AiWc+mxnPXV0KHUwNmr1JTUzoiaw==
X-Google-Smtp-Source: APXvYqxg6dmBKMbpNfXIOpGgqIr6HrBZv2wepCSWxpK45+2rCeFTvsLNidhvuLPbsm5i+SiEhSbKFtEjzzsOglE17yw=
X-Received: by 2002:ac2:4115:: with SMTP id b21mr17669873lfi.54.1553633211913; Tue, 26 Mar 2019 13:46:51 -0700 (PDT)
MIME-Version: 1.0
References: <20180919201401.8E0C220051382A@ary.qy> <> <20180920061343.GA754@jurassic> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Olli Vanhoja <>
Date: Tue, 26 Mar 2019 21:46:40 +0100
Message-ID: <>
To: Brian Dickson <>
Cc: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <>, Tony Finch <>, dnsop <>
Content-Type: text/plain; charset="UTF-8"
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 20:46:56 -0000

On Tue, Mar 26, 2019 at 9:20 PM Brian Dickson
<> wrote:
> On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja <> wrote:
>> On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson
>> > 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.
>> >
>> I see a huge problem there, let's call it IPv6 problem. During the
>> transition phase to this new RR we need to have a fallback, right? How
>> long do we need to have that fallback for old resolvers and browsers?
> I don't follow you.
> I'm advocating the latter of the two options, because it does not require resolver upgrades.
> Thus, the "old resolvers" is a moot issue, as they would continue to be compatible with the new types.
> The only expectation is that new resolvers would be more efficient, thus the incentive (not requirement) is for the resolver operators. Or not, if they don't particularly care.
> I also don't follow the "transition phase" logic, either.

Perhaps I misunderstood you. That's exactly what I'm hoping for,
compatibility with the old resolvers.

> I'm not sure how you see this involving DoH; it is an issue orthogonal to the transport or the choice of recursive.

I mean, if there is something new that the client side needs to do to
get an IP address for a domain, then it could be implemented on a DoH
server. Though maybe in that case the client is updated already. Maybe
it would happen at an ISP instead over traditional DNS.

> An upgraded browser (which understands the new RRtype) would be able to resolve the new type using an old resolver.
> Resolvers do not require upgrades to serve new types, as long as the new types don't require special handling.
> These new types would not require special handling by the resolver, but rather would have the special handling done by the browser.
> (That's kind of the whole point - eliminate the need for resolver upgrades.)

Well that's my point, if you need to do something new on the client
side, is it a resolver change or a browser change, it will make it
much slower transition. Would a big multinational company change to
this new way of resolving an IP address (and stop serving A records on
selected names) any time soon and risking losing possible customers?
The fallback here would be to just somehow serve a normal A record
that a client already understands.