On Tue, Mar 1, 2016 at 1:13 PM, John Levine <jo...@taugh.com> wrote: >>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.
Actually there is also a practice of using TXT records as well. I was surprised when I found out about it. The folk who have written this all up have not done a good job of advertising it. >> 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. That works for TLS but not if you have multiple packet/transport/presentation layer options. For most of my protocols, I want to apply security enhancements at multiple layers. DANE is more hindrance than help. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
