>> Here's a concrete example. My laptop is named mypc.example.com. Because >> I am a forward thinking guy, I send a DANE-verified client cert whenever >> I connect for submission, POP, IMAP, or jabber, and because I'm still >> lazy, I use the same certificate for all of them. The DNS records to >> tell the world about that are: >> >> $ORIGIN mypc.example.com >> _submission._client._tcp IN TLSA ... cert stuff ... >> _imap._client._tcp IN CNAME _submission._client._tcp >> _imaps._client._tcp IN CNAME _submission._client._tcp >> _pop3._client._tcp IN CNAME _submission._client._tcp >> _pop3s._client._tcp IN CNAME _submission._client._tcp >> _xmpp-client._client._tcp IN CNAME _submission._client._tcp >> >> How would you do it? > >Personally, I wouldn't use those owner names, as that's inconsistent >with _tcp being associated with SRV usage, with the previous label being >one from the IANA port registry.
See RFC 6698, which already uses _tcp to name TLSA server records. This tries to minimize the extra creativity. In case it wasn't clear, I was proposing to put "client" into the port/service registry (same thing), as a pseudo-service. >Thinking more though, I actually prefer _<service>._<proto>._client. >The use of _client on the right-hand side would allow this to fit in >Dave Crocker's "underscore registry" as the "most significant label", >with everything to the left of that borrowed from SRV. I suppose, but doing it as _<service>._client._<proto> puts it in the existing service namespace. It's not a huge difference, and it's been clear for a while that if we do Dave's registry, part of what it includes will be a list of the underscore names that are protocol labels. That currently includes _tcp _udp _sip _xmpp _ldap _http _ocsp so I suppose adding one more isn't awful, but it seems needlessly kludgy. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
