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/>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
