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

[Masataka Ohta]

Mark Andrews wrote:


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.

How?

Because most birthday attacks for plain DNS will fail, you can
almost always know DNSSEC answer is bogus by comparing answers
from DNSSEC and plain DNS.

That the root cause may not be known is not a problem.

Masataka Ohta

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

[Masataka Ohta]

Arne Jensen wrote:


    Because every authoritative RRset in a zone must be protected by a
    digital signature, RRSIG RRs must be present for names containing a
    CNAME RR.  This is a change to the traditional DNS specification
    [RFC1034], which stated that if a CNAME is present for a name, it is
    the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
    MUST exist for the same name as a CNAME resource record in a signed
    zone.

Can you tell me what exactly this means?


Hmm, it should means specification of rfc4034 is incomplete.

That is, the rfc certainly specifies that domain name for CNAME
may also have RRSIG.

However, the rfc does not say that, if a query to a server is
for CNAME, the server must also return RRSIG.

Worse, even if authoritative namesevers return both CNAME and
RRSIG, if TTL of CNAME is longer than that of RRSIG, cache of
a resolver may only contain CNAME. Or, if a resolver is not
aware of DNSSEC, RRSIG won't be returned for CNAME query.

As such, when a query for CNAME does not return RRSIG, resolvers
must explicitly ask RRSIG by another query message, specification
for which is missing in the rfc.

Masataka Ohta

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

[Mark Andrews]

> On 10 Dec 2021, at 01:36, Ca By  wrote:
> 
> 
> 
> On Thu, Dec 9, 2021 at 1:07 AM Arne Jensen  wrote:
> Den 08-12-2021 kl. 15:32 skrev Niels Bakker:
> > * darkde...@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: ma...@isc.org

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

[Jean St-Laurent via NANOG]

I understand now and I agree with you that there’s something fishy there.

 

Fear sells.

 

Thanks

Jean

 

From: Ca By  
Sent: December 9, 2021 10:47 AM
To: Jean St-Laurent 
Cc: Arne Jensen ; nanog@nanog.org
Subject: Re: Anyone else seeing DNSSEC failures from EU Commission ? 
(european-union.europa.eu)

 

 

 

On Thu, Dec 9, 2021 at 7:15 AM Jean St-Laurent mailto:j...@ddostest.me> > wrote:

What is a ddos death spiral?

 

A closed circle economy where the vendor provides both the problem and the 
solution

 

https://krebsonsecurity.com/2020/01/ddos-mitigation-firm-founder-admits-to-ddos/

 

That is just one example. 

 

There are many large companies that could do a lot to make things more secure, 
but it is more profitable for them when things are a bit broken and they can 
charge more for a solution

 

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

[Ca By]

On Thu, Dec 9, 2021 at 7:15 AM Jean St-Laurent  wrote:

> What is a ddos death spiral?
>
>
>
A closed circle economy where the vendor provides both the problem and the
solution

https://krebsonsecurity.com/2020/01/ddos-mitigation-firm-founder-admits-to-ddos/

That is just one example.

There are many large companies that could do a lot to make things more
secure, but it is more profitable for them when things are a bit broken and
they can charge more for a solution



Jean
>
>
>
> *From:* NANOG  *On Behalf Of *Ca
> By
> *Sent:* December 9, 2021 9:36 AM
> *To:* Arne Jensen 
> *Cc:* nanog@nanog.org
> *Subject:* Re: Anyone else seeing DNSSEC failures from EU Commission ? (
> european-union.europa.eu)
>
>
>
> and you feeding the vendor / hacker ddos death spiral
>

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

[Nick Hilliard]

Ca By wrote on 09/12/2021 14:36:
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.


it serves a purpose.  There are plenty of actors, both public and 
private sector, who would be happy to announce their own local 
.root-servers.net address blocks, with consequent security issues for 
all end users at the receiving end (+ leakage causing collateral 
damage). For all its other flaws, dnssec makes this style of dns 
compromise difficult.


