Default public-resolvers, wrong results (?) and establishing trust

[RuRo]

Can you explain, how is the list of servers in public-resolvers validated? What is the trust model here?

I found this reddit thread discussing trust, but the discussion there revolves around "trusting maintainers" rather than trusting the public DNS servers.

I am asking because I've had multiple incidents where my local dnscrypt-proxy would return obviously (?) bogus IP addresses. For example, currently dig @127.0.0.1 api.github.com returns

; <<>> DiG 9.18.16 <<>> @127.0.0.1 api.github.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16559
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;api.github.com.			IN	A

;; ANSWER SECTION:
api.github.com.		1738	IN	A	20.175.192.149

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Oct 13 21:59:02 MSK 2023
;; MSG SIZE  rcvd: 59

compared to dig @8.8.8.8 api.github.com

; <<>> DiG 9.18.16 <<>> @8.8.8.8 api.github.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44175
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;api.github.com.			IN	A

;; ANSWER SECTION:
api.github.com.		60	IN	A	140.82.121.5

;; Query time: 64 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Oct 13 21:59:10 MSK 2023
;; MSG SIZE  rcvd: 59

The IP address returned by dnscrypt-proxy seems pretty obviously nonsense. As far as I can tell, it's not even in a subnet used by GitHub and there are no reverse DNS records for that IP (unlike the real IP returned by @8.8.8.8).

If I try to connect to this IP anyway, the server tries to use GitHub SSL certificates, but fails because the official GitHub certificates don't match the provided IP:

* Connected to 20.175.192.149 (20.175.192.149) port 443 (#1)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=*.github.com
*  start date: Feb 16 00:00:00 2023 GMT
*  expire date: Mar 15 23:59:59 2024 GMT
*  subjectAltName does not match 20.175.192.149
* SSL: no alternative certificate subject name matches target host name '20.175.192.149'

All this is extremely suspicious. The last two times this was happening, I checked journalctl -u dnscrypt-proxy2.service and both times nextdns-ultralow was selected as the "Server with the lowest initial latency". A sample size of 2 is kind of low and this might be some bug/transient failure rather than malicious activity, but stuff like this makes me extremely uncomfortable with trusting the default public-resolvers list.

On a related note, how are the nolog and nofilter flags for the public servers determined? Are we just trusting the DNS provider's words, or is there some mechanism that allows us to check if any DNS server logs and/or censors its requests?

[lifenjoiner]

1. The public-resolvers is maintained at: https://github.com/DNSCrypt/dnscrypt-resolvers
2. The IP is safe.
   You can retrieve a list of GitHub's IP addresses from the meta API endpoint according "About GitHub's IP addresses - GitHub Docs".
   Try:

   curl --resolve *:443:20.175.192.149 https://api.github.com
   

[RuRo]

Oh, wow. GitHub must just be having a bad week or something. Sorry for the paranoia, dnscrypt is indeed not at fault here.

curl -vv 'https://api.github.com/' --resolve 'api.github.com:443:20.175.192.149'

works like half the time. And the other half it fails with curl: (16) Error in the HTTP2 framing layer.

And I tried running the above command both on my local machine and in the datacenter, so it seems to be a global issue.

Again, sorry for the FUD.