I did the test with --dry-run and 600 seconds, still Incorrect TXT record found during second validation
From my Internet point of view:
dig -t TXT _acme-challenge.adopteunmanchot.com @ns1.tootai.net +short
;; communications error to 2a01:4f8:120:1104::2#53: timed out
;; communications error to 2a01:4f8:120:1104::2#53: timed out
;; communications error to 2a01:4f8:120:1104::2#53: timed out
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
dig -t TXT _acme-challenge.adopteunmanchot.com @ns2.tootai.net +short
;; communications error to 2a01:729:16e::2#53: timed out
;; communications error to 2a01:729:16e::2#53: timed out
;; communications error to 2a01:729:16e::2#53: timed out
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
dig -t TXT _acme-challenge.adopteunmanchot.com @ns3.tootai.net +short
;; communications error to 2001:67c:1298::1#53: timed out
;; communications error to 2001:67c:1298::1#53: timed out
;; communications error to 2001:67c:1298::1#53: timed out
;; communications error to 2a01:4f8:1c0c:4090::2#53: timed out
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
dig -4 -t TXT _acme-challenge.adopteunmanchot.com @ns1.tootai.net +short
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
dig -4 -t TXT _acme-challenge.adopteunmanchot.com @ns2.tootai.net +short
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
dig -4 -t TXT _acme-challenge.adopteunmanchot.com @ns3.tootai.net +short
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
It seems like the IPv6 paths are much more problematic than the IPv4 paths.
IPv4 responses were immediate.
Can you add an IPv4 only path to the list of nameservers?
3 Likes
SOA serial values are not matching:
2a01:4f8:120:1104::2 ns3.tootai.net. postmaster.adopteunmanchot.com. 2024011526 43200 3600 1209600 1800
2a01:729:16e::2 ns3.tootai.net. postmaster.adopteunmanchot.com. 2024011624 43200 3600 1209600 1800
2001:67c:1298::1 ns3.tootai.net. postmaster.adopteunmanchot.com. 2024011526 43200 3600 1209600 1800
2a01:4f8:1c0c:4090::2 ns3.tootai.net. postmaster.adopteunmanchot.com. 2024011526 43200 3600 1209600 1800
94.130.180.148 ns3.tootai.net. postmaster.adopteunmanchot.com. 2024011526 43200 3600 1209600 1800
109.237.252.179 ns3.tootai.net. postmaster.adopteunmanchot.com. 2024011624 43200 3600 1209600 1800
78.46.82.168 ns3.tootai.net. postmaster.adopteunmanchot.com. 2024011526 43200 3600 1209600 1800
How is your BIND configured?
3 Likes
Thanks for pointing this, I failed this morning, sorry. Corrected
1 Like
During this 10 minute wait time did you check all your nameservers? You should see a new TXT record value in all of them.
Right now I still see just that old record starting with 7FRy. And, that is correct if your rfc2156 plugin added a new value but then deleted it.
But, checking them during that wait time will likely show that one or more of them are not getting a new TXT value. You should probably check both the IPv4 and IPv6 address of each one given what @rg305 showed. Make a script to check them all so you can run it repeatedly during this wait time.
As an aside, I cannot reach ns2 on either IPv4 or IPv6 right now
dig +noall +answer TXT _acme-challenge.adopteunmanchot.com @ns2.tootai.net
;; communications error to 2a01:729:16e::2#53: timed out
;; communications error to 2a01:729:16e::2#53: timed out
;; communications error to 2a01:729:16e::2#53: timed out
;; communications error to 109.237.252.179#53: connection refused
;; no servers could be reached
4 Likes
All our servers can be reached from here -France or Germany- doesn't matter ipv4 or ipv6. Where are your validating server located ? US ?
In logs I see the RR coming on the server on which I launch the certbot (ns2)
16-Jan-2024 15:50:47.727 update: info: client @0x7fc93836c568 192.168.10.254#40548/key certbot: view external: updating zone 'adopteunmanchot.com/IN': adding an RR at '_acme-challenge.adopteunmanchot.com' TXT "PiZQnflfKpi_3yO1ezdgShGkmQtJ22Vw0Vy0n88Wm9I"
16-Jan-2024 15:50:47.811 update: info: client @0x7fc93836c568 192.168.10.254#40578/key certbot: view external: updating zone 'adopteunmanchot.com/IN': adding an RR at '_acme-challenge.adopteunmanchot.com' TXT "ma1LmX0biwcEjK9a0mW7PrGqv1MJOQ4ai1X6Qwnx3qM"
16-Jan-2024 15:51:59.515 update: info: client @0x7fc9328b8b68 192.168.10.254#56314/key certbot: view external: updating zone 'adopteunmanchot.com/IN': deleting an RR at _acme-challenge.adopteunmanchot.com TXT
16-Jan-2024 15:51:59.607 update: info: client @0x7fc93351eb68 192.168.10.254#56332/key certbot: view external: updating zone 'adopteunmanchot.com/IN': deleting an RR at _acme-challenge.adopteunmanchot.com TXT
On ns1 nothing. On ns3 I have in logs:
16-Jan-2024 15:51:48.289 security: info: client @0x7fc02f63e168 2600:3000:2710:300::14#42186 (_aCme-cHALlEngE.ADopteUNmAnchOT.COm): view external: query '_aCme-cHALlEngE.ADopteUNmAnchOT.COm/TXT/IN' denied
16-Jan-2024 15:51:48.461 security: info: client @0x7fc02f63e168 2600:3000:2710:300::14#57698 (_acmE-CHallENge.AdOpTeUnmanchot.com): view external: query '_acmE-CHallENge.AdOpTeUnmanchot.com/TXT/IN' denied
16-Jan-2024 15:51:49.282 security: info: client @0x7fc02f63e168 2600:3000:2710:300::85#42868 (AdoPteUnMaNchoT.com): view external: query 'AdoPteUnMaNchoT.com/DNSKEY/IN' denied
16-Jan-2024 15:51:58.722 security: info: client @0x7fc02f63e168 2600:1f14:a8b:502:ed1f:4a1b:30d1:e2a7#9375 (adoptEunmaNchOt.CoM): view external: query 'adoptEunmaNchOt.CoM/DNSKEY/IN' denied
I tried with allow-query { 0.0.0.0/0; };for this zone, LE is coming with ipv6, get denied but don't come back in ipv4. This test was done before the above one.
The Let's Encrypt validation server farms are mostly in the US but also one in Germany (I think). They make no guarantee of this and say you must support DNS queries from anywhere.
My own tests are from a server in the AWS US East Coast region.
I can again reach ns2 but IPv6 tests to ns3 do not show any TXT value. The other 5 queries return the old 7FRy... value
dig -4 +short TXT _acme-challenge.adopteunmanchot.com @ns3.tootai.net
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
dig -6 +short TXT _acme-challenge.adopteunmanchot.com @ns3.tootai.net
dig -4 +short TXT _acme-challenge.adopteunmanchot.com @ns2.tootai.net
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
dig -6 +short TXT _acme-challenge.adopteunmanchot.com @ns2.tootai.net
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
dig -4 +short TXT _acme-challenge.adopteunmanchot.com @ns1.tootai.net
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
dig -6 +short TXT _acme-challenge.adopteunmanchot.com @ns1.tootai.net
"7FRyJaeWQq7uN0WAB9nGNcGS3J5OLh_2RoGq3z2qlUE"
4 Likes
Yes, all files are shown in TXT as renew fail! From here ns3 show TXT for ipv4 and ipv6. Is it possible to force the LE German server-s to do the test-s (if really existing)?
Files are all 664 for user root:bind in /var/cache/bind so should'nt be a problem for named to write in the directory. In the zone file I have
update-policy {
grant certbot. name _acme-challenge.adopteunmanchot.com. txt;
};
and certbot.key is hmac-512. If that help ...
ns3 has 2 ipv6 ips, so LE should fallback to the second one if first is not working.
Recently that was the SOA value on one server:
109.237.252.179 ns3.tootai.net. postmaster.adopteunmanchot.com. 2024011637 43200 3600 1209600 1800
Later I got the following:
109.237.252.179 ns3.tootai.net. postmaster.adopteunmanchot.com. 2024011635 43200 3600 1209600 1800
It is a smaller serial value than before. What is going on, there? I never seen a thing like that before.
3 Likes
Since days I try to get dns renew working, for debugging I modify the DNSs for this domain, so such things happend as:
. I discover that .signed file for any reason doesn't reset the serial number to the one from zone file
. rndc reload doesn't reload SOA, have to do an systemctl restart named
With the help of this list I discover behaviors like the one you describe, everything is corrected and shouldn't arise in the future. Only problem I'm aware at this time is the ipv6 of ns3 which fail, problem lies on the provider side.
From the three DNS servers one is configured as master for the other two as slaves, isn't it?
One DNS server has two IPv6 addresses, hasn't it?
(3 IPv4 address + 4 IPv6 addresses)
3 Likes
No, Let's Encrypt uses multipoint validation from several locations. There is no way to control this.
We could try a manual test
sudo certbot certonly --dry-run --manual --preferred-challenge dns-01 -d adopteunmanchot.com
Certbot will show you a value to add to your DNS.
Certbot pauses and says press Enter after you confirm your DNS updated
BUT, Do Not press Enter
Instead post here the value of that TXT record and we will look too
3 Likes
No, all 3 are masters, modification on one of them is automatically reported to the 2 others. I removed the failing ipv6 from ns3, now 3 times ipv4 and 3 times ipv6
Appart of port 53 UDP & TCP should another port be opened ?
I revoke & removed 1 certificate alsace.eu.org and tried to generate a new one as well as another new certificate for a new domain swiss-itech.ch, done from ns2. Both creation failed, always got RR record creating/deleting on ns2 server, nothing on ns1 and ns3.
For the new domain swiss-itech.ch I received
DNS problem: NXDOMAIN looking up TXT for _acme-challenge.swiss-itech.ch - check that a DNS record exists for this domain
Is this normal as it is a new domain so a new record to create ?
Will now try your manipulation with adopteunmanchot.com
pYia4K6bHsmGN4VMyVyB_mvsbh8QFeEyUG8F-sE7ghU
I don't see that new record on any of your servers with IPv4 or v6
Do you see it now?
I still see just the older 7FRy... record
3 Likes
So I misunderstand you: do you want me to add it to the zone ? Console is till wiating for the ENTER 
Yes, add it but do not press Enter.
This manual method makes queries easier than trying to query within the 10 minute propagation delay of the prior attempt.
3 Likes
Zone updated on all servers