Why DMARC's new "NP" tag can fail with DNSSEC
dmarcwise.io
dmarcwise.io
tptacek incoming in 3...2...1...
I feel like we need the angry goose meme here.
"But why are those providers returning incorrect data?"
In this case, because they decided actually implementing the protocol they were supposed to be implementing didn't work for their hacky design, so they hacked together a series of Good Enough workarounds.
These cloud companies are the Microsoft Internet Explorer of DNS service but unlike IE6 they're considered cool enough that they're tolerated.
The solution is simple, if you want to use this DMARC feature then don't host with companies that do weird stuff with NXDOMAIN.
This seems like a major design flaw in DNSSEC, if so.
(I don’t have an opinion on whether Cloudflare or whoever else is a good participant in the DNS.)
That's for offline signing. For online signing you can do different things.
But the point is, and that's what this discussion is about is that DNSSEC can evolve. It can get extra features to make online signing more efficient.
The problem is that getting all validating recursive resolvers and other validators to update takes a very long time, on the order of decades.
So we got this problem because people started using this feature without verifying that validator support had spread wide enough.
That's basically what we did with DoH, a protocol that has drastically more deployment than DNSSEC and a more coherent threat model.
The simplest and most obvious thing you could do, if you were being parsimonious about it, would be to switch to an online-signer model. With modern (circa 2005) cryptography, you'd do a straightforward client/server authenticated denial without any of the record-chaining silliness. A big chunk of the complexity of the protocol would just vanish.
In practice DMARC verifiers can/will do the same for checking ‘non-existent’ subdomain. Query A/AAAA/MX and if no usable answers are given, the subdomain does not exist. Who cares if it is NXDOMAIN or NODATA.
But it seems odd that www.company.com should be considered present for this purpose even if it has no MX records. And if I want to send from noreply.company.com, then setting some unrelated DNS record type there to prevent it from being not “not present” seems like a giant kludge.
And lots of domains have subdomains that are intended for some non-email purpose (api.company.com or whatever), and those shouldn’t be allowed without further policy. Nor should (technically invalid for SMTP but maybe allowed anyway) delights like _dmarc.company.com itself.
Why didn’t the DMARC spec say that a domain is “not present” if it lacks MX records?
MX implies a domain can receive email, you don't need it to send email. A setup where company.example sends email from companymailings.example but sets a reply-to for support@company.example is perfectly valid (even if it's stupid and confusing). Plus there's that weird legacy behaviour of mail servers delivering to port 25 to the IP in the A record if MX records are missing.
So shouldn’t this be done explicitly by setting a policy at _dmarc.companymailings.example instead of implicitly by setting at otherwise entirely useless record (of type A? some unused TXT variant?) at companymailings.example?
MX tells a sender where the mail goes.
DMARC allows the recipient to verify the adress in the From header.
Neither has anything to do with the fact whether a server sends emails or not.
That doesn't match the SMTP spec, RFC 5321 says
> If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
Now, steelman argument is that DMARC is used together with SMTP, so it should be somewhat compatible to work in practice. But in this case there isn't fundamental conflict breaking SMTP.