Anyone else seeing DNSSEC failures from EU Commission ? (european-union.europa.eu)

Thu Dec 9 23:22:04 UTC 2021

> On 10 Dec 2021, at 01:36, Ca By <cb.list6 at gmail.com> wrote:
> 
> 
> 
> On Thu, Dec 9, 2021 at 1:07 AM Arne Jensen <darkdevil at darkdevil.dk> wrote:
> Den 08-12-2021 kl. 15:32 skrev Niels Bakker:
> > * darkdevil at 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. 

How do you know?  Unless you investigated every single time DNSSEC validation returned bogus to get to the
root cause you cannot know.

> 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-hijacking-attacks/
> 
> 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. 

Does it really or is it vendors failing to apply mechanisms that can stop large UDP responses to spoofed requests?

DNS does support 3 way handshakes over UDP (See RFC 7873 Domain Name System (DNS) Cookies).  If your resolver is
not sending requests with DNS COOKIEs present you should be asking yourself “why are you using such an outdated
platform”?   If your resolver or authoritative server doesn’t reply with a SERVER COOKIE to a request with a DNS
COOKIE present you should be asking yourself why are you continuing to use this outdated software which doesn’t
help protect both the client and server from spoofed traffic.  You can deploy DNS COOKIE independently on the
server and client sides so you don’t have to wait for the other side to enable it.

For requests without DNS COOKIEs present there is RRL mechanisms.

> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org