Multiple Public DNS Resolvers' Certificate Hashes Not Found

[sr093906]

In https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v3/public-resolvers.md

DnsCrypt log: [dns.sb] Certificate hash [9a3a34f727deb9bca51003d9ce9c39f8f27dd9c5242901c2bab1a44e635a0219] not found DnsCrypt log: Certificate hash not found DnsCrypt log: [dnsfilter] may be a lying resolver DnsCrypt log: [dnsfilter] Certificate hash [444ebd67bb83f8807b3921e938ac9178b882bd50aadb11231f044cf5f08df7ce] not found DnsCrypt log: Certificate hash not found DnsCrypt log: [quad9-doh-ip4-port443-filter-pri] Certificate hash [2a15f5d6acb6e7c0901ade4ebbc743b2ccd489032b46e1642f0693683001258a] not found DnsCrypt log: Certificate hash not found DnsCrypt log: [quad9-doh-ip4-port443-filter-ecs-pri] Certificate hash [2a15f5d6acb6e7c0901ade4ebbc743b2ccd489032b46e1642f0693683001258a] not found DnsCrypt log: Certificate hash not found DnsCrypt log: [quad9-doh-ip4-port443-nofilter-pri] Certificate hash [2a15f5d6acb6e7c0901ade4ebbc743b2ccd489032b46e1642f0693683001258a] not found DnsCrypt log: Certificate hash not found DnsCrypt log: [quad9-doh-ip4-port443-nofilter-ecs-pri] Certificate hash [2a15f5d6acb6e7c0901ade4ebbc743b2ccd489032b46e1642f0693683001258a] not found DnsCrypt log: Certificate hash not found DnsCrypt log: [rethinkdns-doh] Certificate hash [2aae3fb7bf05e4c81c4194dca44511d4f9af304786ec1ae7218409cf62a08355] not found DnsCrypt log: Certificate hash not found

[CrustyB]

same. I think that quad 9 changed certs a few days ago. I am trying to figure out how to update, but all I can find is minisig stuff.

[jedisct1]

I'll update them shortly. But all the Quad9 resolvers are also accessible over DNSCrypt, which cannot have that kind of issue.

[CrustyB]

Ahh thanks for the tip. I have moved my quad 9 servers to DNSCrypt. I now have 4 separate DNS providers (2 DOH,2 DNSCrypt) working properly. I think this is better for resiliency anyway. Thanks again!

Discussions about this: https://github.com/DNSCrypt/dnscrypt-proxy/discussions/2665 https://github.com/DNSCrypt/dnscrypt-resolvers/issues/941

[TCMBC]

Found a similar issue with quad9 doh stamps a few days ago...

