DNS problem: SERVFAIL looking up A for obesity-protocol.com

flattery · February 17, 2017, 10:24pm

Please fill out the fields below so we can help you better.

My domain is: obesity-protocol.com

I ran this command: certbot-auto --apache -d obesity-protocol.com

It produced this output: DNS problem: SERVFAIL looking up A for obesity-protocol.com

My operating system is (include version): Debian 8

My web server is (include version): Apache2

My hosting provider, if applicable, is: my own server

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):no

I have tried auto and manual. Checked my DNS lookup from several sites and the all resolve correctly, but I get this DNS record.

A month ago I had this on SiteGround and used the CPanel and it wouldn’t work there either. Every other domain on my server has worked so it seems like Let’s Encrypt DNS doesn’t like the domain name or something.

jsha · February 17, 2017, 10:35pm

When I try to load this in my browser I also get a DNS failure. It seems like there is probably a problem with your DNS setup.

Osiris · February 17, 2017, 10:36pm

First: you might want to consider adding "www.obesity-protocol.com" to the list of domains

Secondly:

Well, from here it doesn't, actually:

osiris@desktop ~ $ dig +dnssec +trace obesity-protocol.com

; <<>> DiG 9.10.3-P4 <<>> +dnssec +trace obesity-protocol.com
;; global options: +cmd
(...) root servers (...)
;; Received 525 bytes from 194.109.6.66#53(194.109.6.66) in 15 ms

(...) bunch of root servers for the .com TLD with their DNSSEC records (...)
;; Received 872 bytes from 192.33.4.12#53(c.root-servers.net) in 15 ms

obesity-protocol.com.	172800	IN	NS	ns1.starhostdesign.net.
obesity-protocol.com.	172800	IN	NS	ns2.starhostdesign.net.
(...) removed some NSEC3 DNSSEC records (...)
;; Received 620 bytes from 192.54.112.30#53(h.gtld-servers.net) in 9 ms

;; Received 38 bytes from 216.69.185.52#53(ns2.starhostdesign.net) in 9 ms

osiris@desktop ~ $ dig +dnssec @ns2.starhostdesign.net obesity-protocol.com

; <<>> DiG 9.10.3-P4 <<>> +dnssec @ns2.starhostdesign.net obesity-protocol.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 24147
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;obesity-protocol.com.		IN	A

;; Query time: 11 msec
;; SERVER: 216.69.185.52#53(216.69.185.52)
;; WHEN: Fri Feb 17 23:34:47 CET 2017
;; MSG SIZE  rcvd: 38

osiris@desktop ~ $

Same goes for ns1.starhostdesign.net.

Two things: it says "REFUSED" as status and it gives a warning about the fact recursion is not available.

I'm guessing the problem lies at your DNS, perhaps your DNS service provider or something else.

mnordhoff · February 17, 2017, 10:39pm

The domain’s DNS looks iffy to me. I’m not sure what exactly is wrong, but things are way off.

When i do queries, they usually SERVFAIL a few times and eventually work.

http://dnsviz.net/d/obesity-protocol.com/dnssec/

The delegation from the com./net. nameservers is this:

$ digr obesity-protocol.com. @b.gtld-servers.net

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse obesity-protocol.com. @b.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23968
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;obesity-protocol.com.          IN      A

;; AUTHORITY SECTION:
obesity-protocol.com.   172800  IN      NS      ns1.starhostdesign.net.
obesity-protocol.com.   172800  IN      NS      ns2.starhostdesign.net.

;; ADDITIONAL SECTION:
ns1.starhostdesign.net. 172800  IN      A       108.178.34.214
ns2.starhostdesign.net. 172800  IN      A       181.224.144.9

;; Query time: 0 msec
;; SERVER: 2001:503:231d::2:30#53(2001:503:231d::2:30)
;; WHEN: Fri Feb 17 22:30:13 UTC 2017
;; MSG SIZE  rcvd: 135

According to the NS records in your own zone, the nameservers are these:

