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, 04 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
- [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems John Levine
- Re: [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems John R Levine
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Erik Nygren
- Re: [DNSOP] Fundamental ANAME problems Bob Harold
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Christian Huitema
- Re: [DNSOP] Fundamental ANAME problems John R Levine
- Re: [DNSOP] Fundamental ANAME problems Lanlan Pan
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- [DNSOP] CNAME at apex - a website publisher persp… Dan York
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems manu tman
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Jim Reid
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Mark Andrews
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Mark Andrews
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Olli Vanhoja
- Re: [DNSOP] Fundamental ANAME problems Thomas Peterson
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Dan York
- [DNSOP] Further ANAME minimization /\ Ray converg… Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Matthijs Mekking
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Richard Gibson
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Tim Wicinski
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Michael J. Sheldon
- Re: [DNSOP] Further ANAME minimization /\ Ray con… tjw ietf
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Kevin Darcy
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Tim Wicinski
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Bob Harold
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Thomas Peterson
- Re: [DNSOP] Fundamental ANAME problems Tim Wicinski