Re: [DNSOP] Minimum viable ANAME

Olli Vanhoja <olli@zeit.co> Tue, 26 March 2019 20:46 UTC

Return-Path: <olli@zeit.co>
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 7ADF9120B55 for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 13:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zeit-co.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 u6HmH2EBXwJ3 for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 13:46:54 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 C92A3120A0A for <dnsop@ietf.org>; Tue, 26 Mar 2019 13:46:53 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id 10so9721810lfr.8 for <dnsop@ietf.org>; Tue, 26 Mar 2019 13:46:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zeit-co.20150623.gappssmtp.com; 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; d=1e100.net; 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> <08C8A740-D09B-4577-AF2A-79225EDB526B@dotat.at> <20180920061343.GA754@jurassic> <E944887D-51ED-41A0-AC5A-3076743620D8@isoc.org> <acef1f69-8e4f-52cc-dca5-3ada9446e0ee@bellis.me.uk> <CABrJZ5HmCoSsGe2L-JkAsPywhcxyyVkvMmXCvQyJMjWHnMeT_w@mail.gmail.com> <alpine.DEB.2.20.1903261521290.13313@grey.csi.cam.ac.uk> <104ec4ea-296f-1657-5633-f6c1f2684274@pletterpet.nl> <alpine.DEB.2.20.1903261540330.13313@grey.csi.cam.ac.uk> <ec8e6848-c962-56b4-50d5-a7bd4b6d48e6@nic.cz> <CABrJZ5H=Ltora2m6_Gyk=O6+UqT-F704hvoKt5=U-TY7fx8JqA@mail.gmail.com> <CAH1iCioQh_dN=cY42p=Y+kPijEiHHt-oGrwpS=8GAyjy+=xUcg@mail.gmail.com> <CABrJZ5FPeP5NQ5qRyOw9BhrB6k+6hUvj32DAcjZBgTryxNMywg@mail.gmail.com> <CAH1iCiro3UtTnKMyQiVLumgO88=C5miN1qh5tDcMFP7xD1ZQ4A@mail.gmail.com>
In-Reply-To: <CAH1iCiro3UtTnKMyQiVLumgO88=C5miN1qh5tDcMFP7xD1ZQ4A@mail.gmail.com>
From: Olli Vanhoja <olli@zeit.co>
Date: Tue, 26 Mar 2019 21:46:40 +0100
Message-ID: <CABrJZ5FRbzbaQLBxwr3nCDA3+KR-kTpOVpCED+zQm_HGNKSHHQ@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat@nic.cz>, Tony Finch <dot@dotat.at>, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/o7Ua8lhEVDeDFV_m3YwpWWsdmb4>
Subject: Re: [DNSOP] Minimum viable ANAME
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: Tue, 26 Mar 2019 20:46:56 -0000

On Tue, Mar 26, 2019 at 9:20 PM Brian Dickson
<brian.peter.dickson@gmail.com>; wrote:
>
>
>
> On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja <olli@zeit.co>; 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.