5 ms·

I would be curious to know what Paul Vixie thinks of things like DKIM and DMARC. Both of them turn DNS into a database of convenience for every major email pro

I would be curious to know what Paul Vixie thinks of things like DKIM and DMARC. Both of them turn DNS into a database of convenience for every major email provider on the planet, while neither of these technologies seems to make any useful impact on spam itself as the former is as often ignored as the latter is misconfigured. for relaying to Google, one must take a prescriptive and religious approach by accepting both these gods as a precondition of your delivery.

zcw100 3y ago
Does an MX record make it a “database of convenience”? You don’t have to serve any of those records. I’m not saying there isn’t a problem with email but just that it’s not a problem with DNS.
marcus0x62 3y ago
The inventors of DNS originally envisioned a lot more email-related “catalog of convenience” data in the DNS. Go lookup MD, MF, MAILA, MB, MG, MR, MINFO, and MAILB records in the original spec[0] 0 - https://www.rfc-editor.org/rfc/rfc1035 https://www.rfc-editor.org/rfc/rfc1035
- kps 3y ago
  I think it's merely annoying that DMARC, DKIM, et al are all TXT records with magic fake domain names because record types ossified. Also, the web ‘public suffix list’ should be a DNS property instead.
  - teddyh 3y ago
    Better a silly underscore subdomain than a plethora of TXT records, which was once a real problem, and threatened to overwhelm the apex domain. But yes, the abandonment of the SPF record type was disappointing.
    - Avamander 3y ago
      It was clear that the record type significantly hindered the deployment, which is why. If initial implementations wouldn't have been so strict at enforcing a small subset of types, things might be different.
  - crotchfire 3y ago
    Also, the web ‘public suffix list’ should be a DNS property instead. Unfortunately the public suffix list has serious security implications, so it isn't safe to distribute it via unauthenticated DNS. It also has very serious availability implications, so if you sign it with the WebPKI-maximum validity of 90 days and somehow and those signatures expire, you either get major vulnerabilities if you fail open or else an entire TLD (like ".com") breaks if you fail closed. You get to play this game every 90 days. Sounds like fun. https://www.digicert.com/blog/chromes-proposed-90-day-certificate-validity-period https://www.digicert.com/blog/chromes-proposed-90-day-certif... This is the fundamental problem with trying to have DNSSEC replace DNS (instead of augmenting it): signature revocation is Byzantine-Generals-complete, which means that you either sign something forever (like ssh keys) or for a fixed time period and treat nonrenewal as revocation. Nonrenewal-as-revocation sorta works for signing single domains; if one website's cert expires it isn't the end of the world. When you start trying to sign larger and larger fractions of the Domain Name space, moving up to ccTLDs and then the root, the stakes are just way too high. This is why DNSSEC will never displace unauthenticated DNS. The choices are to stick with unauthenticated DNS, or maintain both systems in parallel forever. There is no third option where unsigned DNS records just go away.
    - cryptonector 3y ago
      > This is the fundamental problem with trying to have DNSSEC replace DNS (instead of augmenting it): DNSSEC does not replace DNS. DNSSEC augments DNS. > [stuff about revocation] Much of what you wrote there is erroneous: > [..] you either sign something forever (like ssh keys) or for a fixed time period and treat nonrenewal as revocation. In DNSSEC you revoke by publishing new public keys in a DS record at the delegation and deleting the old public keys, also at the delegation. No need to worry about expiration -- the DS record has none. There is no expiration in the DS record but that's not "you sign something forever" because the DS record is signed by an RRSIG record that has an expiration. Zone operators have to re-sign RRSIG records, but that's not really a problem. So revocation in DNSSEC is easy, and you can do it as often as the TTL on the DS RR allows. Revocation in PKI is much harder, unless one just goes for short-lived certificates. By automating certificate renewal operations, Let's Encrypt is doing the world a favor, as it will allow servers to have very short-lived certificates, thus eliding the need for revocation (and keeping CRLs small if recovation is still needed). > [...] if one website's cert expires it isn't the end of the world. When you start trying to sign larger and larger fractions of the Domain Name space, moving up to ccTLDs and then the root, the stakes are just way too high. Now this is true but it shouldn't be any more likely than other whole-domain outage failure modes of DNS. If you publish the wrong DS records at the delegation, your domain will be out -- don't do that! That's like publishing the wrong NS records at the delegation. The delegator can also break the delegation on their own, but they can do that w/o DNSSEC too, so you're no more and no less at their mercy w/ or w/o DNSSEC. And if you fail to re-sign your zones, you'll have some outages. In practice the right way to do the last is to sign dynamically in your DNS servers using ECC and with some caching, naturally. > This is why DNSSEC will never displace unauthenticated DNS. > > The choices are [...] The predicate is erroneous, so the conclusion doesn't follow from it. It might follow from other issues, but not the ones you stated.
