Subject: [dane] How to Reduce Multiple TA/CA "2 s m"/"0 s m" Or Same C_A_D TLSAs Using Wildcard TLSA

From: Bry8 Star <[email-masked]>
Date: Tue, 25 Jun 2013 08:31:04 -0700

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 ?

C_A_D = Certificate Association Data.
SLD = Second/2nd Level Domain.
TLD = Top Level Domain.
[x] = The portion inside 3rd-Brace is optional. Depends on user's
own preferences.
TTL = Time To Live.
[host.] = Third/3rd Level Domain / Service Domain / Hostname.
EE = End Entity. Here, its used to indicate toward a service in a
server.
IA = Intermediate Authority.
CA = Certificate Authority.
TA = Trust Anchor.

I see RFC 6698 Section A.2.1.3. (Provisioning TLSA Records with
Wildcards) showing common location can be

*._tcp.host.SLD.TLD. IN TLSA u s m C_A_D

It can also be written like these:

_port._proto.[host.]SLD.TLD. [TTL] IN TLSA u s m C_A_D
*._proto.[host.]SLD.TLD. [TTL] IN TLSA u s m C_A_D

And such TLS / SSL cert chain is in use:

EE/Server <-- IA <-- CA/TA.
or,
Level-0 <- Level-1 <- Level-2.
or,
EE/Server {s1, s2, im1, im2, www, m} <-- IA (domA.tld) <-- CA/TA
(Root-CA).

A zone file:

domA.tld. 3600 IN SOA s1.domA.tld. hostmaster.domA.tld. 2013052910
18000 3600 864000 3600
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
im.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
im.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.
_xmpp-client._tcp.domA.tld. 900 IN SRV 0 0 5222 im.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 im.domA.tld.
_xmpp-client._tcp.domA.tld. 900 IN SRV 3 0 15222 im2.domA.tld.
_xmpp-client._tcp.im.domA.tld. 900 IN SRV 0 0 5222 im.domA.tld.
_xmpp-client._tcp.im.domA.tld. 900 IN SRV 1 0 15222 im.domA.tld.
_xmpp-client._tcp.im.domA.tld. 900 IN SRV 2 0 5222 im2.domA.tld.
_xmpp-client._tcp.im.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 im.domA.tld.
_xmpp-client._tcp.im2.domA.tld. 900 IN SRV 3 0 15222 im.domA.tld.
_xmpp-server._tcp.domA.tld. 1800 IN SRV 0 0 5269 im.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 im.domA.tld.
_xmpp-server._tcp.domA.tld. 1800 IN SRV 3 0 15269 im2.domA.tld.
_xmpp-server._tcp.im.domA.tld. 1800 IN SRV 0 0 5269 im.domA.tld.
_xmpp-server._tcp.im.domA.tld. 1800 IN SRV 1 0 15269 im.domA.tld.
_xmpp-server._tcp.im.domA.tld. 1800 IN SRV 2 0 5269 im2.domA.tld.
_xmpp-server._tcp.im.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 im.domA.tld.
_xmpp-server._tcp.im2.domA.tld. 1800 IN SRV 3 0 15269 im.domA.tld.
; And multiple SIP services are configured
; similar to above XMPP services.
_sip._tcp.domA.tld. 1200 IN SRV 0 0 5060 im.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 im.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 im.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 im.domA.tld.
_sips._tcp.domA.tld. 1200 IN SRV 3 0 15061 im2.domA.tld.
; Skipping rest of SIP related SRV declarations.
_irc._tcp.domA.tld. 1800 IN SRV 0 0 6667 im.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 im.domA.tld.
_irc._tcp.domA.tld. 3600 IN SRV 3 0 6669 im2.domA.tld.
_irc._tcp.im.domA.tld. 1800 IN SRV 0 0 6667 im.domA.tld.
_irc._tcp.im.domA.tld. 3600 IN SRV 1 0 6669 im.domA.tld.
_irc._tcp.im.domA.tld. 3600 IN SRV 2 0 6667 im2.domA.tld.
_irc._tcp.im.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 im.domA.tld.
_irc._tcp.im2.domA.tld. 3600 IN SRV 3 0 6669 im.domA.tld.
; Skipping rest of IRC related SRV declarations.;
; RRSIGs are not mentioned, but they exist when DNSSEC signed.

