I’m trying to install a chatmail server using deSEC as the DNS manager. However, the installer reports an error when running dig @get.desec.io. -r -q <my_domain> -t A +short. And if I run this same command from my command line I get the following error:
;; communications error to 2a01:4f8:10a:1044:deec:642:ac10:80#53: connection refused
;; communications error to 2a01:4f8:10a:1044:deec:642:ac10:80#53: connection refused
;; communications error to 2a01:4f8:10a:1044:deec:642:ac10:80#53: connection refused
;; communications error to 88.99.64.5#53: connection refused
Is this connection error expected? What could this be due to?
Thanks, it seems like the configuration tool looked for the SOA record instead of the NS one for some reason. Changing the script to force ns1.desec.io worked!
I’ll open an issue on the chatmail repo so they are aware of that.
I was checking all this issue again and noticed that actually the SOA record of the domains managed by deSEC has the Primary NS value as get.desec.io.. So I understand that the script tries to resolve to this server.
Given that, isn’t this a deSEC issue rather than an issue from the Chatmail server?
I don’t really know how the hole DNS server infrastrucure works, I’m just someone trying to figure how to correctly install and manage my server
That is a misunderstanding of the purpose of the MNAME in the SOA record. It is defined as the primary source of the DNS data, but it is not necessarily a public server. The NS resource record set lists the servers that are to be queried. Not making the MNAME available as a public server is called “hidden primary”. It is an allowed and frequently used configuration, which means it is wrong to query the MNAME from the SOA record. If the MNAME is to be used as a public server, it is also listed in the NS RR set. The only purpose of the MNAME is for RFC2136 style dynamic DNS updates.
