Live data from Hacker News

Why DMARC's new "NP" tag can fail with DNSSEC

dmarcwise.io

11–20 of 29 posts

Re: Why DMARC's new "NP" tag can fail with DNSSEC

#11
post #8
post #3

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…

> 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…

> A setup where company.example sends email from companymailings.example but sets a reply-to for support@company.example is perfectly valid

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?

Re: Why DMARC's new "NP" tag can fail with DNSSEC

#12
post #3

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…

> Why didn’t the DMARC spec say that a domain is “not present” if it lacks MX records?

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.

https://www.rfc-editor.org/rfc/rfc5321.html#section-5

Re: Why DMARC's new "NP" tag can fail with DNSSEC

#13

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 d…

> 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

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.)

Re: Why DMARC's new "NP" tag can fail with DNSSEC

#14
> 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.

Re: Why DMARC's new "NP" tag can fail with DNSSEC

#15

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 d…

> 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 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.)

Most of the time people are not asking for domains which don't resolve. Also, think about what DNSSEC is actually having to do when signing an NXDOMAIN. It needs to prove a negative with offline signing keys, DNSSEC does this by basically making a linked list of each zone and signing the links.

Re: Why DMARC's new "NP" tag can fail with DNSSEC

#16
post #6
post #4

Earlier 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.

Cloudflare is well known for breaking DNS standards whenever they feel like it; they’re too big to ignore, so they get away with murder.

Re: Why DMARC's new "NP" tag can fail with DNSSEC

#17

Earlier quoted context omitted.

> 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 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.)

Most of the time people are not asking for domains which don't resolve. Also, think about what DNSSEC is actually having to do when signing an NXDOMAIN. It needs to prove a negative with offline signing keys, DNSSEC does this by basically making a linked list of each zone and signing the links.

It's doing that because the protocol was designed for offline signers, which in turn was a result of a folk belief in the 1990s that computers wouldn't be fast enough to do online signing.

Re: Why DMARC's new "NP" tag can fail with DNSSEC

#18
post #16
post #6

Earlier 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.

Cloudflare is well known for breaking DNS standards whenever they feel like it; they’re too big to ignore, so they get away with murder.

How did they get this way, anyway? Let's say that I want half the world to sign up for me to MITM their traffic. How would I achieve that?

Re: Why DMARC's new "NP" tag can fail with DNSSEC

#19
post #16

Earlier quoted context omitted.

Cloudflare is well known for breaking DNS standards whenever they feel like it; they’re too big to ignore, so they get away with murder.

How did they get this way, anyway? Let's say that I want half the world to sign up for me to MITM their traffic. How would I achieve that?

Solve a DDoS problem by positioning yourself as the middleman (instead of designing new protocols without the vulnerability).

Re: Why DMARC's new "NP" tag can fail with DNSSEC

#20
post #12
post #3

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…

> Why didn’t the DMARC spec say that a domain is “not present” if it lacks MX records? 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. https://www.rfc-editor.org/rfc/rfc5321.html#section-5

DMARC demands extra DNS entries that SMTP doesn't need, so there is no reason why DMARC could not also demand an explicit MX record even if plain SMPT doesn't
Post reply on HN