On 09/11/2018 09:30, 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 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.)
interesting... :)
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?
Creating per-service record types is the IAB's preferred option (per RFC
5507).
Is fixing wildcards for SRV even possible without a major forklift
upgrade to the DNS?
also, does SSH count as a service? what about FTP? Gopher? RSync?
NNTP? IMAP(S)?
My line of thinking is that in this context a service is "a domain-wide
facility that's exposed to third parties where it is strongly preferred
that the third party use the bare domain name directly because that
domain name is used in end-user identities or to identify the endpoint".
For me, that would include: SMTP, HTTP(s), SIP, XMPP
So, with respect to your list:
SSH - no, it's for managing a specific host
FTP - maybe, but is still well served by the "ftp." convention
Gopher - yes, if it still has any use?
Rsync - maybe - it's most often used for host-to-host transfers,
but arguably a domain could offer file dist via rsync::,
although again the "rsync." prefix would usually suffice.
NNTP - probably not, end users see the hostname in their config
but "news." etc is fine.
IMAP - I believe there's already mechanisms for discovering IMAP
servers via SRV, although AIUI it's usually a one-off
configuration-time search, not per-session.
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?"
I hope that's what I'm trying to do. It would be real bad if some
alternative to "the web" comes along in 10 years time but we can't
differentiate it in the DNS because too many A and AAAA records are
assumed (absent a service identifier) to be dedicated to "the web".
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?
Yes, indeed, that is a more accurate definition.
regards,
Ray
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
