[scrollaway]

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

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]

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/

[mattashii]

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]

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

[nemothekid]

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

[pixl97]

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.

[medguru]

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

[belorn]

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]

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.

[aseipp]

HTTPS also guarantees integrity of the content; even for read-only sites it's important to ensure content isn't modified, code isn't injected, etc. There's an argument that a protocol which does integrity-checks only (without data encryption) might be good, that's the NONE cipher in TLS but it was removed in TLS 1.3 I believe; but it wouldn't fundamentally change the problem with 15yo operating systems lacking the software support or whatever.

(More broadly though the operational overhead of software is really high these days in a lot of ways. I think that's true of anything, not just HTTPS, but there are a lot of other historical factors leading to that.)

I think it's a bit of a leap to suggest that just doing things like banning mass surveillance would magically make systems more stable or make 15yo operating systems suddenly relevant on the net again. We'd probably still need a lot of the stuff we have in place already. However, I suggest we try it anyway because there's only one way to find out and oh well we won't lose anything valuable anyway.

[shkkmo]

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

Did you notice the "read only sites" part? MITM is hardly relevant for those.

[sunaurus]

You should still protect against MITM attacks even with read-only websites - not all attacks are based on stealing user input.

[xoa]

>Did you notice the "read only sites" part? MITM is hardly relevant for those.

I'm sorry but you're not thinking this through very carefully. People still care about authentication of read-only stuff, in the same way much (and it should be all) open source software, particularly from repositories, is signed these days. A great deal of mischief can be done by modifying info in flight, even ignoring privacy concerns entirely. Plenty of not just governmental but corporate bodies could benefit by being able to trivially rewrite whatever populations (or targeted segments of populations) read. Even ignoring what a vector it could be for other attacks. In principle, we could have some universal standard for signing and authenticating as unaltered websites without bothering to encrypt them. But frankly that seems pointless vs just having encryption as well.

Further, like all practical public crypto use in the face of adversaries, there is a lot of benefit from using it universally and thus "hiding in the herd". Otherwise, the mere usage of crypto itself is a signal, and also easier to target and block (not just technically but via laws). Whereas when it's just baked into literally everything that's much harder to outright infeasible, and also destroys that extra bit of signal.

This was all debated and considered extensively while the moves to universal HTTPS were happening. People moved read-only sites as well for a reason.

[shkkmo]

Examples of read only sites that adversaries might want to alter the content you see:

Your banks support numbers, election poll information, binary downloads/checksums are some really critical ones but the list is really endless given the wide range of possible adversaries and their motives.

One big advantage to pushing HTTPS everywhere is that we don't have to trust people to be able to correctly predict which read only content is sensitive.

I do wish browsers handled expired certs for longstanding sites in a way that was clearer to nontechnical people. We should have the ability to look at a project like the Internet Archive to know the history of a site in terms of both content and the certs it was served under.

[antihero]

It really isn’t hard now there’s letsencrypt. We’ll never live in a world where a connection between the client and server can be completely trusted.

HTTPS is wonderful because it offers a guarantee that the data isn’t tampered with (except with corporate root CAs, but that is fuckery).

[toast0]

LetsEncrypt removes the cost of certificates, and ACME removes the work of getting certificate issues, and decent integrations remove the work of loading new certificates and that's all great.

But LE doesn't remove the compatability challenges. If you needed to ship a device today that would sit in a box for 10 years and then get online and get an update via https, that's really hard to do. TLS protocols sometimes get discouraged, and CA changes happen, etc.

[emteycz]

Do you think criminals care about the law?

[the8472]

Criminals are much less likely to engage in MITM attacks, besides TLAs it's usually shady ISPs who want to inject some content (similar to surveillance that could be made illegal too, ISPs would in fact care). And criminals also have little incentive to attack read-only sites. Even if they did it might be more efficient to allocate resources to law enforcement rather than securing everything that could theoretically be attacked by criminals.

[emteycz]

They're not attacking the sites, they're attacking the users. Incentives are exactly the same with readonly sites.

I'm a web programmer and I have no idea how the law enforcement could in any way help. Nor do I want them to. The idea that I have to cooperate with law enforcement to put a site online is absurd.

See "Tech support scams" on YouTube to see what's being done today. We're talking about billion-dollar crime organizations.

[rapind]

Wordpress begs to differ. There are tons of examples of malicious JS on read only sites. Doesn’t have to be MitM. Usually it’s to generate ad views on another site, but can be more nefarious.

[ziddoap]

>Criminals are much less likely to engage in MITM attacks

Can you provide a source, or even just reasoning, to why this would be true? In my experience, MiTM is a common enough attack vector used by criminals.

[warrenm]

> 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

Sorry, but this argument doesn't hold water

And this coming from someone who supports systems still running NT 4

I have fallback rules enabled on all of my domains - TLS 1.3 is preferred, but older editions will be supported if the need arises (1.2, 1.1, and 1.0 (on a single domain))

[neurostimulant]

If your service must meet some strict certifications (e.g. PCI DSS), simply enabling old tls/ssl protocols for backward compatibility is not an option.

[the8472]

Doesn't that enable downgrade attacks?

[warrenm]

When you need to support older OSes, does it matter?

[TedDoesntTalk]

HTTPS is indeed broken when viewing it from a site reliability perspective. Anyone who has maintained more than a handful of domains simultaneously will agree (personally I’ve managed hundreds, each with their own certificate … it’s an awful experience).

[middleclick]

Awful in what sense though? I also maintain many domains and have not touched them in years since their initial setup, with LetsEncrypt (and the Certbot renewal timer).

[verdverm]

I've had several sites with HTTPS work for many years now with zero effort or SRE time. Let's Encrypt via certbot handles it all for me

[baisq]

Lucky you. I’ve had multiple problems like rate limits, cron not firing, let’s encrypt servers not being able to see challenge files because of obscure rewrite rules… it’s far from flawless

[jtbayly]

It’s very sad that new SSL sites just don’t work on older computers that work just fine still. We’re not talking about complicated sites that wouldn’t work anyway without new browsers. Just basic HTML.

[theamk]

Eh, except that HTTPS actually has tangible benefits, unlike DNSSEC.

[belorn]

Much of the Internet right now uses DNS as proof of authentication. Having authentication system be a plain text protocol without any integrity or validation is a recipe for abuse. Right now the work-around is to have multiple resolver spread out all over the world and query the name servers multiple times to detect malicious actors, which is a much worse solution that dnssec if you ask me. It doesn't scale well and is a hack on top of an insecure protocol in order to create a sense of security.

We could return back to IPsec, or tunnel everything under https as a more modern version of IPsec, but those solutions are all disliked depending on who you ask.

[kevincox]

Without DNSSEC anyone can intercept your email. The TLS cert verified by mail is the domain pointed to by the MX record. Plus with DKIM keys store in DNS people can spoof email (if they can fool the receiver to trust their records). If you can fool DNS resolution for LetsEncrypt (pretty hard since IIRC they fetch DNS from multiple perspectives on the internet to mitigate this) you can get certificates for any hostname.

There are other solutions such as MTA-STS and DNS-over-HTTP but the end-to-end validation of DNSSEC is pretty powerful.

[Spooky23]

DNSSEC doesn’t really solve any problems that you have nor does it meaningfully prevent any security risks.

It does create a lot of operational risk, as you’ve discovered. It also checks a box if you’re building a system for the US Federal .gov.

tptacek has written about this at length on this site and other places.

[theamk]

Basically, it is lots of extra work effort for no real security advantages. Other people wrote a lot about it, here is an example:

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

[teddyh]

Rebuttal: https://easydns.com/blog/2015/08/06/for-dnssec/