Cdn.jsdelivr.net fails to resolve using DNS over TLS

This is quite an odd one as the DNS is hosted by Cloudflare so having your own resolver fail to resolve it is very unusual. It works fine over plain DNS.

Hm no problem on my end


Might be a single server. To check what data enter you are hitting: https://www.cloudflare.com/cdn-cgi/tracepoof

Edit: Cloudflare has a new tool: try https://cloudflare-dns.com/help/

And follow the instructions here: Have problems with 1.1.1.1? *Read Me First*

Is that using DNS over TLS though? It resolves fine over plain DNS, it just fails using DNS over TLS.

It makes testing near on impossible as only Unbound can do DNS over TLS, no command line utilities that I’m aware of do.

fl=63f21
h=www.cloudflare.com
ip=82.69.xx.xx
ts=1538131653.843
visit_scheme=https
uag=Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
colo=MAN
spdy=h2
http=h2
loc=GB
tls=TLSv1.3
sni=plaintext

Yea sorry, that was DNS over UDP but I used kdig (from Knot DNS https://www.knot-dns.cz/docs/2.6/html/man_kdig.html) and tried again:

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  cdn.jsdelivr.net

;; DEBUG: Querying for owner(cdn.jsdelivr.net.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 169 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=CA,L=San Francisco,O=Cloudflare\, Inc.,CN=*.cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 7832
;; Flags: qr rd ra; QUERY: 1; ANSWER: 6; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1452 B; ext-rcode: NOERROR
;; PADDING: 293 B

;; QUESTION SECTION:
;; cdn.jsdelivr.net.   		IN	A

;; ANSWER SECTION:
cdn.jsdelivr.net.   	53	IN	CNAME	cdn.jsdelivr.net.cdn.cloudflare.net.
cdn.jsdelivr.net.cdn.cloudflare.net. 143	IN	A	104.16.87.20
cdn.jsdelivr.net.cdn.cloudflare.net. 143	IN	A	104.16.88.20
cdn.jsdelivr.net.cdn.cloudflare.net. 143	IN	A	104.16.89.20
cdn.jsdelivr.net.cdn.cloudflare.net. 143	IN	A	104.16.85.20
cdn.jsdelivr.net.cdn.cloudflare.net. 143	IN	A	104.16.86.20

;; Received 468 B
;; Time 2018-09-30 14:42:08 AEST
;; From [email protected](TCP) in 58.7 ms

Thanks for the additional info maybe Cloudflare @staff can look at this. Is it possible that unbound is incorrectly configured somehow?

P.s. DNSPrivacy has a list of DNS-over-TLS (dot) clients: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients.

There is at least one other person to confirm this issue and Netgate sure do not think its a config issue, plus adding Cloud9 as a backup resolves the issue as their DNS over TLS servers resolve it fine.

Sorry for replying so late but can you try again?

It looks like there was a dnssec issue on that domain 4 days ago[1] but is now fixed[2]

[1] http://dnsviz.net/d/cdn.jsdelivr.net/W7IOvQ/dnssec/

[2] http://dnsviz.net/d/cdn.jsdelivr.net/W7fCOQ/dnssec/

It makes testing near on impossible as only Unbound can do DNS over TLS, no command line utilities that I’m aware of do.

getdns_query, pydig, kdig.