Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dmarcwise.io

Post reply on HN
Print view View original

21–29 of 29 posts

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

#21

Post by 2000UltraDeluxe »

amluto wrote: post #11
jeroenhd wrote: post #8

Earlier quoted context omitted.

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

No.

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.

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

#22

Post by phicoh »

formerly_proven wrote: post #15
woodruffw wrote: post #13

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.

A linked list of each authoritative name in the zone. Not a list of zones.

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.

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

#23

Post by ZWoz »

toast0 wrote: post #12
amluto wrote: 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 isn't part of SMTP.

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.

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

#24

Post by pocksuppet »

tptacek wrote: post #17
formerly_proven wrote: post #15

Earlier quoted context omitted.

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.

Was it really nothing to do with keeping keys safer offline?

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

#25

Post by tptacek »

pocksuppet wrote: post #24
tptacek wrote: post #17

Earlier quoted context omitted.

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.

Was it really nothing to do with keeping keys safer offline?

Go read the mailing lists of the time.

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

#26

Post by tptacek »

phicoh wrote: post #22
formerly_proven wrote: post #15

Earlier quoted context omitted.

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.

A linked list of each authoritative name in the zone. Not a list of zones. 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,…

At this point, with this microscopic level of adoption and this track record of instability, and given that we're now 4 major revisions (all premised on the same original service model that TIS came up with in the mid-1990s), it would make a lot more sense to go back to the drawing board.

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.

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

#27

Post by sealedmailuk »

2000UltraDeluxe wrote: post #21
amluto wrote: post #11

Earlier quoted context omitted.

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

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

[dead]

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

#28

Post by sealedmailuk »

em-bee wrote: post #20
toast0 wrote: post #12

Earlier quoted context omitted.

> 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

[dead]

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

#29

Post by sealedmailuk »

winstonwinston wrote: post #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/wi…

[flagged]
Post reply on HN