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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