Here, "im" & "im2" both host are running same software based
services, on multiple ports, for slightly better traffic handling,
for slightly better QoS, and for load-balancing, and to overcome few
other software limitations.

What is the secure port 5223's service name ? of _xmpp-client (Port
5222).

What is the secure port 6697's service name ? of _irc (Port 6667).

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
_443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www_domA_srvr-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_srvr-crt
_25._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_25._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1_domA_srvr-crt
_25._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_25._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2_domA_srvr-crt
_587._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_587._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1_domA_srvr-crt
_587._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_587._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2_domA_srvr-crt
_993._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_993._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1_domA_srvr-crt
_993._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_993._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2_domA_srvr-crt
_5223._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_5223._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15223._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_15223._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5223._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_5223._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15223._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_15223._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5269._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_5269._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15269._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_15269._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5269._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_5269._tcp.im2.domA.tld. 900 IN TLSA 1 0 0 C_A_D_of_im_domA_srvr-crt
_15269._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_15269._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5061._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_5061._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15061._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_15061._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5061._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_5061._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15061._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_15061._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_6697._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_6697._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_6699._tcp.im.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_6699._tcp.im.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_6697._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_6697._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_6699._tcp.im2.domA.tld. 900 IN TLSA 2 0 1 C_A_D_of_TA-crt
_6699._tcp.im2.domA.tld. 900 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt

= 48 lines.

(Practical/real servers, which uses service location dns SRV
declarations, for running multiple services on same machine, or,
pointing toward multiple services on different machines, have much
more such service ports, and will result into declaring same C_A_D
again and again).

Can those be implemented in common location like this (alternative)
example ?

*._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_srvr-crt
*._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_srvr-crt
*._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_25._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt
_587._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt
_993._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt
*._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_25._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt
_587._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt
_993._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_mail_domA_srvr-crt
*._tcp.im.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_6697._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_6699._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5223._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15223._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5269._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15269._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5061._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15061._tcp.im.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
*._tcp.im2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_6697._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_6699._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5223._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15223._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5269._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15269._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_5061._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt
_15061._tcp.im2.domA.tld. 360 IN TLSA 1 0 2 C_A_D_of_im_domA_srvr-crt

= 30 lines.

And here, "im" host is using only one EE/Server TLS/SSL cert for its
all encrypted services, (and so is "im2", "s1", "s2", "www" hosts),
so can we reduce TLSA DNS declarations even further, like this ?

*._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
*._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www_domA_srvr-crt
*._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
*._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m_domA_srvr-crt
*._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
*._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1_domA_srvr-crt
*._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
*._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2_domA_srvr-crt
*._tcp.im.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
*._tcp.im.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_im_domA_srvr-crt
*._tcp.im2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
*._tcp.im2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_im2_domA_srvr-crt

= 12 lines.

Here "TLSA 1 s m" EE is used (instead of "TLSA 3 s m" EE), to
instruct/indicate client-side, that they must check full TLS/SSL
chain for this EE/Server TLS/SSL cert, (if client's user also have
similar preference settings).

(Based on my own limited understanding in this/these case), One of
the way to say it, or, domain-owner is trying to say in this case :
Hey TLSA/DANE-aware clients, first get EE/server TLS-cert, for
example, for port 5223, from "TLSA 1 s m" DNS record and also from
server's TLS secured port 5223, if it is a EE/Servr cert under
another Root-CA or Intermediate cert, then in second-step,  check
at-first, if the same port (5223) have a "TLSA 2 s m" TA RR or a
"TLSA 0 s m" CA RR present or not ? If yes/present, check validity
of "TLSA 1 s m" based EE/Servr TLS cert and its chain,  But if same
port (5223) does not have a "TLSA 2 s m" or "TLSA 0 s m", then check
in-second, for a TLSA in common location like
"*._tcp.host.domain.tld." or in "*._tcp.domain.tld.", if found,
check validity of Root-CA/TA/IA TLS-cert, and the EE TLS cert under
it nad also check validity of TLS cert chain. And then on success,
finally use EE/Servr TLS cert for encrypted communication for port
5223 based XMPP service.

So my understanding, it will work, or be effective, only when
DANE/TLSA-aware clients supports such/similar logic based
provisional checking (or wildcard based checking).

