This solution is more TLSA standard friendly, than the previous one. (CNAME forwarding are used)
_443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www-domA-crt _443._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _443._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m-domA-crt ; Port 60 is Unassigned. Not used by any real service. _60._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _60._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt _60._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt _60._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt _25._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s1.domA.tld. _25._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s2.domA.tld. _587._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s1.domA.tld. _587._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s2.domA.tld. _993._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s1.domA.tld. _993._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s2.domA.tld. ; Skipping SMTP (Port 26) based 3rd email-server. _60._tcp.im1.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _60._tcp.im1.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im1-domA-crt _60._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt _60._tcp.im2.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im2-domA-crt _5061._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _15061._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _5061._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _15061._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _5223._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _15223._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _5223._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _15223._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _5269._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _15269._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _5269._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _15269._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _6697._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _6699._tcp.im1.domA.tld. 900 IN CNAME _60._tcp.im1.domA.tld. _6697._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. _6699._tcp.im2.domA.tld. 900 IN CNAME _60._tcp.im2.domA.tld. = 12 TLSA lines/rr, and 22 related CNAME lines/rr. = 34 total TLSA related lines/rr. Previously, without using CNAME, this config used 48 TLSA lines/rr, where each line had TLSA RR. Are these (showed in above) correct declarations ? Client-software which is trying to connect with server's secure port 5223, they should still be bale to obtain both TLSA: "TLSA 2 0 1" and "TLSA 1 0 0" and use it for TLS /SSL cert verification for port 5223, and on success, establish encrypted and authenticated communication, right ? Any other way to improve this configuration further ? How to make it more secured and encrypted ? How to add more declarations to clearly define all components that are used in the system. I skipped (did not show) : SSHFP, CERT PGP, etc DNS RRs, never the less they exists, and very essential to very clearly define & declare what is the ZO/D-O approved component(s), (public-side) GPG-KEY(s), which are valid for this system, as these Keys are used for signing files, software, etc, so that users can check their received/downloaded software/files are indeed authentic and unmodified in the middle of the way, or not. Need to understand more on NSEC. Thanks in advance, -- Bright Star. Received from Bry8 Star, on 2013-06-26 5:56 PM: > Great, another possible solution could be using CNAMEs. > > More info on CNAME is here: > RFC 6698 Section > A.2.1.1. Provisioning TLSA Records with CNAME Records > https://tools.ietf.org/html/rfc6698#appendix-A.2.1.1 > > More info on DNAME: > https://tools.ietf.org/html/rfc6698#appendix-A.2.1.2 > > Thanks to both of you Viktor, and, Olafur, for all suggestions, > improvements (related to this type of configuration). > > This configuration is intended to be used for a (very) "higher" > security & encryption based service(s), where there is lesser or no > confusion exist in TLSA/DANE and related DNS > declarations/publication, etc. All necessary components are/will be > clearly defined to eliminate (all/most) confusions. Very higher > strength SSL/TLS certs are used in these services. Clients/users > are shown & instructed to use slightly special configurations & > client-software to connect with these services. But it is within > what is publicly available normally in common and major > web-browsers, client-softwares. > Those who do not want to use such configuration, or, those who do > not have various related capacity to process/handle more than one > TLSA based secured & encrypted solution, then such > clients/users/domain-owners/zone-operators may/should use one/single > TLSA and may/should also choose to use shorter version of TLSAs like > "TLSA u s 1" or "TLSA u s 2", instead of two or more full TLS/SSL > cert based TLSA/DANE solution which are used & shown in these > configurations, or choose what fits best for their > implementation/objectives. > In configuration, the choice of variations, permutations and > combinations for TLSA related DNS records, which are allowed or > optionally allowed by related RFCs, are upon > domain-owner/zone-operator/DNS-operator. > > So, previously posted config can be like this ? > > Are these DNS/zone declarations correct ? > > (I've slightly modified & tried to correct per my own understanding. > Changed "im" hostname into "im1", etc, forgot to show DNSKEY RRs, > skipped DS RRs used for subs). > > A zone file: > ; Lines that starts with ";" symbol are inactive. > domA.tld. 3600 IN SOA s1.domA.tld. hostmaster.domA.tld. 2013052910 > 18000 3600 864000 3600 > ; Below two lines are actually active in actual zone file. > ;domA.tld. 3000 IN DNSKEY 256 3 8 HEX_CODE_KEY > ;domA.tld. 3000 IN DNSKEY 257 3 8 HEX_CODE_KEY > ; Since it is targetted for advanced & secured & > ; encrypted usage/purpose, above will be changed, > ; and higher strength encryption will be used. > ; Skipping NSEC. > domA.tld. 3000 IN NS s1.domA.tld. > domA.tld. 3000 IN NS s2.domA.tld. > domA.tld. 300 IN A IP.ADRS_S-1_IPv4 > domA.tld. 300 IN A IP.ADRS_S-2_IPv4 > domA.tld. 300 IN A IP.ADRS_S-IM-1_IPv4 > domA.tld. 300 IN A IP.ADRS_S-IM-2_IPv4 > domA.tld. 300 IN AAAA IP::ADRS_S-1_IPv6 > domA.tld. 300 IN AAAA IP::ADRS_S-2_IPv6 > domA.tld. 300 IN AAAA IP::ADRS_S-IM-1_IPv6 > domA.tld. 300 IN AAAA IP::ADRS_S-IM-2_IPv6 > s1.domA.tld. 900 IN A IP.ADRS_S-1_IPv4 > s2.domA.tld. 900 IN A IP.ADRS_S-2_IPv4 > im1.domA.tld. 900 IN A IP.ADRS_S-IM-1_IPv4 > im2.domA.tld. 900 IN A IP.ADRS_S-IM-2_IPv4 > s1.domA.tld. 900 IN AAAA IP::ADRS_S-1_IPv6 > s2.domA.tld. 900 IN AAAA IP::ADRS_S-2_IPv6 > im1.domA.tld. 900 IN AAAA IP::ADRS_S-IM-1_IPv6 > im2.domA.tld. 900 IN AAAA IP::ADRS_S-IM-2_IPv6 > www.domA.tld. 300 IN CNAME domA.tld. > m.domA.tld. 300 IN CNAME domA.tld. > _http._tcp.domA.tld. 3600 IN SRV 0 0 80 www.domA.tld. > _https._tcp.domA.tld. 3600 IN SRV 0 0 443 www.domA.tld. > _http._tcp.www.domA.tld. 3600 IN SRV 0 0 80 www.domA.tld. > _https._tcp.www.domA.tld. 3600 IN SRV 0 0 443 www.domA.tld. > _http._tcp.m.domA.tld. 3600 IN SRV 0 0 80 m.domA.tld. > _https._tcp.m.domA.tld. 3600 IN SRV 0 0 443 m.domA.tld. > domA.tld. 3600 IN MX 10 s1.domA.tld. > domA.tld. 3600 IN MX 20 s2.domA.tld. > _smtp._tcp.domA.tld. 3600 IN SRV 10 0 25 s1.domA.tld. > _smtp._tcp.domA.tld. 3600 IN SRV 20 0 25 s2.domA.tld. > _smtp._tcp.s1.domA.tld. 3600 IN SRV 10 0 25 s1.domA.tld. > _smtp._tcp.s1.domA.tld. 3600 IN SRV 20 0 25 s2.domA.tld. > _smtp._tcp.s2.domA.tld. 3600 IN SRV 10 0 25 s2.domA.tld. > _smtp._tcp.s2.domA.tld. 3600 IN SRV 20 0 25 s1.domA.tld. > _submission._tcp.domA.tld. 3600 IN SRV 10 0 587 s1.domA.tld. > _submission._tcp.domA.tld. 3600 IN SRV 20 0 587 s2.domA.tld. > _submission._tcp.s1.domA.tld. 3600 IN SRV 10 0 587 s1.domA.tld. > _submission._tcp.s1.domA.tld. 3600 IN SRV 20 0 587 s2.domA.tld. > _submission._tcp.s2.domA.tld. 3600 IN SRV 10 0 587 s2.domA.tld. > _submission._tcp.s2.domA.tld. 3600 IN SRV 20 0 587 s1.domA.tld. > _imaps._tcp.domA.tld. 1200 IN SRV 0 0 993 s1.domA.tld. > _imaps._tcp.domA.tld. 1200 IN SRV 5 0 993 s2.domA.tld. > _imaps._tcp.s1.domA.tld. 1200 IN SRV 0 0 993 s1.domA.tld. > _imaps._tcp.s1.domA.tld. 1200 IN SRV 5 0 993 s2.domA.tld. > _imaps._tcp.s2.domA.tld. 1200 IN SRV 0 0 993 s2.domA.tld. > _imaps._tcp.s2.domA.tld. 1200 IN SRV 5 0 993 s1.domA.tld. > _pops._tcp.domA.tld. 1200 IN SRV 0 0 995 s1.domA.tld. > _pops._tcp.domA.tld. 1200 IN SRV 5 0 995 s2.domA.tld. > _pops._tcp.s1.domA.tld. 1200 IN SRV 0 0 995 s1.domA.tld. > _pops._tcp.s1.domA.tld. 1200 IN SRV 5 0 995 s2.domA.tld. > _pops._tcp.s2.domA.tld. 1200 IN SRV 0 0 995 s2.domA.tld. > _pops._tcp.s2.domA.tld. 1200 IN SRV 5 0 995 s1.domA.tld. > ; Skipping SMTP (Port 26) based 3rd email-server. > _sip._tcp.domA.tld. 1200 IN SRV 0 0 5060 im1.domA.tld. > _sip._tcp.domA.tld. 1200 IN SRV 1 0 5060 im2.domA.tld. > _sip._tcp.domA.tld. 1200 IN SRV 2 0 15060 im1.domA.tld. > _sip._tcp.domA.tld. 1200 IN SRV 3 0 15060 im2.domA.tld. > _sips._tcp.domA.tld. 1200 IN SRV 0 0 5061 im1.domA.tld. > _sips._tcp.domA.tld. 1200 IN SRV 1 0 5061 im2.domA.tld. > _sips._tcp.domA.tld. 1200 IN SRV 2 0 15061 im1.domA.tld. > _sips._tcp.domA.tld. 1200 IN SRV 3 0 15061 im2.domA.tld. > _sip._tcp.im1.domA.tld. 1200 IN SRV 0 0 5060 im1.domA.tld. > _sip._tcp.im1.domA.tld. 1200 IN SRV 1 0 5060 im2.domA.tld. > _sip._tcp.im1.domA.tld. 1200 IN SRV 2 0 15060 im1.domA.tld. > _sip._tcp.im1.domA.tld. 1200 IN SRV 3 0 15060 im2.domA.tld. > _sip._tcp.im2.domA.tld. 1200 IN SRV 0 0 5060 im2.domA.tld. > _sip._tcp.im2.domA.tld. 1200 IN SRV 1 0 15060 im2.domA.tld. > _sip._tcp.im2.domA.tld. 1200 IN SRV 2 0 5060 im1.domA.tld. > _sip._tcp.im2.domA.tld. 1200 IN SRV 3 0 15060 im1.domA.tld. > _sips._tcp.im1.domA.tld. 1200 IN SRV 0 0 5061 im1.domA.tld. > _sips._tcp.im1.domA.tld. 1200 IN SRV 1 0 5061 im2.domA.tld. > _sips._tcp.im1.domA.tld. 1200 IN SRV 2 0 15061 im1.domA.tld. > _sips._tcp.im1.domA.tld. 1200 IN SRV 3 0 15061 im2.domA.tld. > _sips._tcp.im2.domA.tld. 1200 IN SRV 0 0 5061 im2.domA.tld. > _sips._tcp.im2.domA.tld. 1200 IN SRV 1 0 15061 im2.domA.tld. > _sips._tcp.im2.domA.tld. 1200 IN SRV 2 0 5061 im1.domA.tld. > _sips._tcp.im2.domA.tld. 1200 IN SRV 3 0 15061 im1.domA.tld. > ; And multiple XMPP services are configured > ; similar to above SIP services: > _xmpp-client._tcp.domA.tld. 900 IN SRV 0 0 5222 im1.domA.tld. > _xmpp-client._tcp.domA.tld. 900 IN SRV 1 0 5222 im2.domA.tld. > _xmpp-client._tcp.domA.tld. 900 IN SRV 2 0 15222 im1.domA.tld. > _xmpp-client._tcp.domA.tld. 900 IN SRV 3 0 15222 im2.domA.tld. > _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 0 0 5222 im1.domA.tld. > _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 1 0 15222 im1.domA.tld. > _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 2 0 5222 im2.domA.tld. > _xmpp-client._tcp.im1.domA.tld. 900 IN SRV 3 0 15222 im2.domA.tld. > _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 0 0 5222 im2.domA.tld. > _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 1 0 15222 im2.domA.tld. > _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 2 0 5222 im1.domA.tld. > _xmpp-client._tcp.im2.domA.tld. 900 IN SRV 3 0 15222 im1.domA.tld. > _xmpp-server._tcp.domA.tld. 1800 IN SRV 0 0 5269 im1.domA.tld. > _xmpp-server._tcp.domA.tld. 1800 IN SRV 1 0 5269 im2.domA.tld. > _xmpp-server._tcp.domA.tld. 1800 IN SRV 2 0 15269 im1.domA.tld. > _xmpp-server._tcp.domA.tld. 1800 IN SRV 3 0 15269 im2.domA.tld. > _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 0 0 5269 im1.domA.tld. > _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 1 0 15269 im1.domA.tld. > _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 2 0 5269 im2.domA.tld. > _xmpp-server._tcp.im1.domA.tld. 1800 IN SRV 3 0 15269 im2.domA.tld. > _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 0 0 5269 im2.domA.tld. > _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 1 0 15269 im2.domA.tld. > _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 2 0 5269 im1.domA.tld. > _xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 3 0 15269 im1.domA.tld. > ; Skipping rest of SIP related SRV declarations. > ; And multiple IRC services are configured > ; similar to above SIP/XMPP services. > _irc._tcp.domA.tld. 1800 IN SRV 0 0 6667 im1.domA.tld. > _irc._tcp.domA.tld. 3600 IN SRV 1 0 6667 im2.domA.tld. > _irc._tcp.domA.tld. 3600 IN SRV 2 0 6669 im1.domA.tld. > _irc._tcp.domA.tld. 3600 IN SRV 3 0 6669 im2.domA.tld. > _irc._tcp.im1.domA.tld. 1800 IN SRV 0 0 6667 im1.domA.tld. > _irc._tcp.im1.domA.tld. 3600 IN SRV 1 0 6669 im1.domA.tld. > _irc._tcp.im1.domA.tld. 3600 IN SRV 2 0 6667 im2.domA.tld. > _irc._tcp.im1.domA.tld. 3600 IN SRV 3 0 6669 im2.domA.tld. > _irc._tcp.im2.domA.tld. 1800 IN SRV 0 0 6667 im2.domA.tld. > _irc._tcp.im2.domA.tld. 3600 IN SRV 1 0 6669 im2.domA.tld. > _irc._tcp.im2.domA.tld. 3600 IN SRV 2 0 6667 im1.domA.tld. > _irc._tcp.im2.domA.tld. 3600 IN SRV 3 0 6669 im1.domA.tld. > ; Skipping rest of IRC related SRV declarations. > ; Skipped/omitted other DNS RRs. > ; RRSIGs are not mentioned, but they exist when DNSSEC signed. > > Multiple SRV are for load-balancing, etc purpose. And used for > forwarding client/traffic toward different/other server & service, > when/if one of them is down or heavily loaded. > > And TLS / SSL cert full chain componenets: > EE/Server {s1, s2, im1, im2, www, m} > \ <-- IA {domA.tld} > \ <-- CA/TA {Root-CA}. > > And here are TLSA related RRs, > after incorporating CNAME logic: > > _443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt > _443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www-domA-crt > _443._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt > _443._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m-domA-crt > s1._s.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt > s1._s.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt > s2._s.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt > s2._s.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt > _25._tcp.s1.domA.tld. 360 IN CNAME s1._s.domA.tld. > _25._tcp.s2.domA.tld. 360 IN CNAME s2._s.domA.tld. > _587._tcp.s1.domA.tld. 360 IN CNAME s1._s.domA.tld. > _587._tcp.s2.domA.tld. 360 IN CNAME s2._s.domA.tld. > _993._tcp.s1.domA.tld. 360 IN CNAME s1._s.domA.tld. > _993._tcp.s2.domA.tld. 360 IN CNAME s2._s.domA.tld. > ; Skipping SMTP (Port 26) based 3rd email-server. > im1._im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt > im1._im.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im1-domA-crt > im2._im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt > im2._im.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im2-domA-crt > _5061._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _15061._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _5061._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _15061._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _5223._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _15223._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _5223._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _15223._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _5269._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _15269._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _5269._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _15269._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _6697._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _6699._tcp.im1.domA.tld. 900 IN CNAME im1._im.domA.tld. > _6697._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > _6699._tcp.im2.domA.tld. 900 IN CNAME im2._im.domA.tld. > > = 12 TLSA lines/rr, and 22 related CNAME lines/rr. > = 34 total TLSA related lines/rr. > > (previously, without using CNAME, > this config used 48 TLSA lines/rr, > where each line had TLSA RR). > > And if a ZO (zone-operator) or a domain-owner (D-O) wants to, then > he/she/they can combine & reduce servers and services, by moving all > "im1" services into "s1", and by moving all services from "im2" into > "s2", then there will be even lesser amount of DNS records, but > quality of services will be lower/slower, unless related hardware > and configuration has enough capacity. > A ZO or D-O can do opposite as well: start all on a single or two > machines, and then, move services out to other server, when more > resource assignment will be necessary. > > I could not find usefulness of DNAME or a way to use it for this > specific configuration, without loosing current simple > load-balancing features/advantages. > > But when ZO will add/use/link second domain-name "domB.tld." or > other domain-name based services, on same set of machines, (or on > different set of machines), then DNAME & CNAME could be very useful. > > Wanted to declare even Intermediate TLS/SSL certs ("TLSA u s 1"), to > reduce (related/any-more/further) confusions, but there is now no > way to clearly specify in TLSA which cert is after what in a TLS/SSL > chain. > > Is it a right assessment, that, this type of CNAME or DNAME > forwarding/replacing will need to be supported by DANE-aware > client-software, and also supported by the Full DNSSEC based > DNS-Resolver/DNS-Server which will be used by users in client-side, > for these to work properly. > > Please correct the wrong DNS/zone declarations. > > Thanks in advance, > -- Bright Star. > > > > > Received from Olafur Gudmundsson, on 2013-06-26 5:47 AM: >> >> On Jun 25, 2013, at 11:31 AM, Bry8 Star <[email protected]> wrote: >> >>> When specifying multiple DANE TLSA records for various TLS / SSL >>> supported encrypted communication: >>> >>> Then, if each service port has Two TLSAs, where, one "TLSA 2 s m" >>> (or one "TLSA 0 s m") RR is for declaring Root-CA or TA TLS/SSL >>> cert, and, another "TLSA 1 s m" (or one "TLSA 3 s m") is for >>> declaring EE/Server TLS/SSL cert. >>> >>> Then, it results into lot of same "TLSA 2 s m" (or "TLSA 0 s m") RR >>> for all those services/ports. >>> >>> And, if only one TLSA is declared for each service/port, even then, >>> it results into lot of exact same C_A_D. >>> >>> What can be done to reduce it ? >> >> As Victor notes CNAME is an obvious solution, and it should be the >> recommended solution as >> it will decrease maintenance if done properly, as when the TLSA records need >> to change that change is done in one place in one zone and all >> the other names inherit the change. >> >> For each service there should be a SINGLE target that everyone points to, >> i.e. keeping CNAME chains at length 1 >> as much as possible. >> >> If multiple services "share" a crypto context that should be reflected by >> having having the services "SINGLE" target point >> to the master context i.e. keeping the chains at length 2, what this does is >> if at a later point the sharing is undone only the >> "SINGLE" target for the service needs to be updated. >> >> The same can be done for SRV records instead of replicating them in all the >> different locations have CNAME to a "master" location. >> >> A more radical solution is to replace to place DNAME at _tcp when a name >> like _tcp.www.<domain> has a subset of the >> names at _tcp.<domain> >> Note you can not place DNAME at _nnn._tcp….. as the rewrite rule only work >> at names below the DNAME. >> >> Olafur >> > > > > > Received from Viktor Dukhovni, on 2013-06-25 10:12 AM: >> >> On Tue, Jun 25, 2013 at 08:31:04AM -0700, Bry8 Star wrote: >> >>> Then, if each service port has Two TLSAs, where, one "TLSA 2 s m" >>> (or one "TLSA 0 s m") RR is for declaring Root-CA or TA TLS/SSL >>> cert, and, another "TLSA 1 s m" (or one "TLSA 3 s m") is for >>> declaring EE/Server TLS/SSL cert. >> > > <snip/> > >> >> When using the same TA for multiple services, or the same EE public >> key for multiple services, you can consolidate TLSA RRs via CNAMEs, >> for example (real life): >> >> _25._tcp.open.nlnetlabs.nl. IN CNAME 3.1.1._dane.nlnetlabs.nl. >> 3.1.1._dane.nlnetlabs.nl. IN TLSA 3 1 1 >> 0D1FCBD71686199607A132744A4918FC209565C91FA8E9FFEEA0AAFD6B9305F6 >> >>> So, instead of specifying TLSA for same TA crt like this example, in >>> a zone file: >>> >>> _443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt >> >> Remember to include the full trust anchor certificate in the server's >> chain file, since clients can't reconstruct the certificate from >> its digest. >> > > <snip/> > > > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