Nick

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

[Jean St-Laurent via NANOG]

What is a ddos death spiral?

 

Jean

 

From: NANOG  On Behalf Of Ca By
Sent: December 9, 2021 9:36 AM
To: Arne Jensen 
Cc: nanog@nanog.org
Subject: Re: Anyone else seeing DNSSEC failures from EU Commission ? 
(european-union.europa.eu)

 

and you feeding the vendor / hacker ddos death spiral

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

[Francis Booth via NANOG]

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  wrote:
> 
> 
> 
> On Thu, Dec 9, 2021 at 1:07 AM Arne Jensen  wrote:
> Den 08-12-2021 kl. 15:32 skrev Niels Bakker:
> > * darkde...@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-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. 
> 
> 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

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

[Ca By]

On Thu, Dec 9, 2021 at 1:07 AM Arne Jensen  wrote:

> Den 08-12-2021 kl. 15:32 skrev Niels Bakker:
> > * darkde...@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-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.

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

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

[Arne Jensen]

Den 08-12-2021 kl. 15:32 skrev Niels Bakker:

* darkde...@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.




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

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

[Arne Jensen]

Den 08-12-2021 kl. 16:23 skrev Masataka Ohta:

Arne Jensen wrote:


It is my understanding that the CNAME should never have been followed,


Wrong.


Hmm, okay.

-> https://www.rfc-editor.org/rfc/rfc4034.txt

Section 3, "The RRSIG Resource Record", at the third phrase:


Because every authoritative RRset in a zone must be protected by a
digital signature, RRSIG RRs must be present for names containing a
CNAME RR.  This is a change to the traditional DNS specification
[RFC1034], which stated that if a CNAME is present for a name, it is
the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
MUST exist for the same name as a CNAME resource record in a signed
zone.

Can you tell me what exactly this means?

I fail to see that RRSIG in the following output:


$ dig +dnssec  european-union.europa.eu @1.1.1.1

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> +dnssec  
european-union.europa.eu @1.1.1.1

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16457
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; OPT=15: 00 00 72 65 73 65 72 76 65 64 20 44 53 20 61 6c 67 6f 72 69 
74 68 6d ("..reserved DS algorithm")

;; QUESTION SECTION:
;european-union.europa.eu.  IN  

;; ANSWER SECTION:
european-union.europa.eu. 1800  IN  CNAME 
d1d395kgk3q1uk.cloudfront.net.
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:ea00:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:8200:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:4c00:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:1c00:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:e600:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:3a00:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:f600:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:2000:13:6ecf:b700:93a1


;; Query time: 68 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Dec 08 14:53:06 CET 2021
;; MSG SIZE  rcvd: 347

$


So maybe you would care to elaborate why I am wrong, and why Google and 
Quad9 is wrong too, while CloudFlare is actually doing the "right" thing 
here?


I would still, with the above output, say that CloudFlare shouldn't have 
followed the CNAME at that time.




since there isn't any covering RRSIG for the actual CNAME, exactly as 
the elaborative message on dnsviz.net claims.


That CNAME RR is authenticated means it securely points to some
other domain name, which may or may not be covered by RRSIG
signature, which is no different from domain names pointed by
signed MX RRs.


Both the CNAME RR (european-union.europa.eu) and MX RR's (your mention) 
must have a valid RRSIG when they are within a DNSSEC signed zone, but 
the CNAME RR didn't, as you can see above.


With the timestamp above showing 14:53 CET, and my message appearing 
here at 15:22 CET, the DNSSEC issue was actually fixed within that time, 
so if you're first checking around your own message at 16:23, an hour 
after it had already been resolved, then you will of course see no 
issues, at all, which I am not either.


Seems like it was fixed ~4 minutes after my output above:


$ dig +dnssec  european-union.europa.eu @1.1.1.1

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> +dnssec  
european-union.europa.eu @1.1.1.1

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19554
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;european-union.europa.eu.  IN  

