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

Paul Vixie <> Fri, 09 November 2018 05:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 316671298C5 for <>; Thu, 8 Nov 2018 21:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0M9MSSrJ_HQU for <>; Thu, 8 Nov 2018 21:09:41 -0800 (PST)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0112124C04 for <>; 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 (Postfix) with ESMTPSA id 78593892C6; Fri, 9 Nov 2018 05:09:38 +0000 (UTC)
Message-ID: <>
Date: Thu, 08 Nov 2018 21:09:37 -0800
From: Paul Vixie <>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Brian Dickson <>
CC: " WG" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

> 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