Re: [DNSOP] Fundamental ANAME problems

Brian Dickson <brian.peter.dickson@gmail.com> Sun, 04 November 2018 11:16 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 CF293130E09 for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 03:16:17 -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 q-l6mvkCkIQk for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 03:16:15 -0800 (PST)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 B8A18129C6A for <dnsop@ietf.org>; Sun, 4 Nov 2018 03:16:14 -0800 (PST)
Received: by mail-ua1-x936.google.com with SMTP id x3so2166236ual.12 for <dnsop@ietf.org>; Sun, 04 Nov 2018 03:16:14 -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; bh=IjcmJZgrZM99t7pytGRKUjNl81vzdajKoU5AeYEoL84=; b=bpcJOLhOFeU0xzdk1+qADemxmpzBL8w81Bla0H4OVwJUPNsb5sZmEVoyXFLKdS5qMk J5RR1fI65RXEXIWqnap8JLOcB53rm3Pqp0Ap8XbW7zLZPSlF625yqmrbT6ay+KoVZPOK 4/hemxpdaMXhQoJah9ePAH4r5huyr5sI9j0KYqUyc0KEgSTlFjAiR+r3pDlqHMaU19Gz wWgPgbl6IfupGWVZ7pzu3qsS24JTmpblBHnZ1zVaWHyvXlLDk+5N96vZgZ8arZODvwJ9 U6hbSW9++xK9pRDmMW/Z6nRj3BMQpQtqC4XcDF5jXMGiZGEJzh+H6Orl0R6TbZ5x2LPN m5JQ==
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; bh=IjcmJZgrZM99t7pytGRKUjNl81vzdajKoU5AeYEoL84=; b=V+WacEW+l0LqLxa1PGgckPhmqxFoWe+4vho3QFvPlzzRaX97/LlZKBCafv4D7POu/P MRkjsbVRyqvfIg82xCaa5lM87rmTBUjQguu9z46KkvE2LQaaROQy4JkD8h6FZFycYlV0 xz2R+K/0fkQuHN5UdIzKwU4cLZW6nZ5z7aensbZeA5xiDH14L/TOnUWtJuobWt9Mw6QN cRiGl267xZkm+RPgLGWR2/aq1M/IT2nWZdYBkX4zrtt5+bG9O9O8StvKtkyaKjko39Ym BkqUBr7LCulpUFzHbQaQbpaVcSRBT6sBJC0gaOog80iAcoPaZO7QJw37n1PggBYL/za7 M9ug==
X-Gm-Message-State: AGRZ1gLK0gBTvEI0hHsEfxEbMzWoGC27gRqHUp5P1nm8t93xYeoBJXx9 wgHeNG6JsYwgWsx7hzpn1ZsqT0pTHGY0fzYFXx67sv/DJUg=
X-Google-Smtp-Source: AJdET5dmRqWZB299J1+e09IQmXrBakBEUCdygKmzg9LRmSdwl0GBTid8P8oH6FBsfiQqJELmG/Eo8x9C+IsEm2xUGrE=
X-Received: by 2002:ab0:7d3:: with SMTP id d19mr6571538uaf.137.1541330173297; Sun, 04 Nov 2018 03:16:13 -0800 (PST)
MIME-Version: 1.0
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com> <alpine.DEB.2.20.1811021543210.24450@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.1811021543210.24450@grey.csi.cam.ac.uk>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Sun, 4 Nov 2018 18:16:01 +0700
Message-ID: <CAH1iCioQX84JThYXPKzaiZ0MxPuDXRa2ttSnxYr6DCmRQxAmew@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000760a1a0579d4e5cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GKSCevxNrlow8HteXr5ZrkIYSUI>
Subject: Re: [DNSOP] Fundamental ANAME problems
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: Sun, 04 Nov 2018 11:16:18 -0000

Ray Bellis wrote:
>
> I don't think that either SRV or URI are usable for the primary use
> case, i.e. allowing a domain owner to put a record at the apex of
> their zone that points at the hostname of the web provider they want to
> use.
>
>

Is the apex thing an optimization only (i.e. is it acceptable that the
mechanism for apex detection not be 100% effective)? I think that's the
input needed before it makes sense to go down any particular branch of
design work, by either the http folks or the dns folks.

Is knowing when something is (or is at least expected to be) the apex, one
of the fundamental drivers on this issue?

Is the question of how the "effective TLD list" is maintained, published,
integrated, etc., something we could/should look closer at, or is that a
big can of worms we should stay away from? E.g. get it published by IANA,
through multiple mechanisms, and formalize the update to it through the
TLD/registry creation process at ICANN? Is it necessary to change/improve
the process, publication, ownership, etc. in order for browsers to reply on
it at a protocol level?

I.e. Rather than rely on hunting for SOA records in DNS and/or looking for
NSes for zone cuts, is making a first pass determination by looking at
whether the "authority" of the URI, aka the FQDN, is one level below an
"effective TLD"? If I have "example.com" or "example.co.jp", or "
example.com.au", and I have the current, comprehensive list of places
someone can register domains, I know that in those cases, "example" is an
apex name. Or does the solution to this problem need to handle apex names
for internal-to-a-registrant zone cuts?

Use of ETLDs could drive the initial query to be some new record type that
exists at a zone apex.
(The ETLD list gives an answer to "is it the apex" which is either "yes" or
"maybe", because zone cuts below the ETLD+1 level can exist, obviously.)

Related, follow-on question:
If that new record type were pointing to the owner name (i.e. itself), or
otherwise signaled that an A/AAAA at the owner name should be used, would
having the authority server return the A/AAAA records as well fix the
multiple-lookups issue, i.e. not require the lookup of the A/AAAA records
if the new record type was not present?
(The distinction between a self-referential or empty RDATA answer, and a
NOERROR/NODATA lack of RR, would be the indicator on whether the zone owner
wanted to play nice with the optimizations. The client would probably also
need to do separate A/AAAA queries in the NOERROR/NODATA case, since the
triggering URI would still need to its authority name to be resolved to an
address.)

I.e. :
@ NEWRRTYPE @ ; (or empty RDATA, signaling that the response needs to
include A/AAAA, and that the client should expect A/AAAA in the response)
@ A <apex IPv4>
@ AAAA <apex IPv6>

or
@ NEWRRTYPE www.myproviders.fqdn ; points out of zone, so no additional
data -- but client/recursive needs to chase RDATA down like it was a CNAME

I realize in this hypothetical model, both authority and recursive servers
need updates.
Or is the returning A/AAAA on the empty/self-ref a strictly optional
optimization, and thus not a barrier to adoption?
(The client can't do a parallel query for the A/AAAA records, because it
needs the first answer to get the name for the second query. But it can do
the queries sequentially without the assistance of the recursive.)

I anticipate both the new record type and additional processing, would be
less problematic on authority operators than ANAME.
It adds more additional processing, but does not change the general model
of mostly-static zone data, which plays nice with DNSSEC.

For the recursives, the incremental change is the same additional
processing as authority servers (additional data if empty/self-ref,
possibly with extra queries, or CNAME-type processing.)

Also: would this new record type (and query/response logic) make sense to
use everywhere, not just at a zone apex? I think there would be nothing
implicitly difficult in making it universal, on both the authority and
recursive servers. For the recursive servers, I don't think they even have
the ability to distinguish whether a name is apex or not (!!). For
authorities, I don't think there's anything intrinsically apex-ish about
what is required, so it would probably be less work to support the new
record type anywhere.

Brian