$ dig obesity-protocol.com. ns

; <<>> DiG 9.10.3-P4-Ubuntu <<>> obesity-protocol.com. ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51240
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;obesity-protocol.com.          IN      NS

;; ANSWER SECTION:
obesity-protocol.com.   86399   IN      NS      ns2.m36.siteground.biz.
obesity-protocol.com.   86399   IN      NS      ns1.m36.siteground.biz.

;; Query time: 408 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Feb 17 22:30:17 UTC 2017
;; MSG SIZE  rcvd: 103

$ mhost ns1.m36.siteground.biz.
ns1.m36.siteground.biz.  (unsigned)  7501  A  108.178.34.214
$ mhost ns2.m36.siteground.biz.
ns2.m36.siteground.biz.  (unsigned)  14400  A  181.224.144.9

Notice that the IP addresses are the same, but the hostnames are different.

Finally, according to its own zone, the nameserver names i mentioned first have completely different A records from the com. glue aliasing SiteGround:

$ mhost ns1.starhostdesign.net.
ns1.starhostdesign.net.  (unsigned)  3600  A  216.69.185.52
$ mhost ns2.starhostdesign.net.
ns2.starhostdesign.net.  (unsigned)  3599  A  216.69.185.52

And that server does not respond to queries:

$ digr obesity-protocol.com. @216.69.185.52

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse obesity-protocol.com. @216.69.185.52
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9098
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;obesity-protocol.com.          IN      A

;; Query time: 34 msec
;; SERVER: 216.69.185.52#53(216.69.185.52)
;; WHEN: Fri Feb 17 22:37:11 UTC 2017
;; MSG SIZE  rcvd: 38

So whether it “works” depends on the details of a specific recursive server’s lookup algorithm, what the order of events is, and precisely how and what it caches.

The reason it works for me after a few retries is that i actually use multiple recursive DNS servers with two different implementations; apparently, one of them happens to accept these issues, and one of them doesn’t.

Anyway, this all needs to be sorted out for your DNS to work reliably.

Osiris · February 17, 2017, 10:47pm

Could be from a cache? If you look at the TTL, it's pretty long. Who knows what the starting TTL was..

Because if you use +trace every time, those siteground.biz servers never show up.

mnordhoff · February 17, 2017, 10:55pm

No, those are the live DNS records in the zone itself, according to its working nameservers.

$ digr obesity-protocol.com. @108.178.34.214

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse obesity-protocol.com. @108.178.34.214
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65143
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;obesity-protocol.com.          IN      A

;; ANSWER SECTION:
obesity-protocol.com.   5000    IN      A       185.101.98.140

;; AUTHORITY SECTION:
obesity-protocol.com.   86400   IN      NS      ns1.m36.siteground.biz.
obesity-protocol.com.   86400   IN      NS      ns2.m36.siteground.biz.

;; ADDITIONAL SECTION:
ns1.m36.siteground.biz. 14400   IN      A       108.178.34.214
ns2.m36.siteground.biz. 14400   IN      A       181.224.144.9

;; Query time: 30 msec
;; SERVER: 108.178.34.214#53(108.178.34.214)
;; WHEN: Fri Feb 17 22:50:09 UTC 2017
;; MSG SIZE  rcvd: 151

dig +trace follows the NS records from the parent delegations, without separately looking them up in the child zones, while using your system's resolver (probably via an ordinary getaddrinfo() call, but i haven't checked) to look up the IP addresses of each nameserver involved, which may itself use any arbitrary algorithm.

That's exactly the recipe to fail with this misconfigured zone.

flattery · February 17, 2017, 11:05pm

Thanks guys. Cache must have been hanging things up… that and I found a few conflicts in the DNS server.

All my NSlookups were looking good. I made some adjustments to that and now it all works.

Thanks for your help. I just needed another perspective.

flattery · February 17, 2017, 11:08pm

And I should add, mnordhoff was right on the mark with the issue.

system · March 19, 2017, 11:09pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.