-2

somewhat similar to this thread, I faced with a problem where dig blah.net (for the sake of simplicity let's call it blah.net) returns status: SERVFAIL

This DNS zone is hosted on route53, and I use GoDaddy as registrar - which points to NS records of the hosted zone on route53

this is a pretty simple zone which consists of a CNAME and an A Record, and the default values for SOA and NS records for route53 hosted zone(only TTL has been updated/reduced)

The problem is dig blah.net causes status: SERVFAIL while pointing at a nameserver resoloves fine (e.g. dig @ns-#.awsdns-##.net. blah.net works fine with status: NOERROR )

It also shows the records/resolves fine (no errors) if I use dig blah.net +trace

I've waited for more than 48hrs to make sure GoDaddy propagated the changes, and double/triple checked GoDaddy points to blah.net NS records

I don't see anything weird on /etc/resolve.conf on my machine (but not an expert!), and fwiw it also fails on google's nameserver (@8.8.8.8)

Is it possible that something went wrong from GoDaddy's side? Any suggestion/comment on how to debug this further is really appreciated

[Edit] fix: typo in dns name

Mahyar
  • 107
  • 3
  • Why are you sometimes writing `blah.net` and sometimes `balh.net`? It is too confusing to follow. Anyway, show the records as they appear at route 53 (IP redacted). – tater Aug 04 '20 at 04:27
  • "for the sake of simplicity let's call it blah.net)" No. If you want good replies give the real name as it is public anyway. But if you obfuscate at least do it properly, and use `example.com` or `example.net`. – Patrick Mevzek Sep 05 '20 at 21:55

1 Answers1

0

The problem is dig blah.net causes status: SERVFAIL while pointing at a nameserver resoloves fine (e.g. dig @ns-#.awsdns-##.net. blah.net works fine with status: NOERROR )

This indicates that whatever DNS server you're using on the host running dig is misconfigured, has corrupt cache, or is (to use a technical term) jacked up.

It also shows the records/resolves fine (no errors) if I use dig blah.net +trace

This further supports the above notion, because dig +trace does not use the host's DNS settings for checking DNS, but rather goes straight to root hints.

Not resolving correctly at @8.8.8.8 doesn't precisely rule out your local DNS environment.

And of course, no one can be of any true help to you until you provide the actual domain name in question here.

Wesley
  • 32,320
  • 9
  • 80
  • 116