Public DNS occasionally fails to resolve specific site

Zero Trust 1.1.1.1
1

Cloudflare’s public DNS resolver occasionally fails to resolve only wolframalpha.com while Google’s public DNS resolver can resolve it just fine. This is tested with both IPv6, IPv4, and with DNS-Over-HTTPS on and off. I have not encountered another domain name that 1.1.1.1 fails to resolve.

nslookup result:
C:\Users\Testificate>nslookup wolframalpha.com 8.8.8.8
Server: dns.google
Address: 8.8.8.8

Non-authoritative answer:
Name:    wolframalpha.com
Address:  140.177.204.192


C:\Users\Testificate>nslookup wolframalpha.com 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

*** one.one.one.one can't find wolframalpha.com: Server failed

tracert 1.1.1.1 result:
Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops:

  1     5 ms     5 ms     5 ms  192.168.1.254
  2     8 ms     6 ms     7 ms  d64-180-196-1.bchsia.telus.net [64.180.196.1]
  3     8 ms     6 ms     7 ms  154.11.10.159
  4     7 ms    44 ms     8 ms  as13335.vanix.ca [206.41.104.52]
  5     9 ms     9 ms     7 ms  one.one.one.one [1.1.1.1]

Trace complete.
2

I just noticed the same when I try to access wolframalpha, occasionally it works but mostly not today. If I connect via vpn or such that uses a different dns it works fine.

3

Hi, seems like there’s an issue with wolframalpha.com DNS infrastructure, as it sometimes returns an empty answer:

;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 37929
;; Flags: qr ra  QUERY: 1; ANSWER: 0; AUTHORITY: 2; ADDITIONAL: 3

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: Unused

;; QUESTION SECTION
wolframalpha.com.		A

;; AUTHORITY SECTION
wolframalpha.com.   	5333	NS	wri-dns0.wolfram.com.
wolframalpha.com.   	5333	NS	wri-dns1.wolfram.com.

;; ADDITIONAL SECTION
wri-dns1.wolfram.com.	6602	A	140.177.203.1
wri-dns0.wolfram.com.	5475	A	140.177.205.10

It is more noticeable since the responses are cached for the whole PoP. I’ll try to contact wolframalpha to see if this can be fixed.

4

This should be now resolved (also confirmed from our side).