Anyone else seeing DNSSEC failures from EU Commission ? (european-union.europa.eu)
Bit of a long stretch given the US audience, but I'm seeing lots of things like this at the moment: info: validation failure <european-union.europa.eu. AAAA IN>: key for validation european-union.europa.eu. is marked as invalid because of a previous validation failure <european-union.europa.eu. AAAA IN>: 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 <european-union.europa.eu. AAAA IN>: 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 <europa.eu. A IN>: signatures from unknown keys from 147.67.12.3 info: validation failure <europa.eu. AAAA IN>: signatures from unknown keys from 147.67.12.3
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 <european-union.europa.eu. AAAA IN>: key for validation european-union.europa.eu. is marked as invalid because of a previous validation failure <european-union.europa.eu. AAAA IN>: 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 <european-union.europa.eu. AAAA IN>: 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 <europa.eu. A IN>: signatures from unknown keys from 147.67.12.3
info: validation failure <europa.eu. AAAA IN>: signatures from unknown keys from 147.67.12.3
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
* 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. 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.
On Wed, Dec 8, 2021 at 6:35 AM Niels Bakker <niels=nanog@bakker.net> wrote:
* 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.
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.
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
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.
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
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
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
What is a ddos death spiral? Jean From: NANOG <nanog-bounces+jean=ddostest.me@nanog.org> On Behalf Of Ca By Sent: December 9, 2021 9:36 AM To: Arne Jensen <darkdevil@darkdevil.dk> 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
On Thu, Dec 9, 2021 at 7:15 AM Jean St-Laurent <jean@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-d... 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 <nanog-bounces+jean=ddostest.me@nanog.org> *On Behalf Of *Ca By *Sent:* December 9, 2021 9:36 AM *To:* Arne Jensen <darkdevil@darkdevil.dk> *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
I understand now and I agree with you that there’s something fishy there. Fear sells. Thanks Jean From: Ca By <cb.list6@gmail.com> Sent: December 9, 2021 10:47 AM To: Jean St-Laurent <jean@ddostest.me> Cc: Arne Jensen <darkdevil@darkdevil.dk>; 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 <jean@ddostest.me <mailto:jean@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-d... 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
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
On 10 Dec 2021, at 01:36, 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.
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...
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@isc.org
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
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
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 AAAA european-union.europa.eu @1.1.1.1
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> +dnssec AAAA 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 AAAA
;; ANSWER SECTION: european-union.europa.eu. 1800 IN CNAME d1d395kgk3q1uk.cloudfront.net. d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:ea00:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:8200:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:4c00:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:1c00:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:e600:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:3a00:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:f600:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 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 AAAA european-union.europa.eu @1.1.1.1
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> +dnssec AAAA 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 AAAA
;; 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 AAAA 2600:9000:2021:d400:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:c800:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:9200:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:d200:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:c200:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:be00:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:b800:13:6ecf:b700:93a1 d1d395kgk3q1uk.cloudfront.net. 60 IN AAAA 2600:9000:2021:600:13:6ecf:b700:93a1
;; Query time: 48 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Thu Dec 09 09:34:59 CET 2021 ;; MSG SIZE rcvd: 617
$
And now, CloudFlare should indeed follow the CNAME, as the RRSIG for european-union.europa.eu is there. -- Med venlig hilsen / Kind regards, Arne Jensen
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
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 <european-union.europa.eu. AAAA IN>: key for validation european-union.europa.eu. is marked as invalid because of a previous validation failure <european-union.europa.eu. AAAA IN>: 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 <european-union.europa.eu. AAAA IN>: 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 <europa.eu. A IN>: signatures from unknown keys from 147.67.12.3
info: validation failure <europa.eu. AAAA IN>: 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.
On Wed, Dec 08, 2021 at 01:27:23PM +0000, 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
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 <bortzmeyer@nic.fr> wrote:
On Wed, Dec 08, 2021 at 01:27:23PM +0000,
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
participants (12)
-
Arne Jensen -
Ca By -
Francis Booth -
Jean St-Laurent -
Laura Smith -
Marco Davids (Private) -
Mark Andrews -
Mark Tinka -
Masataka Ohta -
Nick Hilliard -
Niels Bakker -
Stephane Bortzmeyer