Misleading Error? "DNS problem NXDOMAIN looking up A"

I'm working on this problem since hours. I read that I should include an A DNS record for a www. part of my domain. I tried it all, even a wildcard. Could you help me? My DNS records are set correctly or did I miss anything?

I include a screenshot of my AWS config:

My domain is: ripped.link

I ran this command: sudo caddy reverse-proxy --from ripped.link --to 0.0.0.0:9000

It produced this output:
tls.issuance.acme.acme_client challenge failed {"identifier": "ripped.link", "challenge_type": "tls-alpn-01", "status_code": 400, "problem_type": "urn:ietf:params:acme:error:dns", "error": "DNS problem: NXDOMAIN looking up A for ripped.link - check that a DNS record exists for this domain"}

My web server is (include version): caddy

The operating system my web server runs on is (include version): ubuntu 20.04

My hosting provider, if applicable, is: AWS Route 53

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): dunno sorry

2 Likes

Have you registered that domain? Because there doesn't seem to be any NS record for it:

 dan@Dan-Hack-Mini  ~  dig ns ripped.link

; <<>> DiG 9.10.6 <<>> ns ripped.link
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1490
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ripped.link.			IN	NS

;; AUTHORITY SECTION:
link.			823	IN	SOA	ns.uniregistry.net. regops.uniregistry.link. 1626363689 1800 900 604800 86400

;; Query time: 3 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jul 15 11:44:39 EDT 2021
;; MSG SIZE  rcvd: 113
3 Likes

ICANN whois lookup shows it registered via Gandi and even lists AWS nameservers. But yeah, it's weird that the TLD's nameservers aren't returning any NS records for it. That's the root of the problem.

You might want to open a ticket with Gandi and ask them what's going on assuming you're the registered owner, @raphaellueckl.

6 Likes

OR
Move your domain to another registrar that (better) supports .link domains.

#SOSCUBA

2 Likes

AWS Route 53 Domain Registration sometimes acts as a reseller for Gandi. Was the domain bought through AWS directly?

2 Likes

In any case: there's nothing "misleading" about the error: that's just what the Let's Encrypt validation servers DNS resolver sees.. And also the rest of the world.

3 Likes

Yeah! I never heard of Gandi. :slight_smile:

2 Likes

Thanks for your response mate! I have other domains too and will check if those maybe work, of if this is a general problem.

I am the registered owner (I guess, since I ordered over AWS).

4 Likes

Yeah the domain is registered by me. Weird enough that let's encrypt worked for me with other domains (but not with caddy, just with the certbot standalone).

2 Likes

Wait, I see name servers being listed, or am I missing something?

2 Likes

That's just the WHOIS information. Apparently this info is not known at the .link nameservers.

4 Likes

Were the other domains you've used (that work) also .link or were they other TLDs? You can look at AWS's documentation on supported TLDs and see that .link is done through Gandi.

But in any event, AWS isn't currently giving you the product you've bought, as you've registered the name but the .link DNS servers don't know about it. You need to contact AWS Support and get them to fix it.

3 Likes

Thanks I will get in contact with them. :slight_smile:

4 Likes

I had to update my personal data associated with this domain. The error I get now is a different. Bad gateway?! Not sure why that one happens. Any ideas?

