Unable to resolve Nasa domains

Hi, I’m seeing SERVFAIL with domain epic.gsfc.nasa.gov

> dig epic.gsfc.nasa.gov @

; <<>> DiG 9.10.6 <<>> epic.gsfc.nasa.gov @
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60399
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1452
;epic.gsfc.nasa.gov.		IN	A

epic.gsfc.nasa.gov.	300	IN	CNAME	dscovr.gsfc.nasa.gov.
dscovr.gsfc.nasa.gov.	300	IN	A

;; Query time: 1170 msec
;; WHEN: Sun Aug 26 13:24:13 BST 2018
;; MSG SIZE  rcvd: 84

Also ping:

> ping epic.gsfc.nasa.gov
ping: cannot resolve epic.gsfc.nasa.gov: Unknown host

I’m also having problems with other Nasa domains that serve map image tiles:

> ping map1a.vis.earthdata.nasa.gov
ping: cannot resolve map1a.vis.earthdata.nasa.gov: Unknown host

Is this local to my network or is this a Cloudflare DNS issue? Using Google DNS resolves the domains.

1 Like

I use and those hosts resolve. But give this a try and post back what you find:

The responses certainly contain an answer to the query, but take note that the rcode is SERVFAIL.

I get same result as OP from 3 different Cloudflare POPs, doesn’t appear to be an isolated problem, and this thread appears to be the exact same issue with a different domain.

Something something validator mishandling a CNAME in an insecure zone that’s the child of a secure parent zone using the same nameservers? It’s a somewhat obscure and complicated setup, and appears to apply to these NASA and VMware domains.

vmware.com.            (secure)    85654  NS  a1.verisigndns.com.
vmware.com.            (secure)    85654  NS  a2.verisigndns.com.
vmware.com.            (secure)    85654  NS  a3.verisigndns.com.
vmware.com.            (secure)    85654  NS  ns1.p14.dynect.net.
vmware.com.            (secure)    85654  NS  ns2.p14.dynect.net.
vmware.com.            (secure)    85654  NS  ns3.p14.dynect.net.
vmware.com.            (secure)    85654  NS  ns4.p14.dynect.net.
cdnswitch.vmware.com.  (insecure)  85889  NS  a1.verisigndns.com.
cdnswitch.vmware.com.  (insecure)  85889  NS  a2.verisigndns.com.
cdnswitch.vmware.com.  (insecure)  85889  NS  a3.verisigndns.com.
cdnswitch.vmware.com.  (insecure)  85889  NS  ns1.p14.dynect.net.
cdnswitch.vmware.com.  (insecure)  85889  NS  ns2.p14.dynect.net.
cdnswitch.vmware.com.  (insecure)  85889  NS  ns3.p14.dynect.net.
cdnswitch.vmware.com.  (insecure)  85889  NS  ns4.p14.dynect.net.

nasa.gov.              (secure)    74     NS  ns1.nasa.gov.
nasa.gov.              (secure)    74     NS  ns2.nasa.gov.
nasa.gov.              (secure)    74     NS  ns3.nasa.gov.
earthdata.nasa.gov.    (insecure)  300    NS  ns1.nasa.gov.
earthdata.nasa.gov.    (insecure)  300    NS  ns2.nasa.gov.
earthdata.nasa.gov.    (insecure)  300    NS  ns3.nasa.gov.
gsfc.nasa.gov.         (insecure)  300    NS  ns1.nasa.gov.
gsfc.nasa.gov.         (insecure)  300    NS  ns2.nasa.gov.
gsfc.nasa.gov.         (insecure)  300    NS  ns3.nasa.gov. can actually resolve the ultimate targets of the CNAMEs – dscovr.gsfc.nasa.gov., map1.vis.earthdata.nasa.gov., khmrp.x.incapdns.net. and 5alxq.x.incapdns.net..

If that’s right, the reason it returns SERVFAIL with record sets is a different issue where it doesn’t strip record sets from bogus responses.


I’m noticing the same issue @neave describes. I think @mnordhoff is onto the core issue. Here’s another example:

$ dig @ gibs-a.earthdata.nasa.gov.

; <<>> DiG 9.11.4-4-Debian <<>> @ gibs-a.earthdata.nasa.gov.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23731
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1452
;gibs-a.earthdata.nasa.gov.	IN	A

gibs-a.earthdata.nasa.gov. 300	IN	CNAME	gibs.earthdata.nasa.gov.
gibs.earthdata.nasa.gov. 300	IN	A

;; Query time: 171 msec
;; WHEN: Mon Aug 27 19:29:50 EDT 2018
;; MSG SIZE  rcvd: 89 yields the same failure (SERVFAIL). returns NOERROR.

nasa.gov has DNSSEC configured, while earthdata.nasa.gov does not.

I have no reason to believe this is localized, but I’m looking at the IAD instances:

$ dig +short CHAOS TXT id.server @
$ dig +short CHAOS TXT id.server @

In effect, this leads this beautiful website to render a black map canvas. :cry:

I think this might be the same issue as Getting SERVFAIL for some subdomains of vmware.com, I’ll investigate. I’ve added a workaround for earthdata.nasa.gov and gsfc.nasa.gov, so it should start resolving momentarily.

Thanks but this still is not working for me. I’m still seeing SERVFAIL for epic.gsfc.nasa.gov and earthdata.nasa.gov using

Thanks for your patience. We’ve just finished rolling out the fix and I removed the workarounds, let me know if you’re still seeing problems.


Thanks, this seems to have fixed it!

1 Like

Ditto, looks good. Thanks!