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

[Ray Bellis <[e-mail]>]

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