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 that
one, 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?"
My long-term goal would be to never have an A or AAAA record appear in
the DNS other than at the owner name of an actual hostname.
i don't think you mean "actual". anycasted addresses act like host
addresses in all ways (answering UDP, answering TCP SYN, answering ICMP)
but are not "actual" hosts. i think i know what you _mean_ here and if
so i agree with that. but 1.1.1.1 answers both HTTPS and DNS, and would
surely get an AAAA and A in your model, but is not a "host", and its DNS
owner would not be a "hostname". perhaps you mean "effective host" which
could be real or virtual?
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
