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
Propagation check failed when using DNS-01 #4624
Comments
Is it an internal site? Do you set 172.18.44.80:53 as dns01-recursive-nameservers? I feel like cert-manager doesn't query DNS to check TXT records. I think Certificate provider does. |
Issues go stale after 90d of inactivity. |
Stale issues rot after 30d of inactivity. |
Hi, sorry it looks like we never had a chance to look at this issue. Is it still an issue? There is some documentation about how to go about debugging ACME failures https://cert-manager.io/docs/faq/acme/ |
@irbekrm true - this issue was related to the networking problems that we had. Closing :-) |
@wolfedale do you mind sharing the solution of it? I am facing the same issue in one of my eks cluster. The cluster was working fine and for some reason i had to create a cluster, and now i am stuck on this cert issue. Nothing has been changed (networking and other configurations).
|
@wolfedale i m also facing same issue with route53, could you please share the solution ? @evercast-mahesh2021 did u find a solution ? |
@evercast-mahesh2021 @github4sanjay I am too facing the same issue. Do you guys have any solution? |
I think i had to destroy and recreate my eks cluster. |
@MageshSrinivasulu
|
If you are getting this error and using a public Route53 zone, check your VPC Network ACLs if they are blocking incoming port 53. That was what we found. Possible work around using https://cert-manager.io/docs/configuration/acme/dns01/#setting-nameservers-for-dns01-self-check like @github4sanjay mentioned extraArgs:
- --dns01-recursive-nameservers-only
- --dns01-recursive-nameservers=kube-dns.kube-system.svc.cluster.local:53 |
Describe the bug:
Every time when I'm creating new Certificate I'm getting error
E1125 10:20:11.727984 1 sync.go:186] cert-manager/controller/challenges "msg"="propagation check failed" "error"="dial tcp 172.18.44.80:53: i/o timeout" "dnsName"="test.corp.foo.bar" "resource_kind"="Challenge" "resource_name"="foo-bar-f294x-2399323752-3051153670" "resource_namespace"="cert-manager" "resource_version"="v1" "type"="DNS-01"
From what I know networking is working fine, coreDNS too. This is not a fresh k8s cluster, it's a production cluster where I already have multiple services. I'm not sure why cert-manager is trying to access this IP on port 53 and using TCP.
Can I somehow change it to UDP?
Can I disable this check?
How this check is working?
I also noticed that with option:
--dns01-recursive-nameservers-only
it's working fine. I don't see anymore logs about "propagation check", and I see that cert-manager can now generate Certificates.With option:
--dns01-recursive-nameservers-only
I also noticed two new logs entries:I1125 10:43:57.287345 1 controller.go:161] cert-manager/controller/certificates-readiness "msg"="re-queuing item due to optimistic locking on resource" "key"="cert-manager/foo-bar" "error"="Operation cannot be fulfilled on certificates.cert-manager.io \"foo-bar\": the object has been modified; please apply your changes to the latest version and try again"
and:
E1125 10:43:57.300232 1 controller.go:211] cert-manager/controller/challenges "msg"="challenge in work queue no longer exists" "error"="challenge.acme.cert-manager.io \"foo-bar-sptj2-3396776443-943601772\" not found"
After the last one I see that my new certificate is there and it's working correctly. It's not clear from the logs what just happened. Does it mean I need to check webhook logs for the actual status of my Certificate progress? My webhook is able to create and delete (Present/CleanUp) TXT records on the provider.
Expected behaviour:
cert-manager should query my local DNS (using /etc/resolv.conf) to see if TXT record has been created or not.
Steps to reproduce the bug:
Anything else we need to know?:
Environment details::
/kind bug
The text was updated successfully, but these errors were encountered: