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

From: Brian Dickson <[email-masked]>
Date: Fri, 9 Nov 2018 11:09:02 +0700

Paul Vixie wrote:

> Ray Bellis wrote:
>
> On 09/11/2018 07:14, Tony Finch wrote:
>
> But remember: the goal is to make the DNS easier to use for people
> who don’t know about the restrictions on CNAMEs.
>
> I'd say the goal is to make the DNS *possible* to use for people who
> don't know about the restrictions on CNAMEs.
>
> 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.)
>
> I concede that ANAME perhaps makes that easier than HTTP does, but it
> does so at the expense of significant complexity in authority servers by
> still requiring A and AAAA lookups to be somehow "magic", and doesn't
> fix the architectural problem of lack of a service identifier.
>
> i am loath to create per-service record types. that's why SRV. if you really
> want every client of a service to query for something other than AAAA/A,
> can you try to fix what's wrong with SRV regarding wildcards,but avoid a
> new type code for every new thing like MX and HTTP as they come along in
> the decades to follow? also, does SSH count as a service? what about FTP?
> Gopher? RSync? NNTP? IMAP(S)? it may not be too late to think
> architectural thoughts like "what will the internet engineering community
> think, 50 years from now, that we should have done for them?"

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)

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).

I think this is the right time to add this to the proposal (before any
implementations exist). You can't put the cart before the horse if there is
no {cart,horse}.

Not exactly speaking for an authority server operator/developer, I don't
think the difference between either implementing or operating the
wildcarded version is in any way problematic.
(No authority requirement to track or add A/AAAA == we're good; solves apex
issue == we are happy; multiple types of "pointer" at same owner name
(better than CNAME) == we are ecstatic.)

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?

Brian

---

From: Paul Vixie <[email-masked]>
Date: Thu, 08 Nov 2018 21:09:37 -0800

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:
>
>  2. If present, the response is returned, optionally with A/AAAA (i.e.
>     if resolver is upgraded)

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

>   * 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
> 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".
>

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

-- 
P Vixie

---

From: Brian Dickson <[email-masked]>
Date: Fri, 9 Nov 2018 12:55:07 +0700

> nonwildcard.

I'm not 100% sure, but I think the generic DNSSEC response handling already
covers this.
If the response does not include the QTYPE, the NSEC/NSEC3 record proving
non-existent is required (already).
That the types are "type-specific thing" vs "wildcard-type thing", doesn't
even require special handling.

> real utility will come after the last resolver understands and

I think that overstates the deployment issue; in 1990, there weren't any
public resolvers that could be used (at least not that I'm aware of, or
maybe they were but got closed down later.)

Currently, the feature becomes usable when some fraction of the
{standard,open} resolvers have deployed support, and/or enough of the
clients (browsers) provide support, or both, plus some significant
support/deployment in authorities.

The efficiencies/optimizations on queries are something that might be
signaled via EDNS (either an OPT or a flag), regarding support for the new
slew of types.

Clients could have multiple resolvers configured, and prefer ones that
support the new types (as signaled by EDNS).

Those resolvers that provide support, and resolve the RDATA names to A/AAAA
and return those (from cache or proactively), minimize the need for
parallel queries and the corresponding query load.
Clients can learn (or be configured, or whatever) about resolver support
and tune their query logic based on that support.

That would put some degree of competitive pressure on resolver operators,
as well as providing a signal on client-side support. Client queries with
EDNS signal, to resolvers that do not support, still provide meaningful
uptake signal level to resolver operators.

The remaining two elements are authority server (software/operator)
support, and end-user (registrant) use. Competitive pressure in the market
place is beneficial once the first entrant deploys. EDNS signaling can help
there too, even when no response would have been provided (due to lack of
actual RRtype(s) at owner name).

I'm optimistic that there's a clean, scalable, flag-day-less, incremental
way forward.

Brian