Is wildcard TLSA yet supported by any client-side ?

Do "Extended DNSSEC Validator" addon for Firefox, or, Bloodhound
browser (based on Firefox) understands & uses it (wildcard TLSA) to
create TLS/SSL encrypted communication ? or, can they even use
wildcard TLSA and DANE-logics/protocols yet ?

Or, should i add nameserver functionality in each server, like "im1"
and "im2" as well ? (like "s1" & "s2") and then define only "im" or
"im2" sub-domain zone file with related DNS RR set only ? then main
zone file's DNS rr can be reduced. And if wanted, wilcard usage can
be avoided.

Or, what alternative solution exist ?

Please point out mistakes, errors, and, specify what is correct.

Thanks in advance.
-- Bright Star.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Jun 2013 17:12:24 +0000

> declaring EE/Server TLS/SSL cert.

Pick one model.  Either publish TA associations (0 or 2) or EE
associations (1 or 3).  It makes little sense to publish both for
any given service end-point.

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

> _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.

> _443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www_domA_srvr-crt

DO NOT publish "0 0 0", "1 0 0", "2 0 0", or "3 0 0" full certificates
in DNS.  Such RRs cannot reliably be queried by clients.

-- 
	Viktor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 26 Jun 2013 08:47:40 -0400

> 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

---

From: Bry8 Star <[email-masked]>
Date: Wed, 26 Jun 2013 17:56:43 -0700

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.

>> declaring EE/Server TLS/SSL cert.

<snip/>

> chain file, since clients can't reconstruct the certificate from

<snip/>

---

From: Bry8 Star <[email-masked]>
Date: Thu, 27 Jun 2013 13:08:53 -0700

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.

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:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Jun 2013 22:14:43 +0000

> _60._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt

Publishing "1 0 0" is unwise, full certificates are too big for
publishing via DNS.  Also publishing both a TA and and EE association
is unwise.  Pick one of "0 0 1", "1 0 1", "2 0 1" or "3 0 1":

    2.0.1.tlsa.example.com. IN TLSA 2 0 1 <TA-certificate-SHA256-digest>

A trust anchor can be shared across multiple hosts, and multiple services:

    _25._tcp.mx1.example.com. IN CNAME 2.0.1.tlsa.example.com.
    _25._tcp.mx2.example.com. IN CNAME 2.0.1.tlsa.example.com.
    _143._tcp.imap.example.com. IN CNAME 2.0.1.tlsa.example.com.

> 5223, and on success, establish encrypted and authenticated

The "2 0 1" is enough, no need for "1 0 0". Each service chain file
needs to also include the TA certificate and any intermediate
certificates betweent the TA and the server leaf cert.

> it more secured and encrypted?

The data in DNS is public-key data.  There is nothing to encrypt.

> How to add more declarations to

Add fewer declarations to publish just the current and (when rotating
keys) upcoming certificate association for a single carefully chosen
(usage, selector, matching-type), and generally use matching type
1, with selector 1 as most likely to be stable and compact.

> Need to understand more on NSEC.

You shouldn't need to, the NSEC or NSEC3 records are generated
automatically by the software that signs your zone file.

If NSEC3 support is not yet universal, you may need to tell this
software to use NSEC in preference to NSEC3 until NSEC3 support is
(effectively) universal.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Jun 2013 10:29:23 +1000

In message <[email-masked]>, Viktor Dukhovni writ
> software to use NSEC in preference to NSEC3 until NSEC3 support is

Truly, one shouldn't use NSEC3 unless one has a need to use NSEC3.
It is much more expensive on servers and clients.  For most zones
NSEC is all that is needed.  For some zones NSEC is the only thing
that will work.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Bry8 Star <[email-masked]>
Date: Fri, 28 Jun 2013 07:32:47 -0700

THANKS for all the help as always, and for very very helpful
suggestions toward improving this "specific" (not regular purpose)
configuration.

Reconfiguring based on Viktor's last post's suggestion (suggestion
which are suitable and correct for this specific, (not a regular,)
configuration, and suitable with its objectives), and also
extending/improving my own previous configuration, and so, here is
another reduced edition:

