DNSSEC, TLSA and DANE

[edvanleeuwen]

The script does not work for me.
I get an error:

[root@web custom]# ./set_tlsa.sh domain.nl user
This domain does not have DNSSEC active. Skipping TLSA.

But DNSSEC is active! Tested with internet.nl. I also tested it with https://dnssec-analyzer.verisignlabs.com/domain and this gives all green flags.

What is going wrong?

Check if you have /etc/named.conf or /etc/bind/named.conf. And change the NCONF entry in set_tlsa accordingly.

 

[webcraft]

If anyone was trying to use this script:

https://help.directadmin.com/item.php?id=2093

I've updated it on Feb 5th, 2020, to use the X3 cross-signed certs. Hopefully that helps solve some confusion.

Can you add a dnssec setting for domains so that those which do not have it activated will be skipped by the script?

 

[jordivn]

For the ones interessted
This one gives me an green bar at https://www.huque.com/bin/danecheck-smtp

#!/bin/sh

DOMAIN=$1
USER=`cat /etc/virtual/snidomains | grep "^$DOMAIN" | cut -d':' -f2`
echo "Users is $USER"

TQ=/usr/local/directadmin/data/task.queue
DTQ=/usr/local/directadmin/dataskq

if [ "${DOMAIN}" = "" ] || [ ! -d /etc/virtual/$DOMAIN ]; then
       echo "$DOMAIN is not a valid domain";
       exit 1;
fi

#F=lets-encrypt-x2-cross-signed.pem
#F=lets-encrypt-x1-cross-signed.pem
#F=lets-encrypt-x3-cross-signed.pem
#wget -O $F https://letsencrypt.org/certs/$F
#F=`cat /usr/local/directadmin/data/users/$USER/domains/$DOMAIN.cert.combined`
V=`openssl x509 -in /usr/local/directadmin/data/users/$USER/domains/$DOMAIN.cert.combined -outform DER | openssl dgst -sha256 -hex | awk '{print "3 0 1", $NF}'`

echo "Value is: $V"

#R= `openssl s_client -brief -starttls smtp -dane_tlsa_domain mail.$DOMAIN -dane_tlsa_rrdata $V -connect mail.$DOMAIN:25`

#echo "$R"


#exit;
#clear the old le-ca
echo "action=dns&do=delete&domain=${DOMAIN}&type=TLSA&name=_443._tcp.mail.$DOMAIN.&value=*" >> ${TQ}
echo "action=dns&do=delete&domain=${DOMAIN}&type=TLSA&name=_443._tcp.$DOMAIN.&value=*" >> ${TQ}
echo "action=dns&do=delete&domain=${DOMAIN}&type=TLSA&name=_443._tcp.www.$DOMAIN.&value=*" >> ${TQ}
echo "action=dns&do=delete&domain=${DOMAIN}&type=TLSA&name=_25._tcp.mail.$DOMAIN.&value=*" >> ${TQ}
echo "action=dns&do=delete&domain=${DOMAIN}&type=TLSA&name=_25._tcp.$DOMAIN.&value=*" >> ${TQ}

#adding
echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_443._tcp.mail.$DOMAIN.&value=$V" >> ${TQ}
echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_443._tcp.$DOMAIN.&value=$V" >> ${TQ}
echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_443._tcp.www.$DOMAIN.&value=$V" >> ${TQ}
echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_25._tcp.mail.$DOMAIN.&value=$V" >> ${TQ}
echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_25._tcp.$DOMAIN.&value=$V" >> ${TQ}

echo 'action=named&value=reload' >> ${TQ}

exit 0;

 

[Driesp]

Hi

The system does not take the DNS TTL into account when rolling over a TLSA record.
It should be okay while the chain certificates stay the same, but when the chain certificates change, the DANE verification could fail while the old TLSA records' TTL is not yet expired.
I also don't know if it would be possible to implement this unless using a lower TTL for the TLSA records.
Its something one should consider before using this implementation.

The DNSSEC implementation in DirectAdmin is a bit risky I think. I would not implement this for our clients.
I would rather implement DNSSEC ourselves running it on our slave nameservers, using inline signing.
With DirectAdmin, the client has the ability to disable and enable DNSSEC at will.
If the client does not know what they are doing, their domain will be offline when they disable DNSSEC while the DS record is still in the parent or the TTL of the DS record is not yet expired.

Kind regards
Dries