DNS view

[stAn47]

Hello, we just migrated our clients to mailcow and i would like to mention a few possible bugs with the DNS suggestions shown at the domain list:

DKIM

for DKIM we are using "mail" selector as in "mail._domainkey.example.com." mailcow suggests:

v=DKIM1;k=rsa;t=s;s=email;p=MIG...

while our previous (and working) settings are:

v=DKIM1; k=rsa; p=MIGfM...

see - the main difference:

1. mailcow suggests selector "email" even though within doman list it properly says:

   Key valid
   Selector 'mail'
   1024 bit

   and outgoing emails have a proper "mail" selector.

2. our previous config does not mention selector within the DKIM DNS record

i believe it is not correct to have "s=email" in DKIM record when the selector is just "mail" - please correct me. Also i would suggest to validate only "p" part of the DKIM within the DNS suggestions since that is the most important

SRV

we are using google cloud DNS and per all specifications that i read standard format for SRV records is

priority weight port domain.com. and thus the suggestion i believe should be"

0 0 443 mailcowdomainexample.com.

(with or without dot at the end - bind and most cloud DNS require the dot)

TLSA

Is it safe to use TLSA in production when using letsencrypt certificates? when certbot updates certificate, will TLSA change ? if yes, is there any DNS API binding's possible (see below)?

Feature request - Autodiscover Name

I saw a few code suggestions here already for autodiscover name and it would be really nice that we are able to configure it via main server configuration

Feature request - Cloud DNS automation

We moved to google cloud DNS due to a nice API which allows us to use free wildcard certificates via letsencrypt and certbot. It woud be nice if mailcow supported cloud DNS's APIs so that it automatically updates TSLA + SRV + CNAMEs for autodiscovery and automatically creates DKIM entries for new domains.

Thank you for great work, Best regards, Stan

[andryyy]

s=email in the DKIM TXT record is not the selector, but the use-case of this key. It indicates, that it is used for mail only. We could probably add a check to ignore it.

Prority and weight are ignored, iirc, @mkuron ?

The printed TLSA records are bound to the key, which does not change.

What do you mean by "autodiscover name"?

Best André

[mkuron]

DKIM

t=s means that the key is for this domain only and not for subdomains. We should leave it there as Mailcow will never use the key for a subdomain. s=email is the only service type defined (besides s=*, which is the default if none is specified), so it doesn't matter. Since Mailcow only does email, we shouldn't change it just to save 8 bytes in a DNS record.

SRV

Weight and priority are ignored, but of course need to be present. Your DNS server will warn you if you leave them out. We also don't currently show the priority on the MX records on the DNS page, but of course it needs to be there (but its value does not matter).

TLSA

Keys are reused, so TLSA is safe.

Autodiscover name

925. I requested a change on that pull request, but the original author never responded. If you submit a new pull request that uses the name from the database instead of adding another variable to the config file, we can get it merged.

Cloud DNS automation

No way. There are just too many DNS providers that we would need to support. For an idea, look at the dehydrated ACME client's page of DNS hooks: https://github.com/lukas2511/dehydrated/wiki/Examples-for-DNS-01-hook scripts. Since DNS records are basically a one-time thing, I don't think it's a necessary feature anyway.

[stAn47]

thank you very much for great explanation of those records, i am sure this will help lot's of users.

best regards, stan

[d-horner]

I was just browsing the issues and noticed this, I hacked together a script for adding DNS records via CloudFlare's api.

Sharing is caring, and I know it doesn't seem applicable elsewhere. I'll likely be fixing one for Google's CloudDNS as that's my current go-to.

Cheers for all the thought put in, mailcow has greatly simplified my efforts!

[stAn47]

hello, thank you for sharing, this is how we add autodiscovery for thunderbird to each domain

#!/bin/bash

#CONFIGURATION:
TTLA=300 #5 MINUTES=300, 5H=18000,5D=432000
TTLSPF=18000
PROJECT="project-name-in-google"
MXDOMAIN="mx.yourdomain.com"
DOMAIN="$1"
NEWNAME="${DOMAIN//./}"

echo "create google dns zone for: $DOMAIN new name $NEWNAME"
#echo "gcloud dns managed-zones create --dns-name=\"$DOMAIN.\" --description=\"\" \"$NEWNAME\""
#gcloud dns --project=$PROJECT managed-zones create $NEWNAME --description= --dns-name=$DOMAIN.

        echo "creating default records"
        gcloud dns --project=$PROJECT record-sets transaction start --zone=$NEWNAME
        gcloud dns --project=$PROJECT record-sets transaction add "$MXDOMAIN." --name=autodiscover.$DOMAIN. --ttl=$TTLA --type=CNAME --zone=$NEWNAME
        gcloud dns --project=$PROJECT record-sets transaction add "$MXDOMAIN." --name=autoconfig.$DOMAIN. --ttl=$TTLA --type=CNAME --zone=$NEWNAME
        gcloud dns --project=$PROJECT record-sets transaction add "0 0 443 $MXDOMAIN." --name=_autodiscover._tcp.$DOMAIN. --ttl=$TTLA --type=SRV --zone=$NEWNAME
        gcloud dns --project=$PROJECT record-sets transaction execute --zone=$NEWNAME

echo "gcloud dns --project=$PROJECT  managed-zones describe $NEWNAME"
gcloud dns --project=$PROJECT  managed-zones describe $NEWNAME

the script above works if the user running the script got already google enviroment configured

the above code finds the domain by stripping DOTs from the domain name so "example.com" has zonename "examplecom" in our Google Cloud DNS

since mailcow uses docker it would be nice to have one of those docker images for 3rd party apis and they could be executed from web hooks.

once i find out how to read the database into shell script maybe i could add SPF, DKIM a DMARC records this way as well.

best regards, stan