4 ms·

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 M

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.
    - crotchfire 3y ago
      > No need to worry about expiration -- the DS record has none. > the DS record is signed by an RRSIG record that has an expiration You've just contradicted yourself. > No need to worry about expiration If that were true, which it isn't, a MITM could keep feeding old signatures to the victim. You seem to have little idea what you're talking about.
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.

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.
  - crotchfire 3y ago
    > No need to worry about expiration -- the DS record has none. > the DS record is signed by an RRSIG record that has an expiration You've just contradicted yourself. > No need to worry about expiration If that were true, which it isn't, a MITM could keep feeding old signatures to the victim. You seem to have little idea what you're talking about.

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.