Validation: DNS problem

Hi,

Error LOG ;

Status: 400
Detail: During secondary validation: DNS problem: query timed out looking up CAA for aidat.pro
[2020-03-15 22:53:53.861] ERR [extension/letsencrypt] Domain validation failed: Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/3378144459.
Details:
Type: urn:ietf:params:acme:error:dns
Status: 400
Detail: During secondary validation: DNS problem: query timed out looking up CAA for aidat.pro

Only the server’s main ip address has been changed. How can we fix it?

Thank you.

1 Like

There is no A record for deneme.aidat.pro, add one (or a cname).

1 Like

Hi @corelux

if you have that problem (“secondary validation”): Letsencrypt has added a “multiple network validation”.

Read

The Letsencrypt servers are able to check your CAA entry. The additional servers aren’t, that’s the error message.

May be a blocking DNS firewall.

deneme.aidat.pro

is your domain. CAA is a “tree climbing check”. So if you have a CAA entry with deneme.aidat.pro, your aidat.pro entry isn’t checked.

May be it helps if you create a CAA entry with deneme.aidat.pro.

Can you check it now?
I added the A record. But the error is as follows

type: urn:ietf:params:acme:error:dns

Status: 400

Detail: During secondary validation: DNS problem: SERVFAIL looking up A for deneme.aidat.pro - the domain’s nameservers may be malfunctioning

I manually added the CAA value. Unfortunately, nothing has changed.

Error

Type: urn:ietf:params:acme:error:dns

Status: 400

Detail: During secondary validation: DNS problem: SERVFAIL looking up A for deneme.aidat.pro - the domain’s nameservers may be malfunctioning

only server’s main ip address had changed.

I tried querying your domain’s nameserver from one of the AWS regions used by the secondary validation servers, and it timed out.

Is your nameserver blocking traffic from any IPs? In particular, AWS IPs?

1 Like

Thanks @mnordhoff for hinting AWS issue. Have arrived here with the same (comparatively recent) problem on all our servers, resolved by bulk deleting AWS IPs from firewall.

AWS is a well known hub of spammers, scrapers, bots & all sorts of nasties. We increasingly faced a non-stop storm of all sorts of “attacks” from AWS IPs, getting involved in a futile wack-a-mole campaign of banning individual offending IP ranges - till we decided to block en masse all AWS known IPs and thus get some peace of mind.

Since overall we are not aware of what Letsencrypt IPs to whitelist, we are forced to weaken our firewall to a great extend to be able to use Letsencrypt.

Unwittingly Letsencrypt, dedicated to web security, is in effect exposing our servers to security issues by weakening by some of its decisions some of our firewall defenses.

I am not advocating here publication of IPs to whitelist. They have indeed to remain secret. However, Letsencrypt IPs should be far, far away from clusters candidate for IP range blacklisting such as AWS, Google, Microsoft, Oracle, Hetzner and other such nasty clouds.

I hope this makes sense.

.

If your network’s security depends on an absolute blacklist of AWS IPs, there are other, more serious, problems with your network security. But if this concerns you, there’s a simple answer: use DNS validation.

@danb35 : Thanks, however I’m afraid you’re missing the point. Our over 20-year server invincibility has convinced us we are doing something right security-wise, including not snubbing a few low-tech measures - such as using (among others) a medical mask and washing hands in the Age of Covid-19 to block the virus. Limiting exposure helps. Why let nasties knock at your door when you may block them at the highway?

And avoiding avoidable hoops, especially when a large number of domains is involved over multiple servers.

K.I.S.S.

.

Hi @abramos

it doesn’t help. These are Script kiddies. If your server is vulnerable against such scripts, you have a problem.

And if someone really want’s to hack your server, it’s easy to use an ip address you don’t block.

Thanks @JuergenAuer, however beg to differ. On the premise there is no 100% security anywhere, not on the web, not in the real world, limiting exposure by eliminating avenues & raising multiple barriers, is prudent in security. Certainly, not as exclusive defense. Eventually, as things stand, if sever is truly worth hacking (ex. bank) it may be hacked. Our servers, glad to say, are not worth the volume of trouble required to hack them, due to (among others) limited exposure. This includes blocking all countries not interested in, and server clusters known as trouble hubs. Little value, if any, exposing ourselves to the likes of AWS. Cost of blocking them, negligible. All “for fun & glory” efforts against us, as well as for-profit ones, have to date failed miserably.

(Hope this doesn’t sound like a lecture, not meant to be. Despite experience, learning new things by the day, full of ears!).

My point: believe Letsencrypt better avoid verifying from AWS IPs or any such extensive cloud known open to abuse, and liable to firewall blocking.

Letsencrypt rightly limits exposure by not publicizing its IPs for whitelisting. Others have similar concerns, which should not be snubbed. Maybe it’s not exactly the same, but in principle it’s the same.

.

Last, but not least, valid reason for our blocking entire undesirable server clouds is the considerable server resource drain caused by bots, spammers, scrapers, etc, operating from them. Prior to mass blocking server clouds, most of our server resources & bandwidth were drained by such undesirables while true human traffic required just a fraction of our computing power.

We had a spectacular improvement of this situation by such blocking & limiting our exposure, without any loss of business and at the same time significant server performance improvement.

AWS, where Letsencrypt verifies from, had 1250 ranges blocked by us. Reduction of undesirable “traffic” originating from AWS was unbelievable. However, we needed to re-open the floodgates to this hell to keep Letsencrypt functional.

Hopefully, Letsencrypt will take this point into consideration, and hide its IPs in locations not susceptible to essential blocking.

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