Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 08 November 2018 05:04 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 AD212130E91 for <dnsop@ietfa.amsl.com>; Wed, 7 Nov 2018 21:04:54 -0800 (PST)
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 oQgn5_fJEqAV for <dnsop@ietfa.amsl.com>; Wed, 7 Nov 2018 21:04:51 -0800 (PST)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 BDD70130EC8 for <dnsop@ietf.org>; Wed, 7 Nov 2018 21:04:48 -0800 (PST)
Received: by mail-vs1-xe2b.google.com with SMTP id t17so10865094vsc.8 for <dnsop@ietf.org>; Wed, 07 Nov 2018 21:04:48 -0800 (PST)
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=c0cMuQf4y+d9Vy29RT2ijAoivb1s3Q9UPT6C05DzlY0=; b=UzpPP7+5n5GTDTOo1tdB4JsOle5daHtACnDmQfB46k5N1JjRDqKKpgAVXNUaGo607H 72YqMTnUlw9CUK7Ud281fmbab5PtnhzG4eMg2KQN4NOP+YSQLiO3NWQ0/zvX64zunRMR LcJ5cShySDNQMt01408ZE07GCXmKpQxK/ZG3WiW0Mp9g74TOltVv+oKbEPQz3/tgk1r2 ABKQCr+9gaQ2RDJT+vv2CI6iXiGCdfpM1e39SCrAULYotyElNBiaFq0X7UVO3vehfh8z bn+GGjpkfvIaPpTp7K8RtSr3mLfEBSnrg+60X0eIeAa1d+V4+TdyM3NcxuLwvQn7Yonb GOwA==
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=c0cMuQf4y+d9Vy29RT2ijAoivb1s3Q9UPT6C05DzlY0=; b=I9MHXU4lMI/L2m0/oY8H0s+BNNTT3OlTtaeOxi2XY6Sd8QnaAG/OoBkaY62ZWDnjeT 85dzdGmWk2BxPJx82SjBoZQg70c0qQGwBmOgslBpSbZBigOgcG5jyqaakIHijuZ8Y+Dy ejwEUnsv+J/+WwICVKJ+ZIiR2ED0NSqwuHHYVJtwL95/MW3KNaRwYW5ZE4kS+JN9zIjb RL8jyI9bvqHH4Ol1kt1wNPVGSjjV2yOm4JNjNQEkiACmQQIQ5p0IHDMBJ49hx12BfzM4 FhiJ6HJ0BHsEwXHxAZcASyKgGeXMWyyCYU/eyjMPH0GmI/W5B1S6l5VbHocCB7SPk4TW jBBA==
X-Gm-Message-State: AGRZ1gKoywWpLnATztpIIM8zyzOXI3WnmBGJK+oo3/WhgeUhnPXhDW9U lw932yuEn2ZOCE/gXTDv8YdPmPtNYNd6Z8B0BWQ=
X-Google-Smtp-Source: AJdET5coO6WyKIedCoei1gzn5A6tZZcmpDXWZyXpNy5ApL8ECekFog9KpH5u0Ve+HJ9/2tOsKYMoOodE4KHMJIcSZf0=
X-Received: by 2002:a67:3edc:: with SMTP id a89mr1335200vsi.136.1541653487739; Wed, 07 Nov 2018 21:04:47 -0800 (PST)
MIME-Version: 1.0
References: <CAH1iCirLfSEUcTf=p5bHuFJSFie_BoPh4X=89w2mpxgNpR9HkA@mail.gmail.com> <2BDA0411-202D-4199-A43B-3FDC50DC47F5@isoc.org> <CAH1iCirdkU-jYLRGeOm3DcdsReShyOez3oU5hw5sJYEtQyyqGw@mail.gmail.com> <D378E8F5-A667-4649-90ED-7C3612F0A013@isoc.org>
In-Reply-To: <D378E8F5-A667-4649-90ED-7C3612F0A013@isoc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 8 Nov 2018 12:04:35 +0700
Message-ID: <CAH1iCioy4Ox4e5jxEOj=7gG0TaTaiw=QvPWQnvBJpT9D1b273g@mail.gmail.com>
To: Dan York <york@isoc.org>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000080e8ca057a202c54"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-6sZbHIUTula3I6Zh1Sc2y0GlGE>
Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
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: Thu, 08 Nov 2018 05:05:00 -0000

On Thu, Nov 8, 2018 at 11:47 AM Dan York <york@isoc.org> wrote:

> Brian,
>
> > On Nov 8, 2018, at 10:30 AM, Brian Dickson <
> brian.peter.dickson@gmail.com> wrote:
> >
> > For new RRtypes, registries, registrars, and their provisioning services
> do NOT need to support them; the new types are in the zones only.
>
> DY> (Experiencing a "DUH!" moment.)  Yes, of course. It's zone data so
> only those entities handling zone data need to care.  In my
> still-annoyingly-jet-lagged mind, I made the classic mistake of equating
> "registrars" with "DNS hosting operators" because so many registrars are
> *also* DNS hosting providers.
>
>
No problem - it's very easy to mix up the pure math relationships "one to
one" and "onto". (Don't try to, BTW, my brain still hurts from 3rd year
pure math in 1986.)


> > New RRtypes which do not require any "additional" processing, do NOT
> strictly speaking require resolver support, since resolvers handle unknown
> RRtypes. (Mark A can quote you the RFC, and I think has recently.)
>
> DY> Ah, interesting. Where the proposed HTTP RRtype has behavior similar
> to the CNAME record, my assumption would be that resolver software would
> need to know what to do once it receives the record.  For that reason,
> wouldn't all the resolvers (or at least an extremely high %) need to be
> upgraded to support the new record?
>
>
Yes and no. It requires EITHER the resolver OR the client to handle the
name it gets back, and do another query for A/AAAA on that, for whatever
the client originally was looking for.
I.e. an upgraded client (e.g. browser) could bootstrap the system prior to
widespread resolver upgrades.
Resolver upgrades would lower their own load, by making the parallel/serial
re-queries un-necessary.
Thus, it puts at least a modest incentive on resolvers to upgrade.

It's kind of like DIY CNAME, except for only one iteration. (If you do a
lookup on a name for A or AAAA, and the name is a CNAME-only thing in DNS,
resolvers handle that already.)
So, if the resolver is upgraded, it would return the HTTP answer plus A and
AAAA records.
If the resolver was not upgraded, it would return just the HTTP answer (an
FQDN), and the client would have to ask for A and/or AAAA records at that
name. (The resolver would still handle the chaining if the FQDN was a
CNAME.)

NB: client stub OS libraries for getaddrinfo return lists of A, AAAA, or
both, depending on the AF_* parameter (AF_INET, AF_INET6, AF_ANY). Those
might be multiple (parallel, possibly) DNS queries, but the API-calling
code would be simple enough.

Brian