Detail: DNS problem: SERVFAIL looking up A for domain.tld


#1

Hello,

I am hosting my nginx server @ scaleway.com and I have a internal and external IP address. The external IP address is correct edited with an A record and is responding. Ports 80 and 443 are open with firewalld. What I am doing wrong and how I can fix this?

Please help me.

Attached you find the error:

Type: connection
Detail: DNS problem: SERVFAIL looking up A for domain.tld.

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.

Thanks in advance.

dex1983


#2

Hi @dex1983,

Does it literally say “domain.tld.undefined”, or did you edit the message to redact your domain name?


#3

Hi, I edited it to redact my domain.


#4

Without your domain name it makes it difficult to identify the real issue.

You could try checking the DNS records at somewhere like viewdns.info , intodns.com or dnsstuff.com

Also check that you can reach a test file, from the general internet, that you place in yourdomain.com/.well-known/acme-challenge/test and that it returns the contents in plain text.


#5

In the past, we have seen problems with hosts that reply to all-lowercase domain name queries, but not to mixed lower-upper case queries of the domain name. LE uses mixed case queries for better security. Can you check whether this is OK with you?


#6

git.bin-bash.net is my domain could please check it via nslookup? :slight_smile:

Thank you.


#7

Your DNS looks fine, however I can’t reach your site. I get a connection refused on both http and https. Are you sure there isn’t a firewall blocking access ?


#8

Yeah webserver is offline. But also without it should work to generate cert. or?


#9

You could generate the cert in standalone mode ( where the LetsEncrtypt script provides the web server ) otherwise a webserver is needed.

The only other option would be to use the DNS challenge, which doesn’t require a working webserver.


#10

I tried the cert in standalone mode but with no effort :(. What I am doing wrong here:

sudo ./letsencrypt-auto certonly --standalone -d git.bin-bash.net -d www.git.bin-bash.net

I get the same error than before. :sweat:

Any other suggestions?


#11

Aha, I found it: You are not serving A DNS record for www.git.bin-bash.net. Please add a new DNS record or a CNAME regarding the www subdomain. Results from Mxtoolbox:

a:www.git.bin-bash.net

No a Records exist

Reported by dns3.registrar-servers.com on 4/29/2016 at 1:00:49 PM (UTC 0), just for you.


#12

Oh sorry you are right. Thanks you guys helped me a lot, now I think it works :smiley: hurray.


#13

Can you elaborate on this for my curiosity and education? What scheme of case mixing is used? What risk(s) does this mitigate?


#14

It’s to protect against cache poisoning, randomising the case adds another thing to the randomised query IDs and source ports.


#15

That’s a really, really great article – but not about this particular random mixed case strategy. It doesn’t mention case at all, in fact. RFC 4343 is probably a more informative reference here, and it doesn’t seem to agree with the strategy.

Specifically, indirect labels are legitimate, and do not provide case preservation on output. Moreover, implementations in general are not required to provide case preservation on input, at all. It therefore seems to me that this strategy provides more breakage than protection.

$0.02,
LT


#16

https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 may be an appropriate document to read on this topic.


#17

Ah, thanks, very appropriate, and very informative indeed. It’s the question section that can be relied on (ubiquitously, if not by requirement). I retract my prior conclusion.

Final question, with apologies for the threadjack: Does LE ensure the validity of this check by implementing its own resolver library?

Thanks again,
LT


#18

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