Re: [DNSOP] Minimum viable ANAME

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 26 March 2019 20:20 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 425FE120B00 for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 13:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 E0k2FhpxDmVw for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 13:20:25 -0700 (PDT)
Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 14805120AFE for <dnsop@ietf.org>; Tue, 26 Mar 2019 13:20:25 -0700 (PDT)
Received: by mail-qk1-x742.google.com with SMTP id n68so8521929qka.1 for <dnsop@ietf.org>; Tue, 26 Mar 2019 13:20:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pn+pFCjo9kQxM334FRNvjDDTM3bvQJqpX9mPbXIpjCo=; b=VoPhJLE/jqo7xvKSgIKejJEBkfPSYo1A92IDIN9733pUTtvdeVOiPnzpJvgtrbY4cR PzB7TEEIR5MnH1XvJsEW7ohBgboQhgfaxQwfi2c1c+KWn4RzxuIopQ6XB9z4m1RK56i+ QQIhwDv1oHgT0ePOH2lA5r03RMXjnfc3M5+3AJs+nbrvQNomQRpbTxHfTbr/mFVBi2jz Ro13Qmscw0P/FZ9F9VExLr96ehtvieJkTTbHAu26N3+I9+BWsDbhowEazr6bU2MRJSGm uSlzZc5oVLBh/qsFdgMBuEQff62ppmNfYvhAoElHPnmQWE2ssnE1/3Nc6SBPLm4tWq9F R1qg==
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=pn+pFCjo9kQxM334FRNvjDDTM3bvQJqpX9mPbXIpjCo=; b=kfMPwYsVvqOPpykL174ThyvVeqqX6+pa8pXJMOtKj+bG4i9WXnmWVb7M2RpSXAX22J Bd5/4HUtcM+ubk3FoZ/M9Hqsm99G/my7z9kxCGOaEN3Mb66L56RoF0jqaOMuYBNPBpsp Pgy1gZOSleoGsCfnPloYdMn1QTvJrdEjyPxUPdwvgEX+E5CEe/NBVREeX3IUJouxt5LN Y8BbUuDYZ6eG4tpgnvj3Ss/526M4VpYcfa838BYT9bHmjpEuynUbS6pLHr2ElDFUejVo SkvxENZLrSGbIfLLBuzserleGLSXZw/YO0z8z/Lez4CpcVgoaYQ7g66Ag9KsG1VlhFaA IUMQ==
X-Gm-Message-State: APjAAAUHTZYByN2wYdGMuhjW2Snr8hnHaJ22H3Ji6Mm73C0bidrI5BlU 60+OPzdFfrsuglnFrtFzs9M1IQO0KstmybptQBc=
X-Google-Smtp-Source: APXvYqzwaOeHf2vwAfe/9la2+NuFJkDZcDSEXFJHQxSrJFqJ2plbmzw/N1gWBrvg5LRI66ZZTv5v/TfmzGlr0IGi/H0=
X-Received: by 2002:a05:620a:14b4:: with SMTP id x20mr12832099qkj.202.1553631624158; Tue, 26 Mar 2019 13:20:24 -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>
In-Reply-To: <CABrJZ5FPeP5NQ5qRyOw9BhrB6k+6hUvj32DAcjZBgTryxNMywg@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 26 Mar 2019 21:20:10 +0100
Message-ID: <CAH1iCiro3UtTnKMyQiVLumgO88=C5miN1qh5tDcMFP7xD1ZQ4A@mail.gmail.com>
To: Olli Vanhoja <olli@zeit.co>
Cc: Vladimír Čunát <vladimir.cunat@nic.cz>, Tony Finch <dot@dotat.at>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000011e2e70585050d8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bEefYyYwwawN5O29gYuGHQCHHNY>
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:20:28 -0000

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.

Clearly, there would not be compatibility between old browsers and new
RRtypes, since the support for the new types would be in the new browsers
exclusively.

The use of the new types would be controlled by the apex owners of each
individual domain.
Each domain would be free to switch to the new type whenever they wished; I
would expect it to follow the traditional curve of early adopters through
laggards...

This would be a case where there would be a need for deployment of new
browsers first, in order to enable the new record type.
Once there was a critical mass of deployed browsers, I'd expect uptake on
zone owners to follow, eventually creating pressure on laggards to upgrade
their browsers.

Non-upgraded browsers would lose access to names at zone apexes which use
the new type(s).


> I'd say approximately until DNS has been replaced by some other tech.
> If we are lucky DoH would solve it by doing what those previously
> mentioned companies are doing now on their servers, but then we would
> cry again that it's the wrong solution.
>

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

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.)

In this context, "DoH would solve it" is both ambiguous, and largely
redundant, or erroneous.

If by DoH, you mean upgraded resolvers, then upgraded resolvers would be
doing "it"; DoH doesn't enter the picture at all, except as an optional
transport path. Except that without upgrading the browsers, the new RRtypes
would not be requested, and "it" would not work at all. With upgraded
resolvers and browsers both, the new RRtypes would work and have better
performance, but again, the DoH piece is unrelated and not required.

If by DoH, you mean upgraded browsers, then upgraded browsers would be
doing "it"; again, DoH doesn't enter the picture. At best, DoH would be
orthogonal to the new RRtype usage. It would be the support for the RRtype,
not the support for DoH, that would enable the new apex dns record type for
HTTP-specific aliasing.

Brian