Improve DNS configuration for email

AevaOnline commented 4 years ago

Current auto-generated DNS records do not include two key components for email server validation. The result is that many of my emails are placed in the spam folder when sent to friends who still have @ gmail.com accounts.

After some investigation, I think this could be improved very easily by adding one line and updating one line in the DNS configuration:

proper dmarc records that point to actual email accounts (I created two new aliases for this)
a reverse dns record

Example of current auto-generated DNS

; Basic ipv4/ipv6 records
@ 3600 IN A 63.x.y.z
* 3600 IN A 63.x.y.z

; XMPP
_xmpp-client._tcp 3600 IN SRV 0 5 5222 mydomain.com.
_xmpp-server._tcp 3600 IN SRV 0 5 5269 mydomain.com.
muc 3600 IN CNAME @
pubsub 3600 IN CNAME @
vjud 3600 IN CNAME @

; Mail
@ 3600 IN MX 10 mydomain.com.
@ 3600 IN TXT "v=spf1 a mx ip4:63.x.y.z -all"
mail._domainkey 3600 IN TXT "v=DKIM1; h=sha256; k=rsa; p=verylongbytestring"
_dmarc 3600 IN TXT "v=DMARC1; p=none"

; Extra
@ 3600 IN CAA 128 issue "letsencrypt.org"

Suggested additional line

z.y.x.63.in-addr.arpa 3600 IN PTR mydomain.com.

Suggest replacing _dmarc line

_dmarc 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-aggregate@mydomain.com; ruf=mailto:dmarc-afrf@mydomain.com; pct=100"

Psycojoker commented 4 years ago

a reverse dns record

Are you sure about this one? My understanding is that this needs to be done at the "ip owner level" like the ISP/Hosting provider level, it's really the first time I've saw that done at the DNS level of the "user" (sorry, not sure about the exact terminology)

AevaOnline commented 4 years ago

Ah - you're partially correct about the DNS PTR entry.

Unlike other DNS entries which are managed at the registrar, the PTR needs to be managed on the server that the IP actually routes to. In other words, I believe it needs to actually be configured on the Yunohost instance, though I'm not sure exactly how best to do that.

I've tried adding this line to the /etc/dnsmasq.d/mydomain.com file: ptr-record=z.y.x.63.in-addr.arpa,mydomain.com

While this results in a local dig -x query returning the correct domain name, this change doesn't appear to propagate externally.

root@mydomain$ dig +noall +answer -x 63.x.y.z @127.0.0.1 
z.y.x.63.in-addr.arpa. 0   IN      PTR     mydomian.com.

aeva@laptop$ dig +noall +answer -x 63.x.y.z @63.x.y.z
; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> -x 63.x.y.z @63.x.y.z
;; global options: +cmd
;; connection timed out; no servers could be reached

EDIT: a little more digging and I was able to get the answer externally. It's not a firewall issue, but a configuration of dnsmasq. By editing /etc/dnsmasq.conf and adding the server's public IP to the interface list, an external reverse-dns query returns the correct result.

However, this opens up dnsmasq as a public service, and did not result in PTR-validation services validating the configuration, so I reverted it. Mentioning here for completeness.

southerntofu commented 4 years ago

Hey, i'm sorry but like @PsycoJoker said this is out of our reach. Reverse DNS entries are usually setup by your Internet Service Provider. Unfortunately, it's not possible to configure them with every ISP. This is documented on the isp page (en français).

Apart from this detail, your comment about DMARC is very just. There is no way to get your emails for sure delivered to Google/Microsoft (in most cases, contacting their supported to get whitelisted is the only way), but having a rua for DMARC can't do any harm.

For those not familiar with DMARC:

ruf may contain an address to warn of DKIM/SPF/alignment errors immediately (1 email per failed message) ; rua may contain an address to receive aggregate notification of such errors daily
p=none|quarantine|reject what the remote server should do with messages pretending to come from us that fail sanity checks
pct is an optional value that defaults to 100 and can be safely omitted

My two cents:

rua should probably be enabled by default, not ruf; yunohost admins may want to receive a daily notification in case something went wrong, but receiving a message on each failure may be a bit too much
maybe requiring a quarantine policy (usually moving the mail to spam folder) could help build credibility to other mails servers? i have no clue
in the future if we have the need, we could setup a dedicated dmarc report mailbox on each domain, and have a cron job parse the mailboxes to produce human-friendly information (eg in the web interface) and potentially diagnose problems earlier

alexAubin commented 4 years ago

Note that the diagnosis coming in 3.8 will have a test about reverse DNS in both ipv4 and ipv6 with tips on how to configure it (basically "go try to see on your isp router / vps interface if you have control over it")

Discussing this with @ljf when we worked on the implementation, it seems like a pretty big deal, and it might in fact be a blind spot of mail-tester.com that only covers ipv4 (to be confirmed ? but apparently there's no AAAA record for it) and not ipv6 - yet postfix will use ipv6 by default if available!

That rua sounds interesting as well, we should probably recommend people to add it. That should be pretty easy to add.

renne commented 1 year ago

@alexAubin @southerntofu Another option is to run Technitium as a primary nameserver on Yunohost, create reverse DNS zones and let the ISP delegate the reverse DNS zones to the Technitium server. That way Yunohost could configure the RDNS records automagically. This is related to #1824

alexAubin commented 1 year ago

let the ISP delegate the reverse DNS zones to the Technitium server.

As far as I know, the main issue is that many ISP don't even allow to configure the reverse DNS in the first place, so I doubt they will allow to delegate the reverse DNS zone which sounds even more advanced ... But maybe I misunderstand how rDNS works ...

geopayme commented 1 year ago

Need a DNS service? Maybe I can help.

On Tue, Jan 24, 2023, 12:58 AM Alexandre Aubin @.***> wrote:

let the ISP delegate the reverse DNS zones to the Technitium server.

As far as I know, the main issue is that many ISP don't even allow to configure the reverse DNS in the first place, so I doubt they will allow to delegate the reverse DNS zone which sounds even more advanced ... But maybe I misunderstand how rDNS works ...

— Reply to this email directly, view it on GitHub https://github.com/YunoHost/issues/issues/1501#issuecomment-1401119537, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7KJ33MCTIHC7BE4Q5DQY3WT4EJRANCNFSM4J4QOLEA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

geopayme commented 1 year ago

https://dns.ibbt.io I can setup an account for who ever needs one to try out. It should solve the problem you may have

On Tue, Jan 24, 2023, 1:36 AM Antonis Valamontes @.***> wrote:

Need a DNS service? Maybe I can help.

On Tue, Jan 24, 2023, 12:58 AM Alexandre Aubin @.***> wrote:

let the ISP delegate the reverse DNS zones to the Technitium server.

As far as I know, the main issue is that many ISP don't even allow to configure the reverse DNS in the first place, so I doubt they will allow to delegate the reverse DNS zone which sounds even more advanced ... But maybe I misunderstand how rDNS works ...

— Reply to this email directly, view it on GitHub https://github.com/YunoHost/issues/issues/1501#issuecomment-1401119537, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7KJ33MCTIHC7BE4Q5DQY3WT4EJRANCNFSM4J4QOLEA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

renne commented 1 year ago

@alexAubin I created IPv4 and IPv6 reverse DNS zones at desec. io and created a ticket at my VDSL-ISP asking for reverse DNS delegation to the desec.io nameservers. And what should I say - they did it!

YunoHost / issues