As part of our anti-SOPA DNS move off GoDaddy, we decided to switch our Domain Name System (DNS) servers to CloudFlare, so that we could eventually use their Content Distribution Network (CDN) to distribute our script. This is an infrastructural upgrade that would speed up the delivery of our service.
Our move was successful, in that we made certain a full recursive DNS traversal from the root could resolve our domain.
However, we realized that a very small percentage of DNS lookups were failing, which resulted in our widget not loading and browsers showing “Domain not found” errors when loading our site.
Using Google’s public DNS service, we encountered this issue 4 times, each time lasting 5 minutes (this was our DNS TTL).
We immediately set up 4 monitoring checks, each of which looked up (from 20 locations around the world) the following:
- cdn.zopim.com via 184.108.40.206 (Google’s public DNS service)
- cdn.zopim.com via 220.127.116.11
- cdn.zopim.com via emma.ns.cloudflare.com (our new nameservers)
- cdn.zopim.com via lee.ns.cloudflare.com
This was done at 1 minute intervals, but failed to show any problems. Full traversals from the root continued to show no issues.
In the end, it turned out that CloudFlare’s DNS servers were returning an error *together* with the correct DNS record. We quickly suspected our wildcard DNS entry (essentially using *.something notation) and removed it, which fixed this intermittent but extremely annoying issue.
While CloudFlare did blog that they do not proxy wildcard domains (i.e. for their CDN service), there was no mention that proxy wildcard domains would return ambiguous results using their DNS service. We have reached out to Cloudflare to confirm this behavior. At this point, they are still verifying if this is indeed true. In the meantime, hopefully this page would turn out useful for other CloudFlare users.