This system now (still) using 4 servers: S-1, S-2, IM-1, IM-2.  If
anyone wants to, can transfer IM-1 server's all services inside S-1
server, and transfer IM-2 services inside S-2, if they have enough
resources for providing all services.  Then various DNS RRs can be
reduced even further.

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 targeted+geared for "more secured"
; and "higher strength" encrypted services, above will
; be changed: dnskey's strength will be increased.
; Skipping NSEC3. As DNSSEC management software,
; can handle it automatically.
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 AAAA IP::ADRS_S-1_IPv6
domA.tld. 300 IN AAAA IP::ADRS_S-2_IPv6
; IP-address of "s" will be "round-robin" based:
s.domA.tld. 300 IN A    IP.ADRS_S-1_IPv4
s.domA.tld. 300 IN A    IP.ADRS_S-2_IPv4
s.domA.tld. 300 IN AAAA IP::ADRS_S-1_IPv6
s.domA.tld. 300 IN AAAA IP::ADRS_S-2_IPv6
s1.domA.tld. 900 IN A    IP.ADRS_S-1_IPv4
s2.domA.tld. 900 IN A    IP.ADRS_S-2_IPv4
s1.domA.tld. 900 IN AAAA IP::ADRS_S-1_IPv6
s2.domA.tld. 900 IN AAAA IP::ADRS_S-2_IPv6
; IP-address of "im" will be "round-robin" based:
im.domA.tld. 300 IN A    IP.ADRS_S-IM-1_IPv4
im.domA.tld. 300 IN A    IP.ADRS_S-IM-2_IPv4
im.domA.tld. 300 IN AAAA IP::ADRS_S-IM-1_IPv6
im.domA.tld. 300 IN AAAA IP::ADRS_S-IM-2_IPv6
im1.domA.tld. 900 IN A    IP.ADRS_S-IM-1_IPv4
im2.domA.tld. 900 IN A    IP.ADRS_S-IM-2_IPv4
im1.domA.tld. 900 IN AAAA IP::ADRS_S-IM-1_IPv6
im2.domA.tld. 900 IN AAAA IP::ADRS_S-IM-2_IPv6
; IP-address of "s" will be "round-robin" based:
www.domA.tld. 300 IN CNAME s.domA.tld.
m.domA.tld. 300 IN CNAME s.domA.tld.
_http._tcp.domA.tld. 300 IN SRV 0 0 80 www.domA.tld.
_https._tcp.domA.tld. 300 IN SRV 0 0 443 www.domA.tld.
_http._tcp.www.domA.tld. 300 IN SRV 0 0 80 www.domA.tld.
_https._tcp.www.domA.tld. 300 IN SRV 0 0 443 www.domA.tld.
_http._tcp.m.domA.tld. 300 IN SRV 0 0 80 m.domA.tld.
_https._tcp.m.domA.tld. 300 IN SRV 0 0 443 m.domA.tld.
domA.tld. 300 IN MX 10 s.domA.tld.
domA.tld. 1800 IN MX 20 s1.domA.tld.
domA.tld. 1800 IN MX 20 s2.domA.tld.
_smtp._tcp.domA.tld. 300 IN SRV 10 0 25 s.domA.tld.
_smtp._tcp.s.domA.tld. 300 IN SRV 10 0 25 s.domA.tld.
_smtp._tcp.s.domA.tld. 1800 IN SRV 20 0 25 s1.domA.tld.
_smtp._tcp.s.domA.tld. 1800 IN SRV 30 0 25 s2.domA.tld.
_submission._tcp.domA.tld. 300 IN SRV 10 0 587 s.domA.tld.
_submission._tcp.s.domA.tld. 1800 IN SRV 10 0 587 s.domA.tld.
_submission._tcp.s.domA.tld. 1800 IN SRV 20 0 587 s1.domA.tld.
_submission._tcp.s.domA.tld. 1800 IN SRV 30 0 587 s2.domA.tld.
_imaps._tcp.domA.tld. 300 IN SRV 0 0 993 s.domA.tld.
_imaps._tcp.s.domA.tld. 300 IN SRV 0 0 993 s.domA.tld.
_imaps._tcp.s.domA.tld. 900 IN SRV 1 0 993 s1.domA.tld.
_imaps._tcp.s.domA.tld. 900 IN SRV 2 0 993 s2.domA.tld.
_pops._tcp.domA.tld. 300 IN SRV 0 0 995 s.domA.tld.
_pops._tcp.s.domA.tld. 300 IN SRV 1 0 995 s.domA.tld.
_pops._tcp.s.domA.tld. 900 IN SRV 2 0 995 s1.domA.tld.
_pops._tcp.s.domA.tld. 900 IN SRV 3 0 995 s2.domA.tld.
; Skipping SMTP (Port 26) based 3rd email-server.
_sip._tcp.domA.tld. 360 IN SRV 0 0 5060 im.domA.tld.
_sip._tcp.domA.tld. 360 IN SRV 1 0 15060 im.domA.tld.
_sip._tcp.im.domA.tld. 360 IN SRV 0 0 5060 im.domA.tld.
_sip._tcp.im.domA.tld. 360 IN SRV 1 0 15060 im.domA.tld.
; Once encrypted Port (5061, 15061) SIP services are working
; completely, then non-encrypted ports will be removed.
_sips._tcp.domA.tld. 360 IN SRV 0 0 5061 im.domA.tld.
_sips._tcp.domA.tld. 360 IN SRV 1 0 15061 im.domA.tld.
_sips._tcp.im.domA.tld. 360 IN SRV 0 0 5061 im.domA.tld.
_sips._tcp.im.domA.tld. 360 IN SRV 1 0 15061 im.domA.tld.
; And multiple XMPP services are configured
; similar to above SIP services:
_xmpp-client._tcp.domA.tld. 360 IN SRV 0 0 5222 im.domA.tld.
_xmpp-client._tcp.domA.tld. 360 IN SRV 1 0 15222 im.domA.tld.
_xmpp-client._tcp.im.domA.tld. 360 IN SRV 0 0 5222 im.domA.tld.
_xmpp-client._tcp.im.domA.tld. 360 IN SRV 1 0 15222 im.domA.tld.
; Skipping 4 lines (secured sip client port 5223, 15223).
; Once encrypted Port (5223, 15223) XMPP services are working
; completely, then non-encrypted ports will be removed.
_xmpp-server._tcp.domA.tld. 360 IN SRV 0 0 5269 im.domA.tld.
_xmpp-server._tcp.domA.tld. 360 IN SRV 1 0 5269 im.domA.tld.
_xmpp-server._tcp.im.domA.tld. 360 IN SRV 0 0 5269 im.domA.tld.
_xmpp-server._tcp.im.domA.tld. 360 IN SRV 1 0 15269 im.domA.tld.
; Skipping rest of XMPP related SRV declarations.
; And multiple IRC services are configured
; similar to above SIP/XMPP services.
_irc._tcp.domA.tld. 360 IN SRV 0 0 6667 im.domA.tld.
_irc._tcp.domA.tld. 360 IN SRV 1 0 6669 im.domA.tld.
_irc._tcp.im.domA.tld. 360 IN SRV 0 0 6667 im.domA.tld.
_irc._tcp.im.domA.tld. 360 IN SRV 1 0 6669 im.domA.tld.
; Skipping 4 lines (secured IRC port 6697, 6699).
; Once encrypted Port (6697, 6699) IRC services are working
; completely, then non-encrypted ports will be removed.
; Skipped/omitted other DNS RRs.
; RRSIGs are not mentioned, but they exist when DNSSEC signed.

= 70 lines of common DNS RRs.

In previous config there were 113 lines of common DNS RRs.

What is the common service name for the secure port (5223) of
xmpp-client ?

What is the common service name for the secure port of (6697) od IRC ?

And TLS / SSL cert full chain components:
EE/Server {s, im, www, m}
	\ <-- IA {domA.tld}
		\ <-- CA/TA {Root-CA}.

Higher strength TLS/SSL cert.

And here are TLSA/DANE related DNS RRs:

_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.
; And, using such form of TLSA makes more sense:
; _port._proto.zone. [TTL] IN TLSA u s m C_A_D
_60._tcp.s.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_60._tcp.s.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s-domA-crt
_25._tcp.s.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_25._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_25._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_587._tcp.s.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_587._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_587._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_993._tcp.s.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_993._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_993._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
; Skipping SMTP (Port 26) based 3rd email-server.
_60._tcp.im.domA.tld. 300 IN TLSA 2 0 1 C_A_D_of_TA-crt
_60._tcp.im.domA.tld. 300 IN TLSA 1 0 0 C_A_D_of_im-domA-crt
_5061._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_15061._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_5223._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_15223._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_5269._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_15269._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_6697._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_6699._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.

= 8 TLSA lines/rr, and 17 related CNAME lines/rr.
= 25 total TLSA related lines/rr.

In previous configuration, there were 12 TLSA lines/rr, and 22
related CNAME lines/rr, so in total 34 total TLSA related lines/rr.

May be i should use "*" instead of "_60". Should carry more correct
meaning & intention.

Now showing few other declared components:

gpg --export [email-masked] > \
	domA-signing_GPG_KEY-ID.pubkey.bin

make-dns-cert -n domA-signing.domA.tld. \
	-k domA-signing_GPG_KEY-ID.pubkey.bin > \
	domA-signing_GPG_KEY-ID.pub.big.cert

Then codes from "domA-signing_GPG_KEY-ID.pub.big.cert" file can be
placed in zone file, such as below DNS RR, in place of <full_GPG-KEY>.

Publish/Declare public-side portion of GPG-KEY.  Do not share
private key side.  Here "full_GPG-KEY" = "Entire GPG/PGP-KEY's
binary code", used in zone file, with it's equivalent hexadecimal
code form (RFC 3548).

FPR = fpr = Fingerprint.

When files, software are signed with GPG/PGP-KEY, which is
associated with "[email-masked]" and "[email-masked]"
email-addresses, then, (based on RFC 4398) :

domA-signing.domA.tld. 1800 IN CERT PGP 0 0 <full_GPG-KEY>
file-signing.domA.tld. 1800 IN CNAME domA-signing.domA.tld.
HEX-CODE-of-FULL-GPG-KEY-FINGERPRINT 1800 IN CERT PGP 0 0 <full_GPG-KEY>
HEX-CODE-of-SHORT-GPG-KEY-FINGERPRINT 1800 IN CERT PGP 0 0
<full_GPG-KEY>

; Declaring a developer's GPG-KEY:

developer.name.domA.tld. 1800 IN CERT PGP 0 0 <full_GPG-KEY>

If GPG-KEY associated with this above "[email-masked]"
email-adrs has this HEX-CODE-of-FULL-GPG-KEY-FINGERPRINT, then add
another DNS RR:

HEX-CODE-of-FULL-GPG-KEY-FINGERPRINT 1800 IN CERT PGP 0 0 <full_GPG-KEY>

Objective is to allow client-side users to get authentic &
pre-declared (public-key portion of) signing GPG-KEY from DNSSEC
based response, and verify downloaded files with it.  Many websites
still do not share their GPG-KEY in their DNS, and GPG-KEY text
files are either on a non-encrypted HTTP (port 80) based web-page !
or, on an encrypted HTTPS (port 443) based webpage, but SSL cert is
not declared in TLSA DNS RR !

Caution on CERT, TLSA and other DNS records which have slightly
larger data : Each single active line in DNS, (or, The RDATA field
in EACH dns RR (resource record) in DNS protocol) may hold upto
65535 octets (64kb) or less data/payload size.  So do not exceed
that, in any/one line.

; SSHFP: RFC 6594, 4255, 5656, 4716:
; do not use SHA-1 based SSH-keys:
s1.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key
s2.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key
im1.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key
im2.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key

Received from Viktor Dukhovni, on 2013-06-27 3:14 PM:> On Thu, Jun
>     2.0.1.tlsa.example.com. IN TLSA 2 0 1 <TA-certificate-SHA256-digest>

I think, What you are suggesting is not accurate for this specific
configuration.  In below is my "own" explanation of why:

ZO = Zone Operator . D-O = Domain-Owner.

A ZO/D-O type of users must choose what is right for their own
configuration & system, not what i or someone else would suggest
them suddenly without understanding the purpose/objectives & more
details of a configuration and system.

I think, for general configuration and when used for general
purpose, then what you have suggested is best solution.

I think, it will be correct for short time.

