0

The website that I launched along my new app has been reported down from romania, but it works fine from my end. I tried to access it from a public dns server from there (5.254.96.195), but nslookup returns a SERVFAIL.

The domain is beacon.sh.

Here is the output of dig @5.254.96.195 beacon.sh:

; <<>> DiG 9.12.0 <<>> @5.254.96.195 beacon.sh
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1494
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;beacon.sh.         IN  A

;; Query time: 1573 msec
;; SERVER: 5.254.96.195#53(5.254.96.195)
;; WHEN: Wed Feb 28 10:51:08 CET 2018
;; MSG SIZE  rcvd: 27

I use digital ocean and namecheap, I would greatly appreciate it if someone would help me.

Vivere Discere
  • 23
  • 1

1 Answers1

4

I don't get a similar failure:

[me@risby personal]$ dig @5.254.96.195 beacon.sh
[...]
;; ANSWER SECTION:
beacon.sh.              3135    IN      A       138.68.190.199

I don't understand why you're querying that server (5.254.96.195), but any issues you are having with it are between you, your hosting provider, and them. There are many things it could be: transparent DNS proxying going wrong, transparent proxying going right (depending on how it's configured), temporary BGP flap, dodgy firewalls en route, and so on. Only with the assistance of your hosting provider and the provider of the DNS server can you hope to work it out. I would say your best plan was to use the DNS servers that digital ocean and namecheap recommend that you use with their offerings; at least you'll have some kind of contractual basis to expect an issue to be investigated. Otherwise, I doubt this is resolvable.

If you're querying that server because you're trying to work out why this remote user can't get to your site, and it's the remote user's DNS server, then answering the bigger question is similarly-problematic. When some end-user complains they can't reach your website, and you're confident your server is up and serving, then the person best placed to diagnose that is the IT person at the remote user's site. As you have discovered, trying to remotely diagnose their connectivity problems introduces huge numbers of possible additional issues to muddy the water, at least one of which is clearly biting you.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • 1
    It is the remote user dns server, and I can't replicate now either. I'll keep that in mind, sorry for that question, I'm still new here. Thanks for the detailed answer! – Vivere Discere Feb 28 '18 at 11:09
  • @VivescereDiscere don't worry about it, for a first question it was pretty good. You didn't attempt to obfuscate or conceal any of the data involved, which made it a quick question to answer, you bothered to format it correctly, and hopefully you got both useful-short-term and useful-long-term data out of it! – MadHatter Feb 28 '18 at 11:14