Loaded quad9 cert chain, grabbed PEM format of IntCA used for signing host cert for quad9 ( https://9.9.9.9/dns-query or dns9.quad9.net/ ) , openssl to convert to DER, then openssl asn1parse, to find offset to sequence for what would be the equivalent to a "TBS certificate" for that IntCA, extracted based on asn1parse offset (sequence) to then sha256sum that to get b01920744bbb76c9ab053e01e07b7e050e473d20f79f7bea435fafe43c9d242f

Used https://dnscrypt.info/stamps-specifications/ to see field formatting of base64url content of the stamp for the quad9 DOH is use, then piped the stamp through base64_url decode, then piped through xxd to go from 8-bit to hex stream, and then piped through sed to replace old "TBS Cert" sha256 hash 2a15f5d6acb6e7c0901ade4ebbc743b2ccd489032b46e1642f0693683001258a with b01920744bbb76c9ab053e01e07b7e050e473d20f79f7bea435fafe43c9d242f, then pipe back back to xxd to reverse hex to 8-bit, then piped that through base64_url encode to get me a new stamp with the new cert hash for quad9 DOH. Then saved these as "static" entries under '[static]' in the config file with a"-workaround" suffix for key/label, so I can remove them later.

Kludgy, but seems to work well enough until an official update is provided.

I too assumed that https://github.com/Quad9DNS/dnscrypt-settings/tree/main/dnscrypt might be updated, but nope.

Basic summary of steps provided above for any command-line people that know what they are doing to see what can be done, but I'm not pasting in the resulting quad9 doh stamps; bad idea for people to blindly use stamps without trusting the creator of them, and I am a nobody.

Thanks for you hard work on this project. Good luck!

[wwwrando]

Following @TCMBC I wrote a little go program that outputs the new sdns records given the old sdns records, https://github.com/wwwrando/dohstamp

[wwwrando]

@jedisct1 : I just realized that it is recommended to hash in sdns stamps the certificate that signed the certificate provided by the DNS server rather than directly the certificate provided by the DNS server. Wouldn't it be more secure to hash the latter rather than the former? What is the rationale for the current recommendation? (Is it just to avoid the hassle with constantly changing certificates?)

[jedisct1]

@wwwrando the latter can change very frequently, and can differ between servers and locations.

[jedisct1]

The public resolvers list should be fixed, but not the actual source.

The first thing to do would have been to notify @quad9DNS

[TCMBC]

@jedisct1 : Thanks!

Reverted config to use what were previously working keyed entries to stamps in public-resolvers.md before qud9 change. Once config was restored using new public-resolvers.md, dnscrypt-proxy was restarted and it is working fine. (confirmation it is working.)

My boss notified someone he knew at quad9 I think last Friday.

Since my boss notified someone at quad9, I didn't.

They (quad9) are still lagging: (as of this reply date/time) https://www.quad9.net/quad9-resolvers.md (Citation: this can be found at the bottom of https://www.quad9.net/service/service-addresses-and-features/#dnscrypt in the "dnscrypt" section of that page from quad9) still shows old data https://raw.githubusercontent.com/Quad9DNS/dnscrypt-settings/main/dnscrypt/quad9-resolvers.md still shows old data

Thanks again for your hard work!

[AndLLA]

using the latest configuration as of now, the quad9-doh-ip4-port443-filter- are working, the quad9-doh-ip4-port5053-filter- are not working

server_names = [ 'quad9-doh-ip4-port443-filter-pri', 'quad9-doh-ip4-port443-filter-alt','quad9-doh-ip4-port443-filter-alt2', 'quad9-doh-ip4-port5053-filter-pri', 'quad9-doh-ip4-port5053-filter-alt', 'quad9-doh-ip4-port5053-filter-alt2' ]

[2024-08-07 11:21:53] [NOTICE] Advertised cert: [CN=dns.quad9.net,O=Quad9,L=Zurich,ST=Zurich,C=CH] [e3e13daef1fd3012db80b3b002b5d2a7f24a7c8bb82b318694bdcaf061d1ba02] [2024-08-07 11:21:53] [NOTICE] Advertised cert: [CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1,O=DigiCert Inc,C=US] [b01920744bbb76c9ab053e01e07b7e050e473d20f79f7bea435fafe43c9d242f] [2024-08-07 11:21:53] [CRITICAL] [quad9-doh-ip4-port5053-filter-pri] Certificate hash [2a15f5d6acb6e7c0901ade4ebbc743b2ccd489032b46e1642f0693683001258a] not found [2024-08-07 11:21:53] [NOTICE] Advertised cert: [CN=dns.quad9.net,O=Quad9,L=Zurich,ST=Zurich,C=CH] [e3e13daef1fd3012db80b3b002b5d2a7f24a7c8bb82b318694bdcaf061d1ba02] [2024-08-07 11:21:53] [NOTICE] Advertised cert: [CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1,O=DigiCert Inc,C=US] [b01920744bbb76c9ab053e01e07b7e050e473d20f79f7bea435fafe43c9d242f] [2024-08-07 11:21:53] [NOTICE] [quad9-doh-ip4-port443-filter-pri] OK (DoH) - rtt: 23ms

the new configuration file from quad9 is not usable, because of a Incompatible signature algorithm in the minisign key ?

[2024-08-07 11:09:33] [NOTICE] dnscrypt-proxy 2.1.5 [2024-08-07 11:09:33] [NOTICE] Service is not usable yet [2024-08-07 11:09:33] [NOTICE] Resolving server host [quad9.net] using bootstrap resolvers over udp [2024-08-07 11:09:34] [NOTICE] Service is not usable yet [2024-08-07 11:09:34] [NOTICE] Resolving server host [raw.githubusercontent.com] using bootstrap resolvers over udp [2024-08-07 11:09:34] [CRITICAL] Unable to retrieve source [quad9-resolvers]: [Incompatible signature algorithm] [2024-08-07 11:09:34] [FATAL] Incompatible signature algorithm

[sources.quad9-resolvers] urls = ['https://quad9.net/dnscrypt/quad9-resolvers.md', 'https://raw.githubusercontent.com/Quad9DNS/dnscrypt-settings/main/dnscrypt/quad9-resolvers.md'] minisign_key = 'RWTp2E4t64BrL651lEiDLNon+DqzPG4jhZ97pfdNkcq1VDdocLKvl5FW' cache_file = '/var/cache/dnscrypt-proxy/quad9-resolvers.md' refresh_delay = 72 prefix = 'quad9-'