;; ANSWER SECTION:
european-union.europa.eu. 1800  IN  CNAME 
d1d395kgk3q1uk.cloudfront.net.
european-union.europa.eu. 1800  IN  RRSIG   CNAME 8 3 1800 
20220107135603 20211208125711 6276 europa.eu. 
Gu/Zmxulc0RhNnCE55ATi/yCIUxP4NK9/msFIqPJuBhGrZiGT9+KomfL 
XcgBGXlzNt24uE9cQo59/r6liN0BV4IA8k4DCwRKDp2dDJUSLYK6AvMa 
Og+VVAKZvvHJZI6C41vBnD/PJahf9660CvXazzBX5a/W8FGhhVXsUUKx 
6780SgvqiXPn0RRNdJ2ZUFzGfY6/kTXsfAkT0TN7ZgGHq6whp/TVoZYb 
vihl1NoiY4Ou/LFCtAmCJGWaT/h49kTCwIcq/5IgaBLn/CvcSz6YNXi0 
RAV4jx+IVlTMzxIgBUsnOrOIoVH3j6LhtUrymfspWESoWBD7mFOjreyh wG+icw==
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:d400:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:c800:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:9200:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:d200:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:c200:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     
2600:9000:2021:be00:13:6ecf:b700:93a1
d1d395kgk3q1uk.cloudfront.net. 60 IN     

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

[Masataka Ohta]

Ca By wrote:


It’s quite common for DNSSEC to fail at spectacular scale



What’s uncommon? Attacks that DNSSEC is intended to solve.



DNSSEC is considered harmful on the internet


Correct.

The problem is that PKI, in general, does not offer cryptographic
security but just assumes intelligent intermediate entities of CAs,
which are called trusted third parties, are trustworthy, which
is improper social, not cryptographic, assumption as was demonstrated
by a compromised CA of diginotar about 10 years ago.

https://en.wikipedia.org/wiki/DigiNotar

Masataka Ohta

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

[Masataka Ohta]

Arne Jensen wrote:


It is my understanding that the CNAME should never have been followed,


Wrong.

since there isn't any covering RRSIG for the actual CNAME, exactly as 
the elaborative message on dnsviz.net claims.


That CNAME RR is authenticated means it securely points to some
other domain name, which may or may not be covered by RRSIG
signature, which is no different from domain names pointed by
signed MX RRs.

Anyway, as so called secure DNS is merely weakly secure
subject to MitM attacks on intermediate zones, there is
no reason to use it only to increase operational efforts
purposelessly.

Masataka Ohta

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

[Ca By]

On Wed, Dec 8, 2021 at 6:35 AM Niels Bakker  wrote:

> * darkde...@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.
>
> It's been quite common for DNSSEC-enabled recursors to add overrides
> for outaged domains in situations like this.


It’s quite common for DNSSEC to fail at spectacular scale

It is also common for DNSSEC to be weaponized in colossal ddos attacks.

What’s uncommon? Attacks that DNSSEC is intended to solve.

Don’t wait for the rfc.

You dont need a weatheman.

DNSSEC is considered harmful on the internet



>
> It looks like the error has been mitigated, by the way, so this manual
> override may not even have happened.
>
>
> -- Niels.
>

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

[Niels Bakker]

* darkde...@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.


It's been quite common for DNSSEC-enabled recursors to add overrides 
for outaged domains in situations like this.


It looks like the error has been mitigated, by the way, so this manual 
override may not even have happened.



-- Niels.

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

[Arne Jensen]

Den 08-12-2021 kl. 14:35 skrev Marco Davids (Private) via NANOG:

Hi Laura,

Something seems the matter, indeed:

https://dnsviz.net/d/european-union.europa.eu/YbCzrQ/dnssec/

It's weird; 1.1.1.1 resolves, 8.8.8.8 and 9.9.9.9 return SERVFAIL.

It is my understanding that the CNAME should never have been followed, 
since there isn't any covering RRSIG for the actual CNAME, exactly as 
the elaborative message on dnsviz.net claims.