2021/08/03 11:56:05.503 INFO    tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "ripped.link", "challenge_type": "tls-alpn-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
2021/08/03 11:56:06.100 ERROR   tls.issuance.acme.acme_client   challenge failed        {"identifier": "ripped.link", "challenge_type": "tls-alpn-01", "status_code": 400, "problem_type": "urn:ietf:params:acme:error:connection", "error": "Connection refused"}
2021/08/03 11:56:06.100 ERROR   tls.issuance.acme.acme_client   validating authorization        {"identifier": "ripped.link", "error": "authorization failed: HTTP 400 urn:ietf:params:acme:error:connection - Connection refused", "order": "https://acme-v02.api.letsencrypt.org/acme/order/130671497/14228132870", "attempt": 1, "max_attempts": 3}
2021/08/03 11:56:07.480 INFO    tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "ripped.link", "challenge_type": "http-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
2021/08/03 11:56:08.195 ERROR   tls.issuance.acme.acme_client   challenge failed        {"identifier": "ripped.link", "challenge_type": "http-01", "status_code": 400, "problem_type": "urn:ietf:params:acme:error:connection", "error": "Fetching http://ripped.link/.well-known/acme-challenge/Qr4DKMU30cW34iRsoSgUrdDYga21tZhlEg1KvlqMdlw: Connection refused"}
2021/08/03 11:56:08.195 ERROR   tls.issuance.acme.acme_client   validating authorization        {"identifier": "ripped.link", "error": "authorization failed: HTTP 400 urn:ietf:params:acme:error:connection - Fetching http://ripped.link/.well-known/acme-challenge/Qr4DKMU30cW34iRsoSgUrdDYga21tZhlEg1KvlqMdlw: Connection refused", "order": "https://acme-v02.api.letsencrypt.org/acme/order/130671497/14228138870", "attempt": 2, "max_attempts": 3}
2021/08/03 11:56:09.809 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "ripped.link", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "[ripped.link] solving challenges: ripped.link: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[http-01 dns-01 tls-alpn-01] remaining=[dns-01]) (order=https://acme-v02.api.letsencrypt.org/acme/order/130671497/14228145490) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
2021/08/03 11:56:09.810 WARN    tls.issuance.zerossl    missing email address for ZeroSSL; it is strongly recommended to set one for next time
2021/08/03 11:56:10.663 INFO    tls.issuance.zerossl    generated EAB credentials       {"key_id": "eZK6ek1WJEBicrZahdEOVQ"}
2021/08/03 11:56:10.871 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "ripped.link", "issuer": "acme.zerossl.com-v2-DV90", "error": "provisioning client: HTTP 504: <html>\r\n<head><title>504 Gateway Time-out</title></head>\r\n<body>\r\n<center><h1>504 Gateway Time-out</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n"}
2021/08/03 11:56:10.871 ERROR   tls.obtain      will retry      {"error": "[ripped.link] Obtain: provisioning client: HTTP 504: <html>\r\n<head><title>504 Gateway Time-out</title></head>\r\n<body>\r\n<center><h1>504 Gateway Time-out</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n", "attempt": 1, "retrying_in": 60, "elapsed": 6.55863172, "max_duration": 2592000}
2 Likes

The "BAD GATEWAY" seems to be generated when the ACME client tries to obtain a cert from ZeroSSL.
2021/08/03 11:56:10.871 ERROR tls.obtain could not get certificate from issuer {"identifier": "ripped.link", "issuer": "acme.zerossl.com-v2-DV90", "error": "provisioning client: HTTP 504: <html>\r\n<head><title>504 Gateway Time-out</title></head>\r\n<body>\r\n<center><h1>504 Gateway Time-out</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n"}
Unfortunately this forum doesn't support that CA.

As for the preceding (seemingly related) errors:
They all show "Connection refused".
Not being familiar with that client and those error messages, I am unclear if that is occuring when the client is trying to reach the CA or while the CA is trying to reach the FQDN to validate.
So... let's try and see which one is failing.
Please show the output of these commands:
curl -v https://acme-v02.api.letsencrypt.org/directory
curl -4 ifconfig.co

4 Likes

For some reason, Caddy attempts ZeroSSL as wel as Let's Encrypt as CA..? What kind of strange behaviour is that?

In any case, the two challenges attempted by the Let's Encrypt ACME validation servers both return a "Connection refused" error: your hostname needs to be available on port 80 or 443 (depending on the challenge used) to the world wide web.

5 Likes

ZeroSSL has no staging/test server equivalent as far as I know. I think some of these clients that now default to ZeroSSL still have some code that tries to use a staging server for test validations before moving to production.

3 Likes

@rmbolger The log mentions the production API, not staging.

3 Likes

Missed that. Nevermind then. With Caddy specifically it may also just be a fallback thing. Try successive known-good CAs until one works.

4 Likes

Caddy is also owned by apilayer and afaik, has had this behaviour for quite some time now. It first tries Let's Encrypt and if that fails, it falls back to ZeroSSL.

5 Likes