11 ms·

> what's the fastest way to get technical assistance when on a free plan? Upgrading to a non-free plan? You don't have to upgrade to enterprise, but even thei

> what's the fastest way to get technical assistance when on a free plan? Upgrading to a non-free plan? You don't have to upgrade to enterprise, but even their $20/mo plan comes with support. (Also, I hate to victim-blame here but using DNSSEC was a bad idea in the first place)

tmikaeld 4y ago
Why was enabling DNSSEC a bad idea? Clearly the origin registrar isn't handling DNSSEC requests properly, but the OP should still be able to revert to non-DNSSEC without issues.
- scrollaway 4y ago
  This post makes a better argument than I could write. And nothing much has changed in the seven years since. https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/
  - mattashii 4y ago
    That article is a bad example of outdated arguments and whataboutisms. Sure, DNSSEC has some issues, but none are so bad that it means you shouldn't use it: It does help resolvers detect various attacks (e.g. cache poisoning, BGP hijacks, MitMs), which is fairly critical for security-minded organizations. (from that article, that is from 2015 and woefully outdated) > With TLS properly configured, DNSSEC adds nothing. This is false. DNSSEC adds address lookup security through response integrity, whereas TLS (only!) adds transport layer security to the endpoint you're connected to (hence the name). If you find a record in DNS with DNSSEC enabled, you know that the response is exactly as the sender intended it to be (and when connecting to the address returned for A- or AAAA-records, you'll be connecting to the intended IP address). Without DNSSEC, this is impossible to guarantee and record interception / MitM would be an attack vector. Additionally, "With TLS correctly configured" also implies CAA being set up, which only can be done securely using DNSSEC. As to why CAA must be configured: Not all CAs are made the same; and re-routing network traffic is fairly doable if you only need to target one of the many public CAs. Targeting only that CA allowed in the CAA record is presumably much harder. > Securing DNS lookups isn’t a high-priority task > DNSSEC’s real job is thus to replace the TLS CA system. This plan is called DANE. No, DNSSEC's job _is_ to secure DNS lookups. DANE is only one scheme that is made possible by DNSSEC; Secure CAA checking being another. > Real-world DNSSEC therefore relies on RSA with PKCS1v15 padding. Correct, but also relies on Ed25519 and P-256. A lot of authorative servers are still using the legacy RSA keys, but another lot is using P-256 and Ed25519 too. > [sections] DNSSEC is Expensive To Adopt / Deploy This is partly true, but any security is expensive to adopt/deploy. DNSSEC is fairly easy nowadays, though, with many hosted DNS services providing some form of DNSSEC. > DNSSEC doesn’t secure browser DNS lookups. It would, if you allowed your browser to recurse. > DNSSEC is Unsafe > Authenticated denial. Offline signers. Secret hostnames. Pick two. That's fine. Secrecy doesn't add security; Authenticated denial and Offline signers do. > DNSSEC is Architecturally Unsound I disagree with the conclusion here. Sure, it might be useful for US gov to be the writer of the spec, but what public scrutiny DNSSEC has had implies that the security part is sound.
    - peppermint_tea 4y ago
      I'm with you here. I automated my dnssec setup, and I barely think about it. I really wish my bank would use it and stop calling javascript from domains unknown to me :)
- pixl97 4y ago
  Wasn't there a thread on HN within the last couple of months that says switching back when things go wrong is actually very difficult? Intermediate servers or something cache the DNSSEC issues and things tend to break for 24 hours at a time. Unfortunately I can't remember the details.
- nemothekid 4y ago
  >but the OP should still be able to revert to non-DNSSEC without issues. Slack had a 24 hour outage doing exactly that; so I don't think "revert to non-DNSSEC without issues" is trivial at all.
deleted 4y ago
[deleted]
medguru 4y ago
Can you please explain why DNSSEC was a bad idea in the first place? It worked perfectly fine with the old registrar.
- belorn 4y ago
  It like https. A lot of people in the past viewed HTTPS as a terrible idea that just broke things, and every example where someone had their website go down because of broken certificates or mixed content was proof that https as a concept was broken. Usually people brought up x.509 or revocation lists as the definitive proof that https would never be common.
  - the8472 4y ago
    From a site reliability perspective HTTPS is still broken. Some 15yo OS can't access any site because it doesn't have the certificates or cipher suites. And as you mentioned we need to update certs, webservers and DNS all the time to keep up to date. We only put up with it because it protects users from from snoopers. But that means we live in an inadequate equilibrium. If we abolished mass surveillance rather than impeding it with technical measures then we wouldn't need encryption for read-only sites, we could have our cake and eat it too.
    - shkkmo 4y ago
      > If we abolished mass surveillance then we wouldn't need encryption for read-only sites, we could have our cake and eat it too. Mass surveillance is not the only reason to have HTTPS everywhere. It protects not just from snoopers, but from MITM attacks.
      - the8472 4y ago
        Did you notice the "read only sites" part? MITM is hardly relevant for those.
        sunaurus 4y ago

tmikaeld 4y ago

Why was enabling DNSSEC a bad idea? Clearly the origin registrar isn't handling DNSSEC requests properly, but the OP should still be able to revert to non-DNSSEC without issues.

scrollaway 4y ago
This post makes a better argument than I could write. And nothing much has changed in the seven years since. https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/
- mattashii 4y ago
  That article is a bad example of outdated arguments and whataboutisms. Sure, DNSSEC has some issues, but none are so bad that it means you shouldn't use it: It does help resolvers detect various attacks (e.g. cache poisoning, BGP hijacks, MitMs), which is fairly critical for security-minded organizations. (from that article, that is from 2015 and woefully outdated) > With TLS properly configured, DNSSEC adds nothing. This is false. DNSSEC adds address lookup security through response integrity, whereas TLS (only!) adds transport layer security to the endpoint you're connected to (hence the name). If you find a record in DNS with DNSSEC enabled, you know that the response is exactly as the sender intended it to be (and when connecting to the address returned for A- or AAAA-records, you'll be connecting to the intended IP address). Without DNSSEC, this is impossible to guarantee and record interception / MitM would be an attack vector. Additionally, "With TLS correctly configured" also implies CAA being set up, which only can be done securely using DNSSEC. As to why CAA must be configured: Not all CAs are made the same; and re-routing network traffic is fairly doable if you only need to target one of the many public CAs. Targeting only that CA allowed in the CAA record is presumably much harder. > Securing DNS lookups isn’t a high-priority task > DNSSEC’s real job is thus to replace the TLS CA system. This plan is called DANE. No, DNSSEC's job _is_ to secure DNS lookups. DANE is only one scheme that is made possible by DNSSEC; Secure CAA checking being another. > Real-world DNSSEC therefore relies on RSA with PKCS1v15 padding. Correct, but also relies on Ed25519 and P-256. A lot of authorative servers are still using the legacy RSA keys, but another lot is using P-256 and Ed25519 too. > [sections] DNSSEC is Expensive To Adopt / Deploy This is partly true, but any security is expensive to adopt/deploy. DNSSEC is fairly easy nowadays, though, with many hosted DNS services providing some form of DNSSEC. > DNSSEC doesn’t secure browser DNS lookups. It would, if you allowed your browser to recurse. > DNSSEC is Unsafe > Authenticated denial. Offline signers. Secret hostnames. Pick two. That's fine. Secrecy doesn't add security; Authenticated denial and Offline signers do. > DNSSEC is Architecturally Unsound I disagree with the conclusion here. Sure, it might be useful for US gov to be the writer of the spec, but what public scrutiny DNSSEC has had implies that the security part is sound.
  - peppermint_tea 4y ago
    I'm with you here. I automated my dnssec setup, and I barely think about it. I really wish my bank would use it and stop calling javascript from domains unknown to me :)
pixl97 4y ago
Wasn't there a thread on HN within the last couple of months that says switching back when things go wrong is actually very difficult? Intermediate servers or something cache the DNSSEC issues and things tend to break for 24 hours at a time. Unfortunately I can't remember the details.
nemothekid 4y ago
>but the OP should still be able to revert to non-DNSSEC without issues. Slack had a 24 hour outage doing exactly that; so I don't think "revert to non-DNSSEC without issues" is trivial at all.

deleted 4y ago

[deleted]

medguru 4y ago

Can you please explain why DNSSEC was a bad idea in the first place? It worked perfectly fine with the old registrar.

belorn 4y ago
It like https. A lot of people in the past viewed HTTPS as a terrible idea that just broke things, and every example where someone had their website go down because of broken certificates or mixed content was proof that https as a concept was broken. Usually people brought up x.509 or revocation lists as the definitive proof that https would never be common.
- the8472 4y ago
  From a site reliability perspective HTTPS is still broken. Some 15yo OS can't access any site because it doesn't have the certificates or cipher suites. And as you mentioned we need to update certs, webservers and DNS all the time to keep up to date. We only put up with it because it protects users from from snoopers. But that means we live in an inadequate equilibrium. If we abolished mass surveillance rather than impeding it with technical measures then we wouldn't need encryption for read-only sites, we could have our cake and eat it too.
  - shkkmo 4y ago
    > If we abolished mass surveillance then we wouldn't need encryption for read-only sites, we could have our cake and eat it too. Mass surveillance is not the only reason to have HTTPS everywhere. It protects not just from snoopers, but from MITM attacks.
    - the8472 4y ago
      Did you notice the "read only sites" part? MITM is hardly relevant for those.
      - sunaurus 4y ago