>So while SRV and NAPTR and the TXT records are stuck using the two >level approach, there is also a clear need for a meta-discovery record >that only uses the service prefix.
Maybe. >Using SRV discovery you might use: > >_mmm._tcp.example.com SRV 1 10 80 host1.example.com >_mmm._tcp.example.com SRV 1 10 443 host2.example.com > >This is OK but its rather ugly. Does port 80 vs 443 entail the >implicit use of TLS? The practice to date has been to register separate service names for versions of a service that do implicit TLS, e.g., http and https, imap and imaps, pop3 and pop3s, sip and sips. This is a kludge but it's a well established kludge. Service names are cheap, so it's a cheap kludge. > If so what factors would determine the SSL trust anchor? RFC 6698 would tell you to look up the TLSA record at _443._tcp.example.com. (Note the port number rather than service name, specifically to handle TLS services on nonstandard ports.) In the absence of DANE you presumably use whatever trust anchor you use. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