- zokier 3y ago
  It's a shame that SRV records were not included in DNS from beginning, the landscape could look really different today. Notably it would have also liberated port numbers from their semi-fixed status; you could run any service on any port completely transparently, no need to worry about port collisions and whatnot. Note that Vixie is co-author of SRV RFC
  - marcus0x62 3y ago
    It's even weirder and more frustrating when you look at RR types like WKS and HINFO that were included in the original spec. Rather than be able to say "I run this service/variant on this port", they included a way to specify which well-known services were running (at the DNS configuration level,) but on the wire it is just a bitmap of putatively open ports.
mort96 3y ago
As far as I'm concerned, DKIM and DMARC are just tools to ensure that legitimate e-mail gets lost while not making a difference to spam.
- LeonM 3y ago
  DKIM and DMARC are not anti-spam measures, they are anti fraud measures. Signing email with DKIM, and mandating DKIM alignment via DMARC is a very powerful method for preventing unauthorized email from your domain.
  - crotchfire 3y ago
    Nobody cares about that. If I want to be sure that an email came from a certain person, I ask for a PGP signature on it.
ysofunny 3y ago
a globally accessible, replicated database that should be writeable by anybody and which contains autoritative data about which number (IP) maps to which name? seems like a use case for a blockchain???? runs for cover
- smaudet 3y ago
  Yes. This was proposed over 10 years ago. I even proposed this back then... Its a great idea but the same forces that (were|did) threaten(ing) to corrupt DNS got involved in the web 3.0 and thoroughly corrupted that to... Power (and money) corrupts completely. You cannot have a public service that is based upon monetized (share-holder backed) services.
- oasisaimlessly 3y ago
  See namecoin, the very first Bitcoin fork. https://www.namecoin.org/ https://www.namecoin.org/
snowwrestler 3y ago
DKIM and DMARC are not intended to address spam (a flood of low-quality commercial and scam emails). They are intended, along with SPF, to address impersonation, which is a distinct problem (although some spam does employ impersonation). They work just as well for minor email providers as they do for major ones. Even better, in some cases, because many small email providers are corporate IT departments, who tend to filter aggressively on those signals.
- dspillett 3y ago
  > * DKIM and DMARC are not intended to address spam […] They are intended, along with SPF, to address impersonation, which is a distinct problem (although some spam does employ impersonation). I would wager that the vast majority of true spam⁰ currently being sent, based on what my mail server sees, involves impersonation, because it is mostly messages that are not intended to be replied to by mail. You are in most cases instead told to go to a website or call a phone number if it is a “business opportunity” or to send money to a crypto-wallet in the case of a scam. This means that DKIM and SPF are increasingly effectively an anti-spam measure even if you argue that this is not their primary direct intent, because of the large overlap. I would argue that spam is one of their primary targets: junk mailers started faking addresses from real domains where they would otherwise have just included a completely fake address in response to recipient mail servers discarding mail that didn't appear to at least come from a valid domain. Some junk mail more deliberately uses impersonation, to convince the end recipient that it comes from the impersonated individual/group, but much of it does so just to convince the mail server to actually deliver the message. Yes, some genuine junk doesn't use impersonation (the hosting providers that buy mailing lists from other hosts as they close down, and other businesses doing the same, and damned recruiters, for two examples) – but not the majority IME. -- [0] In “true” spam, I'm discounting newsletters and mailing lists that people forgot they signed up for, or signed up for to get a discount but don't really want, etc.