When more software and devices will incorporate full DNSSEC and full
DANE support, then combination of two or more TLSA RRs like, "TLSA 2
0 1" and "TLSA 1 0 0", most likely be one of the wise choice.  Usage
of multiple TLSAs, where EE TLSA clearly telling to look for a TA/CA
TLSA, should have clearly indicated that sense to a ZO/D-O and to
client(s) and to others.  Data bandwidth rate will increase day by
day, it will not go down day by day.  Newer software and devices
will incorporate/adopt the next version of DNS, which is DNSSEC, and
will incorporate next version of TLS/SSL solution, which is
DANE/CERT etc, all these entities have no choice, and no reason, for
always and ONLY support only the old-DNS or only support the older
SSL cert technologies, new features must be included and supported,
or else they will be less useful and "old".

A ZO/D-O type of user, for general case/purpose, can remove either
all "TLSA 2 0 1" DNS RRs lines, or, remove all "TLSA 1 0 0" RRs or
change them, and transform or adapt the configuration into what you
are suggesting.  I think, I've already mentioned this previously.
And again now one more time here.

And for this specific configuration/case, neither my server side,
and nor my client-side have any such problem of pulling "big" data
and using it.

Is there a chart/list which shows different TLS cert key-sizes, and
it's respective full TLSA actual binary bytes, that is used in wire ?

But this configuration is (targeted / geared-toward / tuned /
will-be-used) for such users who must use necessary high-quality and
latest components which supports full DNSSEC and supports full DANE.
 Client-side's TLSA/DANE-preference or TLSA/DANE-settings will
forcefully authenticate entire TLS/SSL cert chain's each component
using multiple TLSAs from DNSSEC based response, for creating
"higher" security.  And that is why multiple TLSAs, SSHFP, CERT PGP,
etc and finally, DNSSEC signed zone, are used.  Or else, this
configuration would have used mostly or just regular non-encrypted
ports and may be some encrypted ports, and no DNSSEC, no DANE.

If someone cannot do or have what is required to use these services
(for "whatever" number of reasons and factors), then, i will not
stop or down-grade services just for them !  If someone does not
have a good router and fair amount of Internet bandwidth and a
powerful enough computer, then encrypted IP-Phone service will not
work properly, or not work at all, then go somewhere else.

For email services, non-encrypted ports (_143, _110, etc) are not
even used, and not mentioned in this specific configuration.  Same
will be done for other ports/services, once encrypted services are
working completely, non-encrypted ports will be completely removed
(unless an encrypted service requires it, and even then, any
non-encrypted service will not be allowed to even initiated/started,
as those can loose password and have other vulnerabilities or
weaknesses, not welcome in this system).  This specific
configuration will be used for providing only encrypted connection
based services.  That is why the emphasis on using more and more
TLSA/DANE, and DNSSEC, and other DNS & TLS related technologies.

When a full TLS cert is pulled/received from TLS server, and a full
TLSA (1 0 0) is pulled from DNS, and then comparing full TLS cert
code against the full TLSA (1 0 0) C_A_D, is faster ? or slower ?
than such : a TLS cert is pulled from TLS server, and SHA-256 hash
checksum is calculated, and then TLSA (1 0 1) is pulled from DNS and
checked against TLS cert's hash checksum.  How many computational
total steps are used in a 64-bits multi-core, multi-threaded
computer for these two scenarios ?  Most client-side have such, and,
servers are usually much more powerful.  Bandwidth is not a big
factor for now, (for this configuration's system/server-side, and in
its targeted client-side, both side have very high-speed and
high-bandwidth connections).

So PLEASE instruct and HELP to achieve that "higher" or "more
secured" solution, (slightly slow or slow speed of operations will
be tolerated and ok, but lower security will not be tolerated
at-all), that is what i'm asking for, from the 1st post, so please
help related to that, then that will be the CORRECT help for this
specific configuration.  Other suggestion not achieving goal, are
not right suggestion for this specific configuration.  Someone might
say : i asked for a "more secured" solution where each component is
DNSSEC and DANE authenticated, and using higher encryption strength
TLS certs, then why are you even suggesting wrong things or which is
going to create lower security level or will use un-authenticated or
will use un-declared components !

>     _143._tcp.imap.example.com. IN CNAME 2.0.1.tlsa.example.com.

THANKS, i've now tried to use the idea from this very very helpful
suggestion & help, in topside configuration.  I can definitely apply
the logic on correct ports for this specific configuration : like
_993, _995, _5223 etc.

