hmm...
If I had to guess, I'd say that it can't be set to zero and one second is the lowest setting allowed.
3 Likes
The cache is there for lookups of the root name servers, and the config doesn't let us set override cache times based on depth of recursion.
5 Likes
Ah, I see (again). Didn't think about the root name servers as BIND usually has a named.root semi-hardcoded into its configuration for this purpose. Not sure if Unbound can use such a thing though.
1 Like
Even BIND is using the named.root file as a hint only, it validates the root servers.
3 Likes
Ah, good to know.
In that case it's very unfortunate it's not possible to increase the cache time for the . zone only.
1 Like
Guys, let me bump up my question: how should LE handle the case when the remote nameservers don't support capsforid feature?
Wasn't that already answered in post #36 (below)? I am not intending to be difficult it has just been a long and winding thread 
Are you looking for improved error message? Or some way to more readily identify problematic DNS servers?
5 Likes
I got some time to do a little more digging:
First, ask the root servers:
$ dig +bufsize=512 +dnssec +norecurse Kronus.Spb.Ru. @a.root-servers.net.
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.16.42-RH <<>> +bufsize +dnssec +norecurse Kronus.Spb.Ru. @a.root-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3184
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 11
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;Kronus.Spb.Ru. IN A
;; AUTHORITY SECTION:
Ru. 172800 IN NS a.dns.ripn.net.
Ru. 172800 IN NS e.dns.ripn.net.
Ru. 172800 IN NS f.dns.ripn.net.
Ru. 172800 IN NS d.dns.ripn.net.
Ru. 172800 IN NS b.dns.ripn.net.
Ru. 86400 IN DS 18274 8 2 AB35D17D3F39EB42CEE14C6273247938D33EEEAA9F5CAA70B3858DBF 4BD3E87B
Ru. 86400 IN RRSIG DS 8 1 86400 20230929170000 20230916160000 11019 . NMzOMpWGzb0vmusFYjzFx73oef4OVwPx34AFCH30R1j/WyI+WzpOlIqE 6A8R1ExoE0QMP5ZHyaxoXy9pB3m4jMN7pwmVtzlQ7VQZWHq7PckjrOAQ kE5IF6LJQ333TBwu4FOx3j13+013pr8e4dGJhrwClvbEbJKeXZoHyL2f 29lG+Rcl/qVPtypZjoAQf4lKsNnl8YzM0uq/8NVIVYrn2yWc0dY13V94 zjeM6iBqLGY4NlHbbw81Us2Wbn9VjbBGBGJM3K7JXlm/xJMItpdtGg4d jq9D3QA8434IqNL7YAmk0Y/qjANG4p+AZzKRZO73bryWiBYy8Ph3Lo3l X698Xg==
;; ADDITIONAL SECTION:
a.dns.ripn.net. 172800 IN A 193.232.128.6
a.dns.ripn.net. 172800 IN AAAA 2001:678:17:0:193:232:128:6
e.dns.ripn.net. 172800 IN A 193.232.142.17
e.dns.ripn.net. 172800 IN AAAA 2001:678:15:0:193:232:142:17
f.dns.ripn.net. 172800 IN A 193.232.156.17
f.dns.ripn.net. 172800 IN AAAA 2001:678:14:0:193:232:156:17
d.dns.ripn.net. 172800 IN A 194.190.124.17
d.dns.ripn.net. 172800 IN AAAA 2001:678:18:0:194:190:124:17
b.dns.ripn.net. 172800 IN A 194.85.252.62
b.dns.ripn.net. 172800 IN AAAA 2001:678:16:0:194:85:252:62
;; Query time: 0 msec
;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
;; WHEN: Sat Sep 16 19:47:52 UTC 2023
;; MSG SIZE rcvd: 689
That says to check the .ru server, so let's try one of those:
$ dig +bufsize=512 +dnssec +norecurse Kronus.Spb.Ru. @2001:678:17:0:193:232:128:6
; <<>> DiG 9.16.42-RH <<>> +bufsize +dnssec +norecurse Kronus.Spb.Ru. @2001:678:17:0:193:232:128:6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17793
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;Kronus.Spb.Ru. IN A
;; AUTHORITY SECTION:
SPB.RU. 345600 IN NS ns3-geo.nic.RU.
SPB.RU. 345600 IN NS ns4-geo.nic.RU.
SPB.RU. 345600 IN NS ns8-geo.nic.RU.
SPB.RU. 345600 IN DS 45820 8 2 826F21EA47462EC6F09A3CEA7B1088E801096FCB492CAEAA7BF2C08C 2204127C
spb.ru. 345600 IN RRSIG DS 8 2 345600 20230930091201 20230821081813 35208 ru. vTzlLovm7/2SgEk3yBchKIfFBOgSmdrl/twcaTsL0j3izJyEAJAzHVkL fuS6RJFy8YT/kqv0CZ6rYxiH7PWYoAlVFEeSnLFIQFjtDG44P50Zzurh +al10qtk2OqQimAstgeKOHF6ePo7B9BKwEJr1x/2URhG9zcMX51xAZiR ONQ=
;; Query time: 119 msec
;; SERVER: 2001:678:17:0:193:232:128:6#53(2001:678:17:0:193:232:128:6)
;; WHEN: Sat Sep 16 19:48:57 UTC 2023
;; MSG SIZE rcvd: 334
And that does the weird thing where the authority section doesn't match the case of the query, and gives a different case for the RRSIG record than it does for the NS or DS record.
Okay, let's try the same thing against the same server but for novag.ru instead:
$ dig +bufsize=512 +dnssec +norecurse Novag.Ru. @2001:678:17:0:193:232:128:6
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.16.42-RH <<>> +bufsize +dnssec +norecurse Novag.Ru. @2001:678:17:0:193:232:128:6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31836
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 20
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;Novag.Ru. IN A
;; AUTHORITY SECTION:
NOVAG.ru. 345600 IN NS ns4-l2.nic.RU.
NOVAG.ru. 345600 IN NS ns3-l2.nic.RU.
NOVAG.ru. 345600 IN NS ns4-cloud.nic.ru.
NOVAG.ru. 345600 IN NS ns8-cloud.nic.RU.
NOVAG.ru. 345600 IN NS ns8-l2.nic.RU.
J20C0QKDHUA3CUMNKST289FF06U2SQ91.ru. 3600 IN NSEC3 1 1 0 - J21C11SHOOTMOEQKPRM91C8AGL4886M6 NS SOA RRSIG DNSKEY NSEC3PARAM
J20C0QKDHUA3CUMNKST289FF06U2SQ91.ru. 3600 IN RRSIG NSEC3 8 2 3600 20230922203200 20230821081813 35208 ru. pmdzIJNQ3+mo85zMjzycEKSZDgSwm3VVSOBt+8FJVxnM0aTIwtKn/Kwt 7qjcDp1MPnSE9Z/aXA/rBg/7uJjZTmu6ossSNHPPXduCLRFKfoceruPm SXAKI63b/w6le4c1cwkTXqqFZL6171vXivv6gp/JVmbaJhI2haJRufOu AoU=
15C9F20U40BT04M9SMIQ2QMBN4HTGDBK.ru. 3600 IN NSEC3 1 1 0 - 1624U3F0ETHBRT3TI8DR3SG4EUDSHNHH NS DS RRSIG
15C9F20U40BT04M9SMIQ2QMBN4HTGDBK.ru. 3600 IN RRSIG NSEC3 8 2 3600 20230930104207 20230821081813 35208 ru. WVhtxOBTiZRMFAK+RqTN0l9f2DHYge4ZuMyuRvppkpKCqr7Hdj8s7Ykr OD2vr2Td0yEV5KQcFvpWfCqrelnH6qQwPTsp1Ky83kIC/9lYrNWKAOOD LjjkIawEEGIQzFXxykZj3UcfDDGT/0jFdWEDdzsQUqLKPlE2eGuC6yfp IaY=
;; ADDITIONAL SECTION:
ns3-l2.NIC.ru. 345600 IN A 193.232.146.1
ns4-l2.NIC.ru. 345600 IN A 91.217.20.20
ns8-l2.NIC.ru. 345600 IN A 91.217.21.20
ns4-cloud.NIC.ru. 345600 IN A 89.104.93.34
ns4-cloud.NIC.ru. 345600 IN A 89.104.95.30
ns4-cloud.NIC.ru. 345600 IN A 89.104.95.33
ns4-cloud.NIC.ru. 345600 IN A 89.104.95.34
ns4-cloud.NIC.ru. 345600 IN A 194.67.73.79
ns4-cloud.NIC.ru. 345600 IN A 194.67.73.81
ns4-cloud.NIC.ru. 345600 IN A 89.104.93.30
ns4-cloud.NIC.ru. 345600 IN A 89.104.93.33
ns8-cloud.NIC.ru. 345600 IN A 89.104.93.31
ns8-cloud.NIC.ru. 345600 IN A 89.104.93.35
ns8-cloud.NIC.ru. 345600 IN A 89.104.93.36
ns8-cloud.NIC.ru. 345600 IN A 89.104.95.31
ns8-cloud.NIC.ru. 345600 IN A 89.104.95.35
ns8-cloud.NIC.ru. 345600 IN A 89.104.95.36
ns8-cloud.NIC.ru. 345600 IN A 194.67.73.80
ns8-cloud.NIC.ru. 345600 IN A 194.67.73.82
;; Query time: 119 msec
;; SERVER: 2001:678:17:0:193:232:128:6#53(2001:678:17:0:193:232:128:6)
;; WHEN: Sat Sep 16 19:52:49 UTC 2023
;; MSG SIZE rcvd: 998
So that gives different inconsistent case, and also provides an "Additional section". It also looks like this domain isn't DNSSEC-signed, for whatever that's worth.
Okay, let's try devpegass.ru:
$ dig +bufsize=512 +dnssec +norecurse Devpegass.Ru. @2001:678:17:0:193:232:128:6
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.16.42-RH <<>> +bufsize +dnssec +norecurse Devpegass.Ru. @2001:678:17:0:193:232:128:6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2371
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 23
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;Devpegass.Ru. IN A
;; AUTHORITY SECTION:
DEVPEGASS.ru. 345600 IN NS ns2.reg.ru.
DEVPEGASS.ru. 345600 IN NS ns1.reg.ru.
J20C0QKDHUA3CUMNKST289FF06U2SQ91.ru. 3600 IN NSEC3 1 1 0 - J21C11SHOOTMOEQKPRM91C8AGL4886M6 NS SOA RRSIG DNSKEY NSEC3PARAM
J20C0QKDHUA3CUMNKST289FF06U2SQ91.ru. 3600 IN RRSIG NSEC3 8 2 3600 20230922203200 20230821081813 35208 ru. pmdzIJNQ3+mo85zMjzycEKSZDgSwm3VVSOBt+8FJVxnM0aTIwtKn/Kwt 7qjcDp1MPnSE9Z/aXA/rBg/7uJjZTmu6ossSNHPPXduCLRFKfoceruPm SXAKI63b/w6le4c1cwkTXqqFZL6171vXivv6gp/JVmbaJhI2haJRufOu AoU=
TKNS65V4IDOU6R89JI3R10IHDH8HNVHB.ru. 3600 IN NSEC3 1 1 0 - TKS2A07N4JKIE85SU1B8BHSA9SK81U40 NS DS RRSIG
TKNS65V4IDOU6R89JI3R10IHDH8HNVHB.ru. 3600 IN RRSIG NSEC3 8 2 3600 20231017002832 20230915204438 35208 ru. UwWRE1ZzVPjugp7zGsMBOuoRRlTQqO4gEt0mry/K83bpNAGvx5PcKH2V x2gb2vR3poLzBmMqvWMQj0Vgel/EDj0+v2aO80YiR0PvtdRF+xWZ1rrz 3VuctqIze8BomtXaIZGFurgT4rgI6CPw122MyCD2hMU9TRrNx0mMnaw6 o2o=
;; ADDITIONAL SECTION:
ns1.REG.RU. 345600 IN AAAA 2a00:f940:4::47
ns2.REG.RU. 345600 IN AAAA 2a00:f940:5::190
ns1.reg.ru. 345600 IN A 194.58.117.13
ns1.reg.ru. 345600 IN A 194.58.117.15
ns1.reg.ru. 345600 IN A 194.58.117.17
ns1.reg.ru. 345600 IN A 194.67.73.173
ns1.reg.ru. 345600 IN A 194.67.73.174
ns1.reg.ru. 345600 IN A 176.99.13.11
ns1.reg.ru. 345600 IN A 176.99.13.13
ns1.reg.ru. 345600 IN A 176.99.13.15
ns1.reg.ru. 345600 IN A 176.99.13.17
ns1.reg.ru. 345600 IN A 194.58.117.11
ns2.reg.ru. 345600 IN A 194.58.117.18
ns2.reg.ru. 345600 IN A 194.67.73.175
ns2.reg.ru. 345600 IN A 194.67.73.176
ns2.reg.ru. 345600 IN A 176.99.13.12
ns2.reg.ru. 345600 IN A 176.99.13.14
ns2.reg.ru. 345600 IN A 176.99.13.16
ns2.reg.ru. 345600 IN A 176.99.13.18
ns2.reg.ru. 345600 IN A 194.58.117.12
ns2.reg.ru. 345600 IN A 194.58.117.14
ns2.reg.ru. 345600 IN A 194.58.117.16
;; Query time: 119 msec
;; SERVER: 2001:678:17:0:193:232:128:6#53(2001:678:17:0:193:232:128:6)
;; WHEN: Sat Sep 16 20:01:21 UTC 2023
;; MSG SIZE rcvd: 966
That seems to be much the same, not echoing the case, providing the Additional Section, and not being DNSSEC-signed.
I'm not sure if any of that is actually helpful though, or if I'm just going on a wild goose chase.
I think Let's Encrypt is doing just what they're supposed to, using a standard DNS resolver to try to resolve the name, with the most secure options that they can. I think your only options to fix your problem is to convince the .ru name servers to fix their behavior, or to use a different CA which isn't quite as meticulous in resolving DNS as Let's Encrypt is.
5 Likes
@MikeMcQ well.. I wouldn't say it's been answered.Here is the bottom line as I understand it: everything worked well before, then LE has changed the way it performs some checks and now a huge part of the internet domains can't get LE certificates. Capsforid feature is not a standard yet (correct me if I'm wrong), so it's not an obligatory for internet registries to support it. That means there should be a working fallback for the domains served by such registries. And, as I see it, either the fallback is not working correctly or the fallback is not implemented. Both are not quite good for the domain owners - we can't get the LE certificates anymore.
Unless that secure options are standardized, I guess LE should keep the way of working with not-so-secured registries. Let it send a warning to the domain owners, but keep providing certificates
I think you should review every answer by LE Staff member @jcjones in this thread.
Follow the links in their posts and the advice provided.
4 Likes
Let's Encrypt hasn't changed anything relating to DNS resolution that I'm aware of. They've used 0x20-randomization all along (at least for many years now). I suspect that it's either something on the .ru name servers which have changed, or different routing going to a different DNS server in its load-balancer, or something like that.
6 Likes
How was that determined?
3 Likes
I read them multiple times, believe me. Which one do you think I missed?
Then I'm wrong.
Couple items:
- It used to work before
- letsdebug (and other dns testers) shows no issues at all
Something has clearly changed, but not necessarily on the Letsencrypt side.
The difference between Letsencrypt production and letsdebug can be explained if spb.ru (or a firewall in between the DNS client and server) introduced DNS rate limit. That matches the timeout condition observed on the Letsencrypt side. Of course, this is just one possibility.
By the way, how does the Letsencrypt's staging behave for a domain that fails in production?
5 Likes
I also have teh same issue wityh spb.ru-based domain. Just opened support ticket request and asked to check DNS server settings + anti-DDoS protection settings/events
3 Likes
hello everyone,
having the same issue with a *.spb.ru domain since the last few days.
so.. bump.
1 Like
What is spb.ru and how come there's so many of you?
3 Likes
that's a rather old domain name, dedicated to Saint Petersburg, Russia. They've been providing 3rd level domain registration since around the medieval time.
2 Likes