Let's Encrypt uses outdated DNS information

Help
1

I have a domain where Let's Encrypt still uses the previous IP address.
Setup:

  • Nameserver unchanged in WHOIS for years
  • Domain has two nameservers
  • Changed in both nameservers, verified via "dig @NSNAME A DOMAIN"

Still, Let's Encrypt refuses to use this IP address an still uses the outdated one.
From my understanding Let's Encrypt should not be affected by DNS propagation so I don't understand why it still uses the old IP address.
This is a huge issue as I cannot currently use HTTPS on the domain even though it worked on the old host.

2

Your thread is more suitable for the Help section instead of the Issuance Tech category.

If you would have opened this thread in the Help section, you would have been provided with a questionnaire. Please fill out the questionnaire below to the best of your knowledge:

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

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

That being said: Let's Encrypts DNS resolver, unbound, crawls from the root to the authorative nameservers, so there probably is something incorrectly setup. But without knowing the information above, especially the hostname which is failing, we can't say anything more than generic "it should work".

3 Likes
3

WHOIS information is NOT an authoritative DNS source for any domain.
[and it can sometimes be delayed or outdated for many days/weeks]

If you fill in the form requested above, we may be able to better help you.

4 Likes
4

My domain is:
realmsofthehaunting.com

I ran this command:
through NGINX Proxy Manager:
2024-01-28 12:13:25,034:DEBUG:certbot._internal.main:Location of certbot entry point: /opt/certbot/bin/certbot
2024-01-28 12:13:25,034:DEBUG:certbot._internal.main:Arguments: ['--config', '/etc/letsencrypt.ini', '--work-dir', '/tmp/letsencrypt-lib', '--logs-dir', '/tmp/letsencrypt-log', '--cert-name', 'npm-28', '--agree-tos', '--authenticator', 'webroot', '--email', 'XXXXXX_EMAIL_REMOVED_XXXXXX', '--preferred-challenges', 'dns,http', '--domains', 'www.realmsofthehaunting.com']

It produced this output:
X-Frame-Options: DENY
...
{
"identifier": {
"type": "dns",
"value": "www.realmsofthehaunting.com"
},
"status": "invalid",
"expires": "2024-02-04T12:13:25Z",
"challenges": [
{
"type": "http-01",
"status": "invalid",
...
"addressesResolved": [
"159.69.43.201"
],
...
}

My web server is (include version):
n/a, but it's NGINX

The operating system my web server runs on is (include version):
Debian inside Docker

My hosting provider, if applicable, is:
n/a

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):
2.8.0

dig +short  SOA realmsofthehaunting.com | cut -d' ' -f1
ns1.tricos.net.

whois realmsofthehaunting.com | grep "Name Server"
   Name Server: NS1.TRICOS.NET
   Name Server: NS2.TRICOS.NET

dig @ns1.tricos.net A realmsofthehaunting.com | grep IN
;; WARNING: recursion requested but not available
;realmsofthehaunting.com.       IN      A
realmsofthehaunting.com. 81989  IN      A       128.140.60.49

dig @ns2.tricos.net A realmsofthehaunting.com | grep IN
;; WARNING: recursion requested but not available
;realmsofthehaunting.com.       IN      A
realmsofthehaunting.com. 81987  IN      A       128.140.60.49

The IP address it resolves to is the previous IP address.
Interestingly it worked with other domains on the same instance before that were moved from the same old IP address to the new one.

5

To avoid confusion - www is a CNAME and the same thing happens when using realmsofthehaunting.com without a subdomain.

6

Weird. I'm getting the same IP address as you're getting, but Unbound doesn't seem to agree:

https://unboundtest.com/m/A/www.realmsofthehaunting.com/AUEQIGA6

It's rather hard to debug with all that information, but it does seem to be getting its reply from one of the authorative nameservers at 213.198.91.2 (ns2.tricos.net)?

Using Google I'm also getting the incorrect IP address:

https://toolbox.googleapps.com/apps/dig/#A/realmsofthehaunting.com

But I did get the other one just once?

Another online dig gets the correct one:

I feel there's something funny going on at your DNS provider. As multiple non-Let's Encrypt sites also get the incorrect IP address, I'm pretty sure this is not a Let's Encrypt thing.

4 Likes
7

Who is/are: tricos.net ?
Is that you?
How are you/they handling the DNS requests?

5 Likes
8

I suspect the IPv6 address of your nameserver(s) point to different servers to the IPv4 ones, I'm not on IPv6 to test with.

4 Likes
9

ns1.tricos.net and ns2.tricos.net are "virtual nameservers", i.e. they are aliases to the real nameservers from a DNS provider who allows for this specifically. I can manage the DNS settings there. Please also note that ns1.tricos.net and ns2.tricos.net only have IPv4 records, no IPv6 records (yet).

This is still really weird - here some more information after some digging. I also moved two other domains and was able to successfully retrieve TLS certificates a few minutes before with domains with the same nameservers from the same original IP address to the same new IP address. So technically there's absolutely no difference between these three domains when it comes to NS1, NS2, A, CNAME, old IP and new IP settings.

No issues with these other domains and the DNS Propagation Checker at dnschecker.org shows all of them having the new address. When doing this for realmsofthehaunting.com however the IP address sometimes toggles between the old and new IP even from the same origin - which I find very weird as I could not reproduce this when querying ns1.tricos.net and ns2.tricos.net multiple times.

What I found out however is that 1.1.1.1 (CloudFlare) still returns the wrong IP whereas Google (8.8.8.8) and Quad9 (9.9.9.9) return the correct new address.

I'll contact the DNS server vendor but as it worked with two other domains configured the exactly same way this looks a bit illogical to me that the DNS server should be the culprit.

10

What else could it be? :man_shrugging:t2: Unboundtest queries the authorative nameservers and it's not able to just come up with an incorrect IP address without any reason. It must have gotten it from ns1.tricos.net and ns2.tricos.net.

Are those nameservers using anycast perhaps?

2 Likes
11

I'll wait for the reply. I just noticed that Cloudflare returns the correct new IP and tried again.
Now I see this flip-flopping in a single request:

     "validationRecord": [
        {
          "url": "http://www.realmsofthehaunting.com/.well-known/acme-challenge/....",
          "hostname": "www.realmsofthehaunting.com",
          "port": "80",
          "addressesResolved": [
            "159.69.43.201"
          ],
          "addressUsed": "159.69.43.201"
        },
        {
          "url": "https://www.realmsofthehaunting.com/.well-known/acme-challenge/....",
          "hostname": "www.realmsofthehaunting.com",
          "port": "443",
          "addressesResolved": [
            "128.140.60.49"
          ],
          "addressUsed": "128.140.60.49"
        }
      ],
1 Like
12

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