-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DNS operation timeout with DNSroboCert 3.25.0 #1101
Comments
Hello @Vertganti ! Indeed I made a change in Lexicon to do a smarter resolution of the actual DNS zone name using requests to DNS servers. Your analysis is correct, there is a timeout when While investigating, I think I should put anyway a way to disable the DNS zone name resolution entirely when it is not needed and creates problem. I still think this should be the default, but this should be a possible opt-out. I will try to work on the issue in the next days. Sorry for the inconvenience. |
Thank you, a config option to opt-out sounds like a good solution. |
FWIW, I see the same issue with TransIP. |
I have what I think is the same issue with OVH, I'm running 3.24.1 and working fine. If I move to anything newer it all goes wrong. Happy to test and proposed fixes, changes, future versions. |
Using a fresh setup of DNSroboCert 3.25.0 on a new host resulted in a DNS operation timeout error. Expand the following block for the full log:
Log
Using the
dig
command fordns.hetzner.com
(we use Hetzner DNS) andacme-v02.api.letsencrypt.org
returned correct results within a few milliseconds both on the host and in the container. We restarted the docker service which also restarted the container, but the issue persisted. Since all our other hosts work perfectly with DNSroboCert 3.24.2 we downgraded to that version which fixed the issue.The issue seems to be in the DNS zone name resolution update. I have looked a bit through the sources and I assume the addition of the
"resolve_zone_name": True
config option to theconfig_dict
passed toConfigResolver().with_dict
causes the error, as it leads to the call ofdns.resolver.zone_for_name
later on. However, I can't find any hint why thednspython
call todns.resolver.zone_for_name
would timeout when normal DNS queries work perfectly.The text was updated successfully, but these errors were encountered: