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: ddbikes.es
I ran this command:
It produced this output:
My web server is (include version): OVH
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is: OVH
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): Plesk Obsidian 18.0.67
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
When reissuing a certificate, the following error is thrown:
No; Let's Encrypt doesn't care about other certificates. But the discrepancy between the DNS record you see and the DNS record Let's Encrypt sees suggests that you may not have updated the NS records for your domain to point to (new or changed, perhaps?) DNS servers. Currently, authoritative DNS for your domain is from ui-dns.com (and .org, .biz, and .de).
I don't know what all "domain redirection" is supposed to entail, so I can't really say whether it was done "correctly" or not. But your results strongly indicate that the DNS server your ACME client is updating, and the DNS server you're checking, aren't the same. So if the "domain redirection" was supposed to update your DNS servers, perhaps that wasn't done.
Yeah I'd guess that your DNS is closely linked to your Osidian control panel (perhaps managed by it?) and your old server is still your nameserver (or vice versa).
For info, you are using DNS based domain validation to get your certs (causing the DNS check), rather than HTTP domain validation (which checks your web server before issuing a certificate).
I would personally figure out what's wrong with your DNS records first, get access to the actual account where they're configured, and fix that part. Not sure if HTTP validation would be easier for you—or if you should even try it—if you can't get the DNS records sorted out.