-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
query: Error with "dnssrv+" service discovery with intermediate CNAME #5679
Comments
Thanks for the detailed report @Tassatux! This sounds like a reasonable request to me. Are you happy to take this or shall I open this for others to work on? 🙂 |
I'm not sure how to properly fix it, so I prefer that someone with more Go knowledge take a look. 🙂 |
Can I work on this one?? |
Sure @h20220025 go for it 🚀 |
Are you still on it @h20220025 ? |
Hello👋 I'd like to work on this issue :) |
Hey @Atharva-Shinde I'd say go for it 🚀, maybe @h20220025 didn't get a chance to pick this up after all 🙃 |
Thanos, Prometheus and Golang version used:
thanos:v0.28.0
What happened:
When Thanos query is deployed in a Kubernetes cluster with coredns configured to avoid superfluous DNS requests (with
autopath @kubernetes
andpods verified
), a CNAME may be returned to the DNS query resulting in a error in storeAPIs addresses resolution.This happen when using "relative" DNS name
service.namespace
, without the full cluster DNS domain.StoreAPI endpoint is properly discovered on Thanos query start, but few seconds later the resolution fail, removing the endpoint.
It look like it's because only SRV type in response are handled in https://github.com/thanos-io/thanos/blob/v0.28.0/pkg/discovery/dns/miekgdns/resolver.go#L37
What you expected to happen:
The CNAME should be followed to get the real SRV value.
How to reproduce it (as minimally and precisely as possible):
Update Kubernetes coredns config to include both
autopath @kubernetes
andpods verified
:Restart coredns pods then deploy following manifests:
Full logs to relevant components:
Query logs:
Anything else we need to know:
Without
autopath @kubernetes
andpods verified
:tcpdump:
With
autopath @kubernetes
andpods verified
:tcpdump:
I saw that a way to follow CNAME was added previously in
LookupIPAddr
function via #5271Could we get the same for SRV?
Thanks.
The text was updated successfully, but these errors were encountered: