Why DMARC's new "NP" tag can fail with DNSSEC
dmarcwise.io
Why DMARC's new "NP" tag can fail with DNSSEC
1–10 of 29 posts
Re: Why DMARC's new "NP" tag can fail with DNSSEC
#2Summary: 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...
Re: Why DMARC's new "NP" tag can fail with DNSSEC
#3While 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?
Re: Why DMARC's new "NP" tag can fail with DNSSEC
#4Summary: 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 d…
> Summary: it's not DNSSEC itself, it's DNS providers like Cloudflare returning incorrect data to make responses shorter and avoid switching to TCP.
I feel like we need the angry goose meme here.
"But why are those providers returning incorrect data?"
Re: Why DMARC's new "NP" tag can fail with DNSSEC
#5While 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…
Re: Why DMARC's new "NP" tag can fail with DNSSEC
#6Summary: 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 d…
> Summary: it's not DNSSEC itself, it's DNS providers like Cloudflare returning incorrect data to make responses shorter and avoid switching to TCP. I feel like we need the angry goose meme here. "But why are those providers returning incorrect data?"
> "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.
Re: Why DMARC's new "NP" tag can fail with DNSSEC
#7Earlier quoted context omitted.
> Summary: it's not DNSSEC itself, it's DNS providers like Cloudflare returning incorrect data to make responses shorter and avoid switching to TCP. I feel like we need the angry goose meme here. "But why are those providers returning incorrect data?"
> "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.
So you’re cool with letting anyone walk your DNS?
Re: Why DMARC's new "NP" tag can fail with DNSSEC
#8While 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…
> 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.
Re: Why DMARC's new "NP" tag can fail with DNSSEC
#9Summary: 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 d…
At the time it was well known that messing around with NXDOMAIN would cause problems. But some companies wanted to do it anyhow.
The solution is simple, if you want to use this DMARC feature then don't host with companies that do weird stuff with NXDOMAIN.
Re: Why DMARC's new "NP" tag can fail with DNSSEC
#10Earlier quoted context omitted.
> "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.
So you’re cool with letting anyone walk your DNS?
The problem here is that computing three 3 NSEC3 records as you might need to return an NXDOMAIN was considered too expensive. It's just a choice to reduce their costs while increasing complexity for everyone else.