zcw100 3y ago

Does an MX record make it a “database of convenience”? You don’t have to serve any of those records. I’m not saying there isn’t a problem with email but just that it’s not a problem with DNS.

marcus0x62 3y ago

The inventors of DNS originally envisioned a lot more email-related “catalog of convenience” data in the DNS. Go lookup MD, MF, MAILA, MB, MG, MR, MINFO, and MAILB records in the original spec[0] 0 - https://www.rfc-editor.org/rfc/rfc1035 https://www.rfc-editor.org/rfc/rfc1035

kps 3y ago
I think it's merely annoying that DMARC, DKIM, et al are all TXT records with magic fake domain names because record types ossified. Also, the web ‘public suffix list’ should be a DNS property instead.
- teddyh 3y ago
  Better a silly underscore subdomain than a plethora of TXT records, which was once a real problem, and threatened to overwhelm the apex domain. But yes, the abandonment of the SPF record type was disappointing.
  - Avamander 3y ago
    It was clear that the record type significantly hindered the deployment, which is why. If initial implementations wouldn't have been so strict at enforcing a small subset of types, things might be different.
- crotchfire 3y ago
  Also, the web ‘public suffix list’ should be a DNS property instead. Unfortunately the public suffix list has serious security implications, so it isn't safe to distribute it via unauthenticated DNS. It also has very serious availability implications, so if you sign it with the WebPKI-maximum validity of 90 days and somehow and those signatures expire, you either get major vulnerabilities if you fail open or else an entire TLD (like ".com") breaks if you fail closed. You get to play this game every 90 days. Sounds like fun. https://www.digicert.com/blog/chromes-proposed-90-day-certificate-validity-period https://www.digicert.com/blog/chromes-proposed-90-day-certif... This is the fundamental problem with trying to have DNSSEC replace DNS (instead of augmenting it): signature revocation is Byzantine-Generals-complete, which means that you either sign something forever (like ssh keys) or for a fixed time period and treat nonrenewal as revocation. Nonrenewal-as-revocation sorta works for signing single domains; if one website's cert expires it isn't the end of the world. When you start trying to sign larger and larger fractions of the Domain Name space, moving up to ccTLDs and then the root, the stakes are just way too high. This is why DNSSEC will never displace unauthenticated DNS. The choices are to stick with unauthenticated DNS, or maintain both systems in parallel forever. There is no third option where unsigned DNS records just go away.
  - cryptonector 3y ago
    > This is the fundamental problem with trying to have DNSSEC replace DNS (instead of augmenting it): DNSSEC does not replace DNS. DNSSEC augments DNS. > [stuff about revocation] Much of what you wrote there is erroneous: > [..] you either sign something forever (like ssh keys) or for a fixed time period and treat nonrenewal as revocation. In DNSSEC you revoke by publishing new public keys in a DS record at the delegation and deleting the old public keys, also at the delegation. No need to worry about expiration -- the DS record has none. There is no expiration in the DS record but that's not "you sign something forever" because the DS record is signed by an RRSIG record that has an expiration. Zone operators have to re-sign RRSIG records, but that's not really a problem. So revocation in DNSSEC is easy, and you can do it as often as the TTL on the DS RR allows. Revocation in PKI is much harder, unless one just goes for short-lived certificates. By automating certificate renewal operations, Let's Encrypt is doing the world a favor, as it will allow servers to have very short-lived certificates, thus eliding the need for revocation (and keeping CRLs small if recovation is still needed). > [...] if one website's cert expires it isn't the end of the world. When you start trying to sign larger and larger fractions of the Domain Name space, moving up to ccTLDs and then the root, the stakes are just way too high. Now this is true but it shouldn't be any more likely than other whole-domain outage failure modes of DNS. If you publish the wrong DS records at the delegation, your domain will be out -- don't do that! That's like publishing the wrong NS records at the delegation. The delegator can also break the delegation on their own, but they can do that w/o DNSSEC too, so you're no more and no less at their mercy w/ or w/o DNSSEC. And if you fail to re-sign your zones, you'll have some outages. In practice the right way to do the last is to sign dynamically in your DNS servers using ECC and with some caching, naturally. > This is why DNSSEC will never displace unauthenticated DNS. > > The choices are [...] The predicate is erroneous, so the conclusion doesn't follow from it. It might follow from other issues, but not the ones you stated.
zokier 3y ago
It's a shame that SRV records were not included in DNS from beginning, the landscape could look really different today. Notably it would have also liberated port numbers from their semi-fixed status; you could run any service on any port completely transparently, no need to worry about port collisions and whatnot. Note that Vixie is co-author of SRV RFC
- marcus0x62 3y ago
  It's even weirder and more frustrating when you look at RR types like WKS and HINFO that were included in the original spec. Rather than be able to say "I run this service/variant on this port", they included a way to specify which well-known services were running (at the DNS configuration level,) but on the wire it is just a bitmap of putatively open ports.

mort96 3y ago

As far as I'm concerned, DKIM and DMARC are just tools to ensure that legitimate e-mail gets lost while not making a difference to spam.

LeonM 3y ago
DKIM and DMARC are not anti-spam measures, they are anti fraud measures. Signing email with DKIM, and mandating DKIM alignment via DMARC is a very powerful method for preventing unauthorized email from your domain.
- crotchfire 3y ago
  Nobody cares about that. If I want to be sure that an email came from a certain person, I ask for a PGP signature on it.

ysofunny 3y ago

a globally accessible, replicated database that should be writeable by anybody and which contains autoritative data about which number (IP) maps to which name? seems like a use case for a blockchain???? runs for cover

smaudet 3y ago
Yes. This was proposed over 10 years ago. I even proposed this back then... Its a great idea but the same forces that (were|did) threaten(ing) to corrupt DNS got involved in the web 3.0 and thoroughly corrupted that to... Power (and money) corrupts completely. You cannot have a public service that is based upon monetized (share-holder backed) services.
oasisaimlessly 3y ago
See namecoin, the very first Bitcoin fork. https://www.namecoin.org/ https://www.namecoin.org/

snowwrestler 3y ago

DKIM and DMARC are not intended to address spam (a flood of low-quality commercial and scam emails). They are intended, along with SPF, to address impersonation, which is a distinct problem (although some spam does employ impersonation). They work just as well for minor email providers as they do for major ones. Even better, in some cases, because many small email providers are corporate IT departments, who tend to filter aggressively on those signals.

dspillett 3y ago
> * DKIM and DMARC are not intended to address spam […] They are intended, along with SPF, to address impersonation, which is a distinct problem (although some spam does employ impersonation). I would wager that the vast majority of true spam⁰ currently being sent, based on what my mail server sees, involves impersonation, because it is mostly messages that are not intended to be replied to by mail. You are in most cases instead told to go to a website or call a phone number if it is a “business opportunity” or to send money to a crypto-wallet in the case of a scam. This means that DKIM and SPF are increasingly effectively an anti-spam measure even if you argue that this is not their primary direct intent, because of the large overlap. I would argue that spam is one of their primary targets: junk mailers started faking addresses from real domains where they would otherwise have just included a completely fake address in response to recipient mail servers discarding mail that didn't appear to at least come from a valid domain. Some junk mail more deliberately uses impersonation, to convince the end recipient that it comes from the impersonated individual/group, but much of it does so just to convince the mail server to actually deliver the message. Yes, some genuine junk doesn't use impersonation (the hosting providers that buy mailing lists from other hosts as they close down, and other businesses doing the same, and damned recruiters, for two examples) – but not the majority IME. -- [0] In “true” spam, I'm discounting newsletters and mailing lists that people forgot they signed up for, or signed up for to get a discount but don't really want, etc.