

Discussion summary
Discussions focus on the issues with DMARC's new 'NP' tag and DNSSEC, highlighting problems with DNS provider implementations and DNS record handling.
What the discussion says
- Some argue the 'NP' tag semantics are misguided.
- DNS providers like Cloudflare may return incorrect data to optimize responses.
- There is concern about DNSSEC signatures and their impact on DNS responses.
- The mismatch between DNS standards and provider implementations is problematic.
“The new 'NP' feature’s semantics are misguided.”
“Many DNS providers return incorrect data to avoid switching to TCP.”
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- While nothing good can be said about the design of DNSSEC here, it seems to me that the new np feature’s semantics are also misguided. I get it: if I own company.com and I’m not using foo.company.com, then maybe I should set np=reject on company.com’s DMARC rule so that no one can spoof email from it.
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?
by amluto - > Finally, one aspect to consider is that many mail servers reject mail when the Envelope From domain has no MX or A/AAAA records. When the Envelope From domain and From domain are identical, this may reduce the number of relevant cases. The np tag was nonetheless introduced, so it was probably deemed realistic that a mail receiver reaches the point where the np policy is evaluated.
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.
- Summary: it's not DNSSEC itself, it's DNS providers like Cloudflare returning incorrect data to make responses shorter and avoid switching to TCP. A DNSSEC signature for "this domain doesn't exist" is much longer than a DNSSEC signature for "this domain exists, but doesn't have the type of record you asked for" so these providers choose to always return the latter type of answer. Since the server is telling you the domain exists, policies about what to do when the domain doesn't exist don't apply.
tptacek incoming in 3...2...1...
by pocksuppet