On 06/11/2018 17:17, Tim Wicinski wrote:

In doing some digging through my data, I have instances which I have an apex of a zone, sub zone, etc that are not HTTP but actually a dynamic database endpoint.

I also have solid number of instances where the apex is used mainly as an API endpoint, that serves not HTTP web content.

I think you're expressing a similar concern to those that Wes expressed at the mic.

However, if there was also an HTTP endpoint on that domain apex, how would you distinguish it from the non-HTTP one? Clients don't connect to "hosts", they connect to "services" on those hosts.

Recalling Mark's message from last night which indirectly referenced RFC 5507:

People ... want a pointer to a server for a service at the apex.
CNAME provided a pointer to a server when the prefix was www.
This can be done a number of ways.

1) Prefix  + name in rdata.
2) Service specific type + name in rdata > 3) Generic type + service and name 
in rdata.

#1 is what SRV does, but HTTP has issues with that
#2 is what my proposed HTTP record does
#3 is what SPF etc uses - TXT records with a prefix in the RDATA

These methods are not mutually exclusive - a prefixed SRV record can co-exist with an SPF TXT record and an HTTP (or other record) all at the same point in the DNS.

Turning my proposal into a supposedly "future proof" RR type as was suggested yesterday that covers non-HTTP "future services" won't work unless it uses a service prefix (#1) or something else in the RDATA (subtyping, #3) to identify the service.


DNSOP mailing list

Reply via email to