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

Paul Vixie <paul@redbarn.org> Fri, 09 November 2018 05:09 UTC

Return-Path: <paul@redbarn.org>
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 316671298C5 for <dnsop@ietfa.amsl.com>; Thu, 8 Nov 2018 21:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 0M9MSSrJ_HQU for <dnsop@ietfa.amsl.com>; Thu, 8 Nov 2018 21:09:41 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0112124C04 for <dnsop@ietf.org>; Thu, 8 Nov 2018 21:09:40 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:ec89:6a65:e867:265a] (unknown [IPv6:2001:559:8000:c9:ec89:6a65:e867:265a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 78593892C6; Fri, 9 Nov 2018 05:09:38 +0000 (UTC)
Message-ID: <5BE51691.1050006@redbarn.org>
Date: Thu, 08 Nov 2018 21:09:37 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Brian Dickson <brian.peter.dickson@gmail.com>
CC: "dnsop@ietf.org WG" <dnsop@ietf.org>
References: <CAH1iCiqnzV6NE2FaRapFK_SQ4bhbraLs5GAbBuU+DYe15E54XA@mail.gmail.com>
In-Reply-To: <CAH1iCiqnzV6NE2FaRapFK_SQ4bhbraLs5GAbBuU+DYe15E54XA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qN_VYgKtJJqpNn8jUKOogMcCsU8>
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: Fri, 09 Nov 2018 05:09:42 -0000


Brian Dickson wrote:
> Paul Vixie wrote:
>
>     ...
>
>     i regret not adding ANY as an RR type (not just a Q type) back when
>     the DNS was small and i supported 90% of it. what we actually needed
>     is a wildcard on types so that if there's no more-specific type you
>     get thatone, which would have an rdata of the target name, but act
>     like PTR (which the DNS requester has to follow) rather than like
>     CNAME (which the recursive has to follow.)
>
>     ...
>
>
> Funny anecdote:
>
> I was actually going to add a suggestion for a "fall-back catch-all" aka
> wildcard RR type, to the first message in this new thread, but was
> concerned about muddying the waters.
>
> I'll just point out the semantics of having both service-specific, and
> wildcard, service-RRtypes, and their poster-child use cases.
>
> Semantics:
>
>  1. Client queries for service-specific RRtype
>  2. If present, the response is returned, optionally with A/AAAA (i.e.
>     if resolver is upgraded)
>  3. If absent, but a wildcard service RRtype is present, the wildcard is
>     returned, optionally with A/AAAA (ditto)
>  4. If neither is present, noerror/nodata response, possibly with A/AAAA
>     of original owner (i.e. if resolver is upgraded)

i don't love the dnssec implications of this, including proof of 
nonwildcard.

> Typical instructions to domain owner:
>
>   * If all your services are on some third party at the same FQDN, put
>     in a wildcard pointing there
>   * If most of your services are on one third party at the same FQDN,
>     put in a wildcard pointing there, with any other type-specific
>     services which are on other third parties, added with pointers to
>     each of them
>   * If you are wanting to ensure only responses for specific types, use
>     those types and do not use the wildcard type.
>
> The logic required on authority servers is exactly analogous to wildcard
> names. Look up the specific thing first, and if absent, look up the
> wildcard. Return what you find.
> The logic required on resolvers is similarly analogous, including the
> logic for following the RHS returned with any such record type: rewrite
> the query and rerun resolution (just like CNAMEs).

it's pretty not-practical at this point to add a feature whose first 
real utility will come after the last resolver understands and 
implements it.

> ...
> Minimizes level of effort on nearly-trivial zones; gives control for
> zones operated by folks who want control; minimizes total minimum record
> count (provably) in all situations. Easy to add more types without ANY
> logic-flow changes to any implementations (assuming RDATA is just an
> FQDN), beyond adding new types to the enum set of "things like this".
>
> Are we converging on consensus, possibly?

no. these are the weeds. the time to have done this was 1990.

-- 
P Vixie