# Quirk with "TLSA records enabled" option and Virtualmin -\> Systems Settings -\> Re-check Configuration

**URL:** <https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032>\
**Category:** Virtualmin\
**Tags:** solved\
**Created:** [July 20, 2024, 4:16am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032 "2024-07-20T04:16:30Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![calport](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/calport/32/44_2.png) [@calport](https://forum.virtualmin.com/u/calport)\
**Post date:** [July 20, 2024, 4:16am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/1 "2024-07-20T04:16:30Z")

</div>

| SYSTEM INFORMATION | |
| --- | --- |
| OS type and version | Debian Linux 11 |
| Webmin version | 2.111 |
| Usermin version | 2.010 |
| Virtualmin version | 7.20.1 |
| Theme version | 21.10 |
| Package updates | All installed packages are up to date |

In Virtualmin → DNS Settings → DNS Options, when “TLSA records enabled” is set to yes but “DNSSEC signature enabled” is set to no, it causes Virtualmin → Systems Settings → Re-check Configuration to display the 'Your system is not ready to be used by Virtualmin".

When “TLSA records enabled” is set to no for all virtual servers, Re-check Configuration shows the usual " **… your system is ready for use by Virtualmin** message.

Perhaps “TLSA records enabled” should be greyed out if “DNSSEC signature enabled” is set to no?

---

<div class="post-metadata">

**Author:** ![Ilia](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/ilia/32/10185_2.png) [@Ilia](https://forum.virtualmin.com/u/Ilia)\
**Post date:** [July 20, 2024, 8:56am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/2 "2024-07-20T08:56:15Z")

</div>

Hello Niel,

Thanks for the heads up!

> [@calport](#):
>
> Perhaps “TLSA records enabled” should be greyed out if “DNSSEC signature enabled” is set to no?

@Jamie, I think we should show an error when trying to save the form with DNS TLSA records enabled, while at the same time having DNSSEC disabled?

---

<div class="post-metadata">

**Author:** ![lawk](https://cdn.forum.virtualmin.com/letter_avatar_proxy/v4/letter/l/dbc845/32.png) [@lawk](https://forum.virtualmin.com/u/lawk)\
**Post date:** [July 20, 2024, 11:06am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/3 "2024-07-20T11:06:32Z")

</div>

TLSA requires DNSSEC to be enabled.

so a re-check pointing out this problem is legit IMO, (if it points to the specific issue).

to prevent it from happening in the first place the UI should not accept TLSA only.

---

<div class="post-metadata">

**Author:** ![calport](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/calport/32/44_2.png) [@calport](https://forum.virtualmin.com/u/calport)\
**Post date:** [July 20, 2024, 11:52am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/4 "2024-07-20T11:52:09Z")

</div>

> [@lawk](#):
>
> to prevent it from happening in the first place the UI should not accept TLSA only.

In other words

> [@calport](#):
>
> Perhaps “TLSA records enabled” should be greyed out if “DNSSEC signature enabled” is set to no?

---

<div class="post-metadata">

**Author:** ![Jamie](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/jamie/32/8589_2.png) [@Jamie](https://forum.virtualmin.com/u/Jamie)\
**Post date:** [July 20, 2024, 3:45pm UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/5 "2024-07-20T15:45:01Z")

</div>

TLSA records can ber added without DNSSEC being enabled though. Sure they are more reliable with DNSSEC, but it’s not strictly required…

---

<div class="post-metadata">

**Author:** ![Ilia](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/ilia/32/10185_2.png) [@Ilia](https://forum.virtualmin.com/u/Ilia)\
**Post date:** [July 20, 2024, 11:11pm UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/6 "2024-07-20T23:11:36Z")

</div>

> [@Jamie](#):
>
> TLSA records can be added without DNSSEC being enabled though. Sure they are more reliable with DNSSEC, but it’s not strictly required…

Doesn’t it defeats the purpose of TLSA? Without DNSSEC, the trustworthiness of TLSA records cannot be assured … right?

Though I agree, in this case, we should not enforce users to enable DNSSEC …

---

<div class="post-metadata">

**Author:** ![Jamie](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/jamie/32/8589_2.png) [@Jamie](https://forum.virtualmin.com/u/Jamie)\
**Post date:** [July 21, 2024, 3:19am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/7 "2024-07-21T03:19:30Z")

</div>

> [@Ilia](#):
>
> Doesn’t it defeats the purpose of TLSA? Without DNSSEC, the trustworthiness of TLSA records cannot be assured … right?

True, but technically it’s possible to add TLSA records even if DNSSEC isn’t enabled.

---

<div class="post-metadata">

**Author:** ![calport](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/calport/32/44_2.png) [@calport](https://forum.virtualmin.com/u/calport)\
**Post date:** [July 21, 2024, 3:46am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/8 "2024-07-21T03:46:28Z")

</div>

> [@Jamie](#):
>
> technically it’s possible to add TLSA records even if DNSSEC isn’t enabled

It is Bind which objects, when that happens, in Re-check Configuration. If we wish to offer this permutation to Virtualmin users, can Recheck Configuration be made to ignore the warnings generated by Bind and go on to the next set of checks that Recheck Configuration performs?

And if not, then as long as Bind generates the warning, that permutation cannot be offered.

Oh, I should also mention that Check BIND Config throws no errors or warnings when we add TLSA records even if DNSSEC isn’t enabled.

---

<div class="post-metadata">

**Author:** ![Jamie](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/jamie/32/8589_2.png) [@Jamie](https://forum.virtualmin.com/u/Jamie)\
**Post date:** [July 21, 2024, 4:08am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/9 "2024-07-21T04:08:24Z")

</div>

Can you post the error message you’re getting from “Re-check Configuration” ?

---

<div class="post-metadata">

**Author:** ![calport](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/calport/32/44_2.png) [@calport](https://forum.virtualmin.com/u/calport)\
**Post date:** [July 21, 2024, 4:16am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/10 "2024-07-21T04:16:16Z")

</div>

This one has TLSA records and DNSSEC isn’t enabled

```auto
Hostname	vps16.indiax.com
System	Linux vps16.indiax.com 5.10.0-31-amd64 #1 SMP Debian 5.10.221-1 (2024-07-14) x86_64 GNU/Linux
Mailbox locking methods
flock
fcntl
dotlock
Supported Lookup Tables
btree
cidr
environ
fail
hash
inline
internal
memcache
nis
pcre
pipemap
proxy
randmap
regexp
socketmap
static
tcp
texthash
unionmap
unix
main.cf

non-default parameters
alias_maps	hash:/etc/aliases
allow_percent_hack	no
append_dot_mydomain	no
biff	no
broken_sasl_auth_clients	yes
compatibility_level	2
home_mailbox	Maildir/
mailbox_command	/usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit	0
message_size_limit	30000000
milter_default_action	accept
mydestination	$myhostname, vps16.indiax.com, localhost.contaboserver.net, localhost
mynetworks	127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin	/etc/mailname
non_smtpd_milters	local:/var/run/milter-greylist/milter-greylist.sock,inet:127.0.0.1:8891
readme_directory	no
recipient_delimiter	+
resolve_dequoted_address	no
sender_bcc_maps	hash:/etc/postfix/bcc
sender_dependent_default_transport_maps	hash:/etc/postfix/dependent
smtp_dns_support_level	dnssec
smtp_tls_CApath	/etc/ssl/certs
smtp_tls_security_level	dane
smtp_tls_session_cache_database	btree:${data_directory}/smtp_scache
smtpd_banner	$myhostname ESMTP $mail_name (Debian/GNU)
smtpd_milters	local:/var/run/milter-greylist/milter-greylist.sock,inet:127.0.0.1:8891
smtpd_recipient_restrictions	permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_policy_service inet:127.0.0.1:10023
smtpd_relay_restrictions	permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_sasl_auth_enable	yes
smtpd_sasl_authenticated_header	yes
smtpd_tls_CAfile	/etc/postfix/postfix.ca.pem
smtpd_tls_cert_file	/etc/postfix/postfix.cert.pem
smtpd_tls_key_file	/etc/postfix/postfix.key.pem
smtpd_tls_mandatory_protocols	!SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_security_level	may
tls_server_sni_maps	hash:/etc/postfix/sni_map
virtual_alias_maps	hash:/etc/postfix/virtual
main.cf

parameters defined as per defaults
alias_database	hash:/etc/aliases
inet_interfaces	all
inet_protocols	all
relayhost	
smtp_host_lookup	dns
smtpd_sasl_security_options	noanonymous
master.cf

service	type	private	unpriv	chroot	wakeup	maxproc	command + args
inet
pickup	
unix
n
-
y
60
1
pickup
cleanup	
unix
n
-
y
-
0
cleanup
qmgr	
unix
n
-
n
300
1
qmgr
tlsmgr	
unix
-
-
y
1000?
1
tlsmgr
rewrite	
unix
-
-
y
-
-
trivial-rewrite
bounce	
unix
-
-
y
-
0
bounce
defer	
unix
-
-
y
-
0
bounce
trace	
unix
-
-
y
-
0
bounce
verify	
unix
-
-
y
-
1
verify
flush	
unix
n
-
y
1000?
0
flush
proxymap	
unix
-
-
n
-
-
proxymap
proxywrite	
unix
-
-
n
-
1
proxymap
smtp	
unix
-
-
y
-
-
smtp
relay	
unix
-
-
y
-
-
smtp
-o
showq	
unix
n
-
y
-
-
showq
error	
unix
-
-
y
-
-
error
retry	
unix
-
-
y
-
-
error
discard	
unix
-
-
y
-
-
discard
local	
unix
-
n
n
-
-
local
virtual	
unix
-
n
n
-
-
virtual
lmtp	
unix
-
-
y
-
-
lmtp
anvil	
unix
-
-
y
-
1
anvil
scache	
unix
-
-
y
-
1
scache
postlog	
unix-dgram
n
-
n
-
1
postlogd
maildrop	
unix
-
n
n
-
-
pipe
uucp	
unix
-
n
n
-
-
pipe
ifmail	
unix
-
n
n
-
-
pipe
bsmtp	
unix
-
n
n
-
-
pipe
scalemail-backend	
unix
-
n
n
-
2
pipe
mailman	
unix
-
n
n
-
-
pipe
inet
inet
Specific file and directory permissions

Permission Deep Owner Group Size Date Directory/File
drwx-wx--T 2 postfix postdrop 4096 Jul 21 05:44 /var/spool/postfix/maildrop
drwx--s--- 2 postfix postdrop 4096 Jul 16 09:35 /var/spool/postfix/public
srw-rw-rw- 1 postfix postdrop 0 Jul 16 09:35 cleanup
srw-rw-rw- 1 postfix postdrop 0 Jul 16 09:35 flush
srw-rw-rw- 1 postfix postdrop 0 Jul 16 09:35 pickup
srw-rw-rw- 1 postfix postdrop 0 Jul 16 09:35 postlog
srw-rw-rw- 1 postfix postdrop 0 Jul 16 09:35 qmgr
srw-rw-rw- 1 postfix postdrop 0 Jul 16 09:35 showq
drwx------ 2 postfix root 4096 Jul 16 09:35 /var/spool/postfix/private
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 anvil
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 bounce
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 bsmtp
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 defer
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 discard
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 error
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 ifmail
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 lmtp
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 local
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 maildrop
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 mailman
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 proxymap
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 proxywrite
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 relay
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 retry
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 rewrite
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 scache
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 scalemail-backend
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 smtp
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 tlsmgr
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 trace
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 uucp
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 verify
srw-rw-rw- 1 postfix postfix 0 Jul 16 09:35 virtual
-r-xr-sr-x 1 root postdrop 18552 Mar 9 16:38 /usr/sbin/postdrop
-r-xr-sr-x 1 root postdrop 22600 Mar 9 16:38 /usr/sbin/postqueue
Library dependencies
linux-vdso.so.1 (0x00007ffe6fde4000)	=
libpostfix-master.so	=> /usr/lib/postfix/libpostfix-master.so (0x00007fe6a603c000)
libpostfix-tls.so	=> /usr/lib/postfix/libpostfix-tls.so (0x00007fe6a6017000)
libpostfix-dns.so	=> /usr/lib/postfix/libpostfix-dns.so (0x00007fe6a600d000)
libpostfix-global.so	=> /usr/lib/postfix/libpostfix-global.so (0x00007fe6a5fc2000)
libpostfix-util.so	=> /usr/lib/postfix/libpostfix-util.so (0x00007fe6a5f79000)
libsasl2.so.2	=> /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fe6a5f53000)
libpthread.so.0	=> /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe6a5f2f000)
libc.so.6	=> /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe6a5d5b000)
libssl.so.1.1	=> /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fe6a5cc8000)
libcrypto.so.1.1	=> /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fe6a59d4000)
libresolv.so.2	=> /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fe6a59ba000)
libdb-5.3.so	=> /lib/x86_64-linux-gnu/libdb-5.3.so (0x00007fe6a57f8000)
libnsl.so.2	=> /lib/x86_64-linux-gnu/libnsl.so.2 (0x00007fe6a57dd000)
libdl.so.2	=> /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe6a57d7000)
libicuuc.so.67	=> /lib/x86_64-linux-gnu/libicuuc.so.67 (0x00007fe6a55ee000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe6a608b000)	=
libtirpc.so.3	=> /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007fe6a55be000)
libicudata.so.67	=> /lib/x86_64-linux-gnu/libicudata.so.67 (0x00007fe6a3aa3000)
libstdc++.so.6	=> /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe6a38d6000)
libm.so.6	=> /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe6a3792000)
libgcc_s.so.1	=> /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe6a3778000)
libgssapi_krb5.so.2	=> /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fe6a3725000)
libkrb5.so.3	=> /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fe6a3649000)
libk5crypto.so.3	=> /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fe6a3619000)
libcom_err.so.2	=> /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fe6a3613000)
libkrb5support.so.0	=> /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fe6a3604000)
libkeyutils.so.1	=> /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fe6a35fd000)

```

```auto
 Checking Configuration
The status of your system is being checked to ensure that all enabled features are available and properly configured ..
Your system has 5.78 GiB of memory, which is at or above the Virtualmin recommended minimum of 256 MiB
Errors were found in your system's BIND configuration : /var/lib/bind/beehivesoftware.indiax.com.hosts:8: ignoring out-of-zone data (beehivesoftware.indiax.com), /var/lib/bind/beehivesoftware.indiax.com.hosts:9: ignoring out-of-zone data (beehivesoftware.indiax.com), zone beehivesoftware.indiax.com.disabled/IN: has no NS records, zone beehivesoftware.indiax.com.disabled/IN: not loaded due to errors., _default/beehivesoftware.indiax.com.disabled/IN: bad zone, /var/lib/bind/sumdiagnostics.in.hosts:28: ignoring out-of-zone data (_443._tcp.sumdiagnostics.indiax.com), /var/lib/bind/sumdiagnostics.in.hosts:29: ignoring out-of-zone data (_443._tcp.www.sumdiagnostics.indiax.com), /var/lib/bind/sumdiagnostics.in.hosts:30: ignoring out-of-zone data (_443._tcp.admin.sumdiagnostics.indiax.com), /var/lib/bind/sumdiagnostics.in.hosts:31: ignoring out-of-zone data (_443._tcp.webmail.sumdiagnostics.indiax.com)

   .. your system is not ready for use by Virtualmin

```

So:

```auto
/var/lib/bind/sumdiagnostics.in.hosts:28: ignoring out-of-zone data (_443._tcp.sumdiagnostics.indiax.com)

```

---

<div class="post-metadata">

**Author:** ![Jamie](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/jamie/32/8589_2.png) [@Jamie](https://forum.virtualmin.com/u/Jamie)\
**Post date:** [July 21, 2024, 4:36am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/11 "2024-07-21T04:36:52Z")

</div>

It looks like the bigger issue is that DNS records are being added to the wrong zone!

What does `/var/lib/bind/sumdiagnostics.in.hosts` contain on your system?

---

<div class="post-metadata">

**Author:** ![calport](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/calport/32/44_2.png) [@calport](https://forum.virtualmin.com/u/calport)\
**Post date:** [July 21, 2024, 4:40am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/12 "2024-07-21T04:40:13Z")

</div>

```auto
$ttl 3600
sumdiagnostics.in.	IN	SOA	dns31.indiax.com. root.dns31.indiax.com. (
			2024072107
			3600
			600
			1209600
			3600 )
@	IN	NS	dns31.indiax.com.
@	IN	NS	dns1.indiax.com.
sumdiagnostics.in.	IN	A	62.72.42.43
www.sumdiagnostics.in.	IN	A	62.72.42.43
ftp.sumdiagnostics.in.	IN	A	62.72.42.43
localhost.sumdiagnostics.in.	IN	A	127.0.0.1
webmail.sumdiagnostics.in.	IN	A	62.72.42.43
admin.sumdiagnostics.in.	IN	A	62.72.42.43
sumdiagnostics.in.	IN	TXT	"v=spf1 a mx a:sumdiagnostics.in ip4:62.72.42.43 ip6:2400:d321:2191:9007:0000:0000:0000:0001 -all"
_dmarc.sumdiagnostics.in.	IN	TXT	"v=DMARC1; p=quarantine; pct=100; ruf=mailto:dmarc@calport.com; rua=mailto:dmarc@calport.com"
sumdiagnostics.in.	IN	AAAA	2400:d321:2191:9007:0000:0000:0000:0001
www.sumdiagnostics.in.	IN	AAAA	2400:d321:2191:9007:0000:0000:0000:0001
ftp.sumdiagnostics.in.	IN	AAAA	2400:d321:2191:9007:0000:0000:0000:0001
webmail.sumdiagnostics.in.	IN	AAAA	2400:d321:2191:9007:0000:0000:0000:0001
admin.sumdiagnostics.in.	IN	AAAA	2400:d321:2191:9007:0000:0000:0000:0001
@	IN	CAA	0 issuewild letsencrypt.org
mail.sumdiagnostics.in.	IN	A	62.72.42.43
mail.sumdiagnostics.in.	IN	AAAA	2400:d321:2191:9007:0000:0000:0000:0001
sumdiagnostics.in.	IN	MX	5 mail.sumdiagnostics.in.
vps16._domainkey.sumdiagnostics.in.	IN	TXT	( "v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArduxKwN529LsU" "QIEZJKDdvbpWv/bTXPvhlWP9xD5Lu5MHjWvX/pjS/cpNPxC/0DmcYCg9GaD7FlpTaD/ZaxF0kU+D2Uy2" "xp6eBOMAYLTwgc+m5J+icehLLe/Vs7dk30Kicd1GH5Q7gBMY++HBfFLK744CA327I4txFf88VpMZ2rBR" "RGlaSujrnrbukh0JeHOJBs9PnLkNlPXiPCbj7YT4z+GY6uVFX146XEO5ZwjReGVSRKUoc84g54zRpSeh" "sY3V6tMFjecn1JhgbHRkt/HUSpAjo3matW76xeNjUAKj5/f3o3tFBuuCVsdwOlZ7+NBl5EcmYyw1wd7N" "+15xCitUwIDAQAB" )
_443._tcp.sumdiagnostics.indiax.com.	3600	IN	TLSA	3 0 1 484b8434816f8f6b0849952cd66d36cd355680bae0435d20925c9331d637f93f
_443._tcp.www.sumdiagnostics.indiax.com.	3600	IN	TLSA	3 0 1 484b8434816f8f6b0849952cd66d36cd355680bae0435d20925c9331d637f93f
_443._tcp.admin.sumdiagnostics.indiax.com.	3600	IN	TLSA	3 0 1 484b8434816f8f6b0849952cd66d36cd355680bae0435d20925c9331d637f93f
_443._tcp.webmail.sumdiagnostics.indiax.com.	3600	IN	TLSA	3 0 1 484b8434816f8f6b0849952cd66d36cd355680bae0435d20925c9331d637f93f
_443._tcp.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_443._tcp.www.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_443._tcp.mail.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_443._tcp.admin.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_443._tcp.webmail.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_10000._tcp.admin.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_10000._tcp.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_20000._tcp.webmail.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_20000._tcp.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_993._tcp.mail.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_993._tcp.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_995._tcp.mail.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_995._tcp.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_587._tcp.mail.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_587._tcp.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_25._tcp.mail.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_25._tcp.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 42461c485892484ffaee402dfd296298bb4f0fe3b256fb765b6cb5cd77a6bb42
_3306._tcp.mysql.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 65bce3ca52927c698254ebe9ea2441a2932b4ce520b70bfcd3ef3df612408857
_3306._tcp.sumdiagnostics.in.	3600	IN	TLSA	3 0 1 65bce3ca52927c698254ebe9ea2441a2932b4ce520b70bfcd3ef3df612408857
sumdiagnostics.in.	IN	SSHFP	1 1 991f6289ed506239527979ad04eef58a3fd9093c
www.sumdiagnostics.in.	IN	SSHFP	1 1 991f6289ed506239527979ad04eef58a3fd9093c
sumdiagnostics.in.	IN	SSHFP	2 1 b9c188247df02ff8385fa55f2a3e0c311f37ed5c
www.sumdiagnostics.in.	IN	SSHFP	2 1 b9c188247df02ff8385fa55f2a3e0c311f37ed5c
sumdiagnostics.in.	IN	SSHFP	3 1 aa05d38ce8a1ac2643f82bfa3857aef3d3578888
www.sumdiagnostics.in.	IN	SSHFP	3 1 aa05d38ce8a1ac2643f82bfa3857aef3d3578888
sumdiagnostics.in.	IN	SSHFP	4 1 4a012604ed4edde5432d9a127b4cd839f7c41365
www.sumdiagnostics.in.	IN	SSHFP	4 1 4a012604ed4edde5432d9a127b4cd839f7c41365

```

[sumdiagnostics.indiax.com](http://sumdiagnostics.indiax.com) was used during development. The domain has now been removed.

Edit: and I did something stupid a few minutes ago. While we were discussing this, I disabled TLSA for sumdiagnostics and then enabled it again, and in doing so removed the old records in sumdiagnostics.in.hosts which might have been of help to you to diagnose this. Sorry!

Edit: after i enabled TLSA again, I still see:

```auto
Checking Configuration
The status of your system is being checked to ensure that all enabled features are available and properly configured ..
Your system has 5.78 GiB of memory, which is at or above the Virtualmin recommended minimum of 256 MiB
Errors were found in your system's BIND configuration : /var/lib/bind/beehivesoftware.indiax.com.hosts:8: ignoring out-of-zone data (beehivesoftware.indiax.com), /var/lib/bind/beehivesoftware.indiax.com.hosts:9: ignoring out-of-zone data (beehivesoftware.indiax.com), zone beehivesoftware.indiax.com.disabled/IN: has no NS records, zone beehivesoftware.indiax.com.disabled/IN: not loaded due to errors., _default/beehivesoftware.indiax.com.disabled/IN: bad zone, /var/lib/bind/sumdiagnostics.in.hosts:28: ignoring out-of-zone data (_443._tcp.sumdiagnostics.indiax.com), /var/lib/bind/sumdiagnostics.in.hosts:29: ignoring out-of-zone data (_443._tcp.www.sumdiagnostics.indiax.com), /var/lib/bind/sumdiagnostics.in.hosts:30: ignoring out-of-zone data (_443._tcp.admin.sumdiagnostics.indiax.com), /var/lib/bind/sumdiagnostics.in.hosts:31: ignoring out-of-zone data (_443._tcp.webmail.sumdiagnostics.indiax.com)

```

Edit: but when I restart BIND, I see:

```auto
Check BIND Config
The following errors were found in the BIND configuration file /etc/bind/named.conf or referenced zone files ..
/var/lib/bind/beehivesoftware.indiax.com.hosts:8: ignoring out-of-zone data (beehivesoftware.indiax.com)
/var/lib/bind/beehivesoftware.indiax.com.hosts:9: ignoring out-of-zone data (beehivesoftware.indiax.com)
zone beehivesoftware.indiax.com.disabled/IN: has no NS records
zone beehivesoftware.indiax.com.disabled/IN: not loaded due to errors.
_default/beehivesoftware.indiax.com.disabled/IN: bad zone
/var/lib/bind/sumdiagnostics.in.hosts:28: ignoring out-of-zone data (_443._tcp.sumdiagnostics.indiax.com)
/var/lib/bind/sumdiagnostics.in.hosts:29: ignoring out-of-zone data (_443._tcp.www.sumdiagnostics.indiax.com)
/var/lib/bind/sumdiagnostics.in.hosts:30: ignoring out-of-zone data (_443._tcp.admin.sumdiagnostics.indiax.com)
/var/lib/bind/sumdiagnostics.in.hosts:31: ignoring out-of-zone data (_443._tcp.webmail.sumdiagnostics.indiax.com)

```

Is this an edge case caused by my workflow? I create a virtual server with the client’s domain (sumdiagnostics.in - which is still hosted somewhere else) and I alias it with a temporary domain used during development ([sumdiagnostics.indiax.com](http://sumdiagnostics.indiax.com) - which is on my Virtualmin server, naturally). DNS records are created automatically by Virtualmin. However, when I remove the temporary domain and make the client’s website live on the clients domains by pointing its DNS to Virtualmin’s DNS, the cleanup by Virtualmin for the removal of [sumdiagnostics.indiax.com](http://sumdiagnostics.indiax.com) is not perfect?

---

<div class="post-metadata">

**Author:** ![Jamie](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/jamie/32/8589_2.png) [@Jamie](https://forum.virtualmin.com/u/Jamie)\
**Post date:** [July 21, 2024, 5:11am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/13 "2024-07-21T05:11:16Z")

</div>

Thanks for that file! I see the issue now, and will fix it in the next Virtualmin release.

The trigger is having an SSL certificate for multiple domain names, in this case `sumdiagnostics.in` and `indiax.com` … it’s not actually related to DNSSEC at all.

---

<div class="post-metadata">

**Author:** ![calport](https://cdn.forum.virtualmin.com/user_avatar/forum.virtualmin.com/calport/32/44_2.png) [@calport](https://forum.virtualmin.com/u/calport)\
**Post date:** [July 21, 2024, 5:12am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/14 "2024-07-21T05:12:33Z")

</div>

That would be great, @Jamie. Thanks!

So: Virtualmin could be made to create TLSA records even if DNSSEC is disabled. Yay!!

---

<div class="post-metadata">

**Author:** ![system](https://cdn.forum.virtualmin.com/uploads/default/original/2X/c/cd96d761e326db4b2bef94886a639109bd7a8e76.svg) [@system](https://forum.virtualmin.com/u/system)\
**Post date:** [July 29, 2024, 5:12am UTC](https://forum.virtualmin.com/t/quirk-with-tlsa-records-enabled-option-and-virtualmin-systems-settings-re-check-configuration/128032/15 "2024-07-29T05:12:59Z")

</div>

Closed on July 29, 2024, 5:12am UTC

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.