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 1.1.1.1 — the Internet’s Fastest, Privacy-First DNS Resolver
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 kdig – Advanced DNS lookup utility — Knot DNS 2.6.9 documentation) 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 1.1.1.1@853(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: http://dnsprivacy.org/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]