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