There is a DNSSEC Chain issue for some subdomains: rsync.gentoo.org http://dnsviz.net/d/rsync.gentoo.org/dnssec/ dev.gentoo.org http://dnsviz.net/d/dev.gentoo.org/dnssec/ distfiles.gentoo.org http://dnsviz.net/d/distfiles.gentoo.org/dnssec/ Maybe other subdomains have the same issue. Reproducible: Always Steps to Reproduce: 1. Resolve one of the Subdomains behind a DNSSEC validating resolver. Actual Results: ** server can't find rsync.gentoo.org: SERVFAIL Expected Results: Name: rsync.gentoo.org Address: 81.91.253.252 ...
Also anongit.
Can confirm this behavior. > Maybe other subdomains have the same issue. Also impacted keys.gentoo.org which, if you weren't already deadlocked by the DNS resolution failure on distfiles.gentoo.org/rsync.gentoo.org, cause webrsync to fail while trying to refresh the keys. > There is a DNSSEC Chain issue for some subdomains: > > rsync.gentoo.org > http://dnsviz.net/d/rsync.gentoo.org/dnssec/ Currently, Google and Cloudflare public DNSes fail to resolve because of a signature mismatch. A key rollout gone wrong ? The valid DNSKEY (37372) with the corresponding Delegation Signature record (DS) is not used to sign child records like SOA, A, AAAA ..etc The key used to sign actual records has the ID 50775 wich has no corresponding DS in the gentoo.org zone. Workaround for webrsync: Had to manually set sync-uri in my repos with an IP address (obtained via querying ns1.gentoo.org without DNSSEC) and nullify sync-openpgp-keyserver to synchronize my tree on my local mirror. Regards,
Sometimes I really do wonder why do we even bother trying to improve security if users at the first signs of failure don't even bother waiting a few hours and immediately workaround all the security measures. So we have security measure in place to prevent ::gentoo from being compromised. However, it's sufficient to attack DNS and people go out of their way to disable all security measures.
(In reply to Michał Górny from comment #3) > Sometimes I really do wonder why do we even bother trying to improve > security if users at the first signs of failure don't even bother waiting a > few hours and immediately workaround all the security measures. > > So we have security measure in place to prevent ::gentoo from being > compromised. However, it's sufficient to attack DNS and people go out of > their way to disable all security measures. While this is a valid point, I fail to grasp the security implications of my workaround. Nullifying sync-openpgp-keyserver only suspend the PGP keys synchronization, the validation still take place using the "last known" public key. I could also use another -slow and potentially vulnerable- key server to get them. WKD is also working as intended. As for the sync-uri workaround, I suggested querying the DNS server directly to obtain a valid but DNSSEC-free response. If the DNS Server is sending forged queries, we have a much more serious problem at hand. Rgds,
gitweb.g.o also seems affected for me
The problem should be fixed now.
Not sure if this belongs here or in a new bug report. dnssec validation isn't working for me for attachments on this bug tracker. Example: https://713530.bugs.gentoo.org/attachment.cgi?id=623928 does not resolve for me with dnssec enabled. > resolvectl query 713530.bugs.gentoo.org 713530.bugs.gentoo.org: resolve call failed: DNSSEC validation failed: invalid The standard domains, like bugs.gentoo.org or rsync.gentoo.org, seem all to work fine for me. I am using cloudflares dns server(1.1.1.1) through systemd-resolved if that makes any difference.
(In reply to Christian Stoitner from comment #7) > Not sure if this belongs here or in a new bug report. dnssec validation > isn't working for me for attachments on this bug tracker. Example: > https://713530.bugs.gentoo.org/attachment.cgi?id=623928 does not resolve for > me with dnssec enabled. > > > resolvectl query 713530.bugs.gentoo.org > 713530.bugs.gentoo.org: resolve call failed: DNSSEC validation failed: > invalid > > The standard domains, like bugs.gentoo.org or rsync.gentoo.org, seem all to > work fine for me. > > I am using cloudflares dns server(1.1.1.1) through systemd-resolved if that > makes any difference. This bug is definitely not related to your issue. Please file a new bug, after testing with non-systemd and non-CloudFlare resolver. https://dnssec-analyzer.verisignlabs.com/713530.bugs.gentoo.org Claims that the DNSSEC on Gentoo's records are good.
