Hello, I have a problem with DNS over TLS that I can't debug.
If I'm using 9.9.9.11 server from Quad9, I receive this output from dig, on Mac and on Linux:
└─$ dig cnn.com
; <<>> DiG 9.16.13-Debian <<>> cnn.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 37374
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 12882241105594ad (echoed)
;; QUESTION SECTION:
;cnn.com. IN A
;; Query time: 1040 msec
;; SERVER: 10.88.0.2#53(10.88.0.2)
;; WHEN: gio apr 22 11:46:21 CEST 2021
;; MSG SIZE rcvd: 48
host and nslookup work fine. Operating systems can resolve names (web browsers work), at least I tried a Mac and Linux with regular /etc/resolv.conf. However a Linux server with systemd-resolved can't resolve names when the upstream on the router is 9.9.9.11.
If I change to 9.9.9.9 everything works fine.
DoH works fine even for 9.9.9.11.
I tried a packet capture and it seems that queries don't go to the internet, it's the router that responds REFUSED to the local clients.
Truncated output from "show dns-proxy":
...
proxy-tls:
server-tls:
address: 9.9.9.11
port:
sni: dns11.quad9.net
spki:
interface:
server-tls:
address: 149.112.112.11
port:
sni: dns11.quad9.net
spki:
interface:
...
Is this a bug? Why is it not working properly for just these two servers? I'd like to use these and not the regular Quad9 because they have EDNS Client Subnet.