Getssl: "DNS problem: query timed out looking up A for stokkie.net

This is becoming annoying, because when the dns check passes with
flying colors at DNS Check and DNS Report Tools - Comprehensive DNS Tests - MxToolBox for stokkie.net,
how can .letsencrypt.org and getssl fail like this ? :

[hubble:root]:(~)# getssl -a
Check all certificates
Registering account
Verify each domain
Verifying stokkie.net
copying challenge token to /home/klant/crashrecovery/www/.well-known/acme-challenge/9YTBUA4DoCuE8pl9MmNr6xYMp5Pp6cxiC3X1xOYbZAM
sending request to ACME server saying we're ready for challenge
checking if challenge is complete
Pending
checking if challenge is complete
Pending
checking if challenge is complete
Pending
checking if challenge is complete
Pending
checking if challenge is complete
Pending
checking if challenge is complete
getssl: stokkie.net:Verify error: "detail": "DNS problem: query timed out looking up A for stokkie.net; DNS problem: query timed out looking up AAAA for stokkie.net",
[hubble:root]:(~)#

What is failing?
I see this with Firefox

1 Like

And I see a DNS A record

1 Like

This may not be the only problem, but your ns2 server (92.67.169.193) doesn't answer over tcp.

https://dnsviz.net/d/stokkie.net/dnssec/

  • stokkie.net zone: The server(s) were not responsive to queries over TCP. (92.67.169.193)
  • stokkie.net/SOA: No response was received from the server over TCP (tried 3 times). (92.67.169.193, TCP_-_EDNS0_4096_D_N)

I similarly see a problem when I try over TCP:

$ dig +tcp +norecurse stokkie.net @92.67.169.193

(just hangs without a response)

I believe Let's Encrypt uses TCP more often than the average DNS resolver due to it being more secure.

I don't see a problem with the ns1 server offhand, so I don't think it should be completely fatal, but it's something to look at.

5 Likes

the ACME server doesn't see a A record for stokkie.net

Thanks, i will check whats happening with ns2

1 Like

ns2 server (92.67.169.193) does not do tcp queries, only udp

so dig +norecurse stokkie.net @92.67.169.193 should work

Maybe the firewall of ns2, only has udp 53 enabled and not tcp 53
will check tomorrow. Is letsencrypt/ACME requiring tcp 53 access to
your nameservers ?

There are some serious DNS issues with your domain:
DNS Spy report for stokkie.net

3 Likes

I think that if the response is small enough it can use UDP, but many requests end up going over TCP. You might want to check out RFC 7766, which tries to make the case that "support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation."

Even with that issue, though, in theory it should be able to get a response from the other DNS server, so there may be something else going on as well. Do either of your DNS servers have some sort of firewall that's trying to be "smart" and might be blocking the traffic? Let's Encrypt checks your system from multiple vantage points at once, which some firewalls interpret as an "attack" since it's several places at once all requesting the same thing. Or there might be a geographic or IP blocklist that's blocking the traffic.

5 Likes

Not to my knowledge :
https://i.imgur.com/JsALu1r.png

I see this

$ nslookup
> server ns1.stokkie.net
Default server: ns1.stokkie.net
Address: 84.87.53.162#53
> stokkie.net
;; connection timed out; no servers could be reached
> set q=soa
> stokkie.net
;; connection timed out; no servers could be reached
> exit

$ nslookup
> server ns2.stokkie.net
Default server: ns2.stokkie.net
Address: 92.67.169.193#53
> stokkie.net
;; connection timed out; no servers could be reached
> set q=soa
> stokkie.net
;; connection timed out; no servers could be reached
>
1 Like

And from here DNS Lookup - Check DNS Records the DNS SOA Record has
SOA stokkie.net 21600 ns1.stokkie.net. hostmaster.stokkie.net.

But here the TTLs varies

1 Like

Interesting from here https://check-your-website.server-daten.de/?q=stokkie.net#soa-entries the TTLs are 86400
Your DNS needs help, it is not providing consistent answers (and sometime none at all) from various locations.

1 Like

thats obvious now. It looks I'm under a UDP port 53 DDOS attack :

[acer30:stock]:(~)$ nslookup 
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> stokkie.net
Server:         8.8.8.8
Address:        8.8.8.8#53

** server can't find stokkie.net: NXDOMAIN
> ^C[acer30:stock]:(~)$ 
[acer30:stock]:(~)$ 
[acer30:stock]:(~)$ 
[acer30:stock]:(~)$ nslookup 
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> stokkie.net
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   stokkie.net
Address: 84.87.53.162
>   
[acer30:stock]:(~)$ 

Something is definitely going on:

nslookup stokkie.net 84.87.53.162
;; connection timed out; no servers could be reached

nslookup stokkie.net 92.67.169.193
;; connection timed out; no servers could be reached
3 Likes

You need more DNS servers.
You may also need a better defense for them / different O/S or version.
[you need to find the weakness and send it to the GYM - LOL]

3 Likes

Inside the options file getssl.cfg one can specify a PUBLIC_DNS_SERVER .
The public DNS servers of Google seem to work just fine for my domain.
So I use this inside .getssl/getssl.cfg :

PUBLIC_DNS_SERVER="8.8.4.4"

But somehow letsencrypt still fails with :

getssl: stokkie.net:Verify error:    "detail": "DNS problem: query timed out looking up A for stokkie.net; DNS problem: query timed out looking up AAAA for stokkie.net",

That would only affect getssl. It does not affect the inbound requests to your server from the Let's Encrypt Servers.

The DNS problems noted earlier still seem a problem. The Let's Encrypt failure can also be repeated by the Let's Debug test site (see here for results).

I can use your DNS from various test servers. As noted by others already, your DNS is not responding consistently from all places.

5 Likes

Sometimes things progress slowly, but surely : DNS over tcp port 53 now works :

$ dig +tcp +norecurse stokkie.net @92.67.169.193

; <<>> DiG 9.8.1 <<>> +tcp +norecurse stokkie.net @92.67.169.193
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37274
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;stokkie.net.                   IN      A

;; ANSWER SECTION:
stokkie.net.            86400   IN      A       84.87.53.162

;; AUTHORITY SECTION:
stokkie.net.            86400   IN      NS      ns2.stokkie.net.
stokkie.net.            86400   IN      NS      ns1.stokkie.net.

;; ADDITIONAL SECTION:
ns1.stokkie.net.        86400   IN      A       84.87.53.162
ns2.stokkie.net.        86400   IN      A       92.67.169.193

;; Query time: 18 msec
;; SERVER: 92.67.169.193#53(92.67.169.193)
;; WHEN: Tue Oct 18 00:09:58 2022
;; MSG SIZE  rcvd: 113

$
1 Like