I should've provided same/one type of service, from a
same/common/shared one service name and provide from all servers,
instead of what i was doing mostly : i used actual (two) server's
hostnames, and used them in/for service hostname for different types
of services.

I was already doing it correctly, but for "www" & "m" services only,
(i was using common service name "www" and a common TLSA for that,
and provide service from both "s1" & "s2" servers using
"round-robin"), and i should have done that for all other services
as well.

Thanks for pointing it out even those remaining mistakes.

> certificates betweent the TA and the server leaf cert.

I think, your this response is also not accurate for this specific
configuration, I'm Not going for and not targeting what is "enough",
objective is/are to reach a more "higher" level of security or "much
more than enough" level of security or close to 100%
authentications.  Client side is/will be configured and forced to
check entire TLS/SSL cert chain's each component, (in regex term)
greedily.  That is why at-least two TLSA RRs are used.  DANE-aware
clients 1st pulls & checks Level-0 / EE / Server TLS/SSL cert,
against the EE TLSA, and here EE TLSA (1 0 0) is clearly indicating
to check EE TLS/SSL cert and it's full TLS/SSL chain (level after
level), and so, eventually, TA TLSA (2 0 1) dns record will be
pulled and checked against Root-CA SSL/TLS cert, and then on
success, the EE SSL/TLS cert will be used for creating encrypted
communication.

One of the best solution would have been, to have all/100%
component(s) of a TLS chain can be authenticated (for this specific
configuration based solution, there are currently 3/three TLS
components and they are defined or pre-declared in multiple (2 or
more) TLSA RRs for each service/port : (1) "www.domA.tld.",
"m.domA.tld.", "s.domA.tld.", "im.domA.tld." etc server SSL/TLS
certs, checked against their respective EE TLSA ("TLSA 1 0 0") DNS
RRs, (2) "domA.tld." IA SSL /TLS cert, checked against it's
respective (1st) IA TLSA (either via "TLSA 4 64 1" or "TLSA 4 64 2")
DNS RRs, (3) Root-CA SSL cert, checked against it's respective TA
TLSA ("TLSA 2 0 1" or "TLSA 2 0 2") DNS RRs.  But now shown &
proposed IA type of TLSA usage is not supported, so now, cannot be
defined, with its exact position, to indicate the IA cert's level
position in a full TLS chain.  And another better feature would have
been, when, Server-side and client-side both could/will pull
all/full Keys/Certs from various DNS records and after successful
authentication, use EE cert for encrypted connection or
communication.  Only server-side will have a priv_key in their
configuration.

for any user, please avoid suggesting which will leave more
components undeclared, or please avoid wrong suggestion for this
specific configuration, where "more secured" level is expected.

> The data in DNS is public-key data.  There is nothing to encrypt.

I made one word mistake here, should have used "system" instead of
"it".  Sorry to create confusion and for using wrong word "it".  I
meant, system which will use this specific DNS/zone configuration,
how can that system's each component be further more DNSSEC (and
DANE, where applicable) authenticated/secured, and how to make or
configure this system's connection & communication encryption more
higher-strength.  DNS/zone records are public and open and
non-encrypted as always.  Unless two zones are used, one for
public/outside/external/dmz view, and one for
inside/non-public/private view.

For such "more secured" configuration & system, should i use all 8
kbits server TLS certs, instead of current 4 kbits server TLS certs,
or, should i switch to ECDSA ?  for SIP (audio-stream) what type of
TLS cert would be better ? for xmpp, irc what type cert would better
?  i think, various TLS cert need to be applied & load-tested to get
a chart.  I have some basic ideas on type of certs, what should be
used in which cases, but may be a discussion or a new discussion can
reveal further and better guidance for different cases/scenarios.

> software to use NSEC in preference to NSEC3 until NSEC3 support is

That is a big relief, THANKS.  Yes, the NSEC3.  My very limited
understanding is NSEC is suffice, but it have some exploits, so
NSEC3 is better.  If name-servers have enough bandwidth &
computation power, then client-side's full DNSSEC-Resolver will be
burdened a lot when NSEC3 is used ? or NSEC is suffice ?

Thanks for your help,
-- Bright Star.