I’m not sure what you’re talking about. DNSSEC is alive and well and protects DNS in-flight from modification. Any client with proper DNSSEC implemented will drop any forged DNS response from an attackers dns server and prevent them from loading whatever resource they were trying to access. Personally, I see DNSSEC as the perfect solution to the problem of the limited selection of third party resolvers outside the major players (Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, Quad 9, and other major providers). Anybody can set up a recursive DNS server and start redirecting traffic whenever they please but if that the server has DNSSEC enabled then I’m going to have more trust that this server is not going to return bad records to me. The reason you see people have issues with it is because a lot of people aren’t reading through the entire implementation guidelines and making mistakes in their management of it. I have been running DNSSEC across a majority of my domains and while I can’t make claim to any “attacks” that may or may not have been stopped, I have never suffered an outage because of DNSSEC. I have a script that runs every night at midnight on my DNS servers that sign my zones every night at midnight and updates my serials to the current date+00 (eg today would be 2021120900) to prevent my signatures from aging out. If ICANN can automate the signing of the Internet roots every night at midnight, you can too. If your “auditing” is based solely on when your serial numbers have changed then I’m sorry but that is not proper DNS change auditing, don’t fool yourself. Ideally the server you use to sign your DNS zones should NOT be the same servers you expose publicly onto the Internet to prevent your keys from getting stolen and attackers changing your records without your knowledge. In response to what happened to NetNod, if hackers are able to get into your domain registrar you have much bigger problems and you need to move away from that registrar as fast as possible. Anybody who is not implementing 2FA and is running a domain registrar is not taking your domain security seriously and do not deserve your business. Best, Francis Booth
On Dec 9, 2021, at 9:36 AM, Ca By <cb.list6@gmail.com> wrote:
On Thu, Dec 9, 2021 at 1:07 AM Arne Jensen <darkdevil@darkdevil.dk> wrote: Den 08-12-2021 kl. 15:32 skrev Niels Bakker:
* darkdevil@darkdevil.dk (Arne Jensen) [Wed 08 Dec 2021, 15:23 CET]:
To me, that part of it also points towards a broken implementation at CloudFlare, letting a bogus (insecure) responses take effect anyway.
Or they prefer allowing people to visit websites over punishing system administrators for operational failures that less secure (read: nonvalidating) ISPs wouldn't inflict on their customers. I find it hard to believe that CloudFlare would do such though, however, while such kind of things could indeed be the cause, I'm personally going towards "Rather safe, than sorry".
It's been quite common for DNSSEC-enabled recursors to add overrides for outaged domains in situations like this.
Unfortunately, yes, overrides are too common for many different things. Time for them (the overrides) to die completely.
Or accept that dnssec has always been dead since it never solved a problem, but created a lot of problems.
Just saying, facts are on my side. Check the number of times dnssec caused an outage. Then check the number of hacks prevented by dnssec. Literally 0.
Be sure to note the time Netnod got hacked because the perps… turned off dnssec…
https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns...
Look, i dont have anything personal against dnssec. Just as much as any droid, i love
1. 3rd rate crypto
2. Many enabled RCEs
3. Complex architectures , doubly complex operational procedure
4. Government managed CAs and then related procurement requirements
But, the thing i dont like is the massive ddos it creates. Those huge records are really not acceptable into today’s dns environment.
Please stop enabling dnssec on your domain folks, you are going to have outage, your security is worse off, and you feeding the vendor / hacker ddos death spiral
It looks like the error has been mitigated, by the way, so this manual override may not even have happened.
+1.
-- Med venlig hilsen / Kind regards, Arne Jensen