DMARC DNS entries for anti-spoofing of email From addresses of kubernetes.io

[Joel Smith]

Hi,

This morning we received a report that our kubernetes.io domain does not have DMARC DNS entries. I'm not familiar with DMARC so I read the Wikipedia entry [1] and it looks like it's yet another TXT record that you add to your domain. It provides processing instructions and gives greater control over how to detect and handle spoofed email. For example, it can be used to tell other mail servers to send an aggregate report of received messages from the domain to an administrative address (for example, dmarc...@example.com). That could give us a sense of whether our domain is being used for spoofing if we care, or to detect a misconfiguration in our email setup. It can tell other mail servers whether to use SPF and DKIM or both for spoof detection.

We currently have a SPF record in place that allows Google email servers to send email from the kubernetes.io domain. This enables us to use Google Groups mailing lists for our many various @kubernetes.io lists, but allows servers to detect spoofed messages originating from any other servers.

I'd like opinions of anyone in the community on whether this is worth our time to set up DMARC. If you think we'd derive some benefit by adding a DMARC record beyond what we're already getting from the existing SPF record, I'd like to hear about it. If you think we shouldn't bother, I'd like to hear that too.

I'm of the opinion that our current SPF record is sufficient to detect spoofers and I don't think there's much to be gained by somebody who sends spoofed email using our domain. I think that we needn't bother with DMARC.

Thanks,

Joel

[1] https://en.wikipedia.org/wiki/DMARC

[Craig Ingram]

Missing DMARC is a pretty low risk, but there have been some changes to how it's been rated in bug bounty programs (https://www.bugcrowd.com/bugcrowd-releases-vulnerability-rating-taxonomy-1-6/) with the argument being (https://github.com/bugcrowd/vulnerability-rating-taxonomy/issues/195#issuecomment-429027873) that providers are shifting toward ignoring SPF and focusing on DMARC to filter spoofed email (or at least, ignoring SPF if DMARC is not also present). 

I don't know enough about the specifics of who/how/when emails are sent from the kubernetes.io domain, but if things are working ok with the current SPF setup for authorized people to send email via a @kubernets.io email, then DMARC should work ok too. If it's a low enough effort task to enable, it seems like a reasonable thing to try out, especially since it can be enabled slowly without actually doing any blocking at first.

Thanks,

Craig

--
You received this message because you are subscribed to the Google Groups "kubernetes-security-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-security...@googlegroups.com.
To post to this group, send email to kubernetes-se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-security-discuss/d808d9a7-6fd0-42eb-bb6a-d4f099b9e125%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.