As such, the CNAME record cannot be verified to be authentic.

To me, that part of it also points towards a broken implementation at 
CloudFlare, letting a bogus (insecure) responses take effect anyway.


--
Med venlig hilsen / Kind regards,
Arne Jensen

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

[Laura Smith via NANOG]

Thanks Stephane.  I've subsequently had confirmation on the grapevine (indirect 
comms with CERT-EU) that they are indeed aware of a DNS issue but no detail or 
estimated fix time.

‐‐‐ Original Message ‐‐‐

On Wednesday, December 8th, 2021 at 13:40, Stephane Bortzmeyer 
 wrote:

> On Wed, Dec 08, 2021 at 01:27:23PM +,
>
> Laura Smith via NANOG nanog@nanog.org wrote
>
> a message of 18 lines which said:
>
> > Bit of a long stretch given the US audience, but I'm seeing lots of things 
> > like this at the moment:
>
> Indeed, they botched DNSSEC
>
> https://dnsviz.net/d/european-union.europa.eu/YbCzrQ/dnssec/
>
> Seen by RIPE Atlas probes:
>
> % blaeu-resolve --requested 100 --type A european-union.europa.eu
>
> [ERROR: SERVFAIL] : 48 occurrences
>
> ...
>
> Test #34367829 done at 2021-12-08T13:37:31Z

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

[Stephane Bortzmeyer]

On Wed, Dec 08, 2021 at 01:27:23PM +,
 Laura Smith via NANOG  wrote 
 a message of 18 lines which said:

> Bit of a long stretch given the US audience, but I'm seeing lots of things 
> like this at the moment:

Indeed, they botched DNSSEC


Seen by RIPE Atlas probes:

% blaeu-resolve  --requested 100 --type A european-union.europa.eu
[ERROR: SERVFAIL] : 48 occurrences
...
Test #34367829 done at 2021-12-08T13:37:31Z

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

[Mark Tinka]

On 12/8/21 15:27, Laura Smith via NANOG wrote:


Bit of a long stretch given the US audience, but I'm seeing lots of things like 
this at the moment:

info: validation failure : key for validation 
european-union.europa.eu. is marked as invalid because of a previous validation failure 
: DS got unsigned CNAME answer from 
2600:9000:5301:a200::1 and 34.255.155.194 for DS european-union.europa.eu. while building 
chain of trust

info: validation failure : DS got unsigned 
CNAME answer from 2600:9000:5302:9a00::1 and 34.255.155.194 for DS 
european-union.europa.eu. while building chain of trust

validation failure : signatures from unknown keys from 
147.67.12.3

info: validation failure : signatures from unknown keys 
from 147.67.12.3


Both of these are showing a number of issues:

https://dnssec-analyzer.verisignlabs.com/european-union.europa.eu
    https://dnsviz.net/d/european-union.europa.eu/dnssec/

Mark.

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

[Marco Davids (Private) via NANOG]

Hi Laura,

Something seems the matter, indeed:

https://dnsviz.net/d/european-union.europa.eu/YbCzrQ/dnssec/

It's weird; 1.1.1.1 resolves, 8.8.8.8 and 9.9.9.9 return SERVFAIL.

--
Marco


Op 08-12-2021 om 14:27 schreef Laura Smith via NANOG:


Bit of a long stretch given the US audience, but I'm seeing lots of things like 
this at the moment:

info: validation failure : key for validation 
european-union.europa.eu. is marked as invalid because of a previous validation failure 
: DS got unsigned CNAME answer from 
2600:9000:5301:a200::1 and 34.255.155.194 for DS european-union.europa.eu. while building 
chain of trust

info: validation failure : DS got unsigned 
CNAME answer from 2600:9000:5302:9a00::1 and 34.255.155.194 for DS 
european-union.europa.eu. while building chain of trust

validation failure : signatures from unknown keys from 
147.67.12.3

info: validation failure : signatures from unknown keys 
from 147.67.12.3