Skip to content
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

memcached dns+ addresses resolve from CNAME #1654

Closed
oneacl opened this issue Apr 7, 2022 · 4 comments · Fixed by #1715
Closed

memcached dns+ addresses resolve from CNAME #1654

oneacl opened this issue Apr 7, 2022 · 4 comments · Fixed by #1715
Labels
bug Something isn't working

Comments

@oneacl
Copy link
Contributor

oneacl commented Apr 7, 2022

Describe the bug

With cortex I could use the memcached addresses dns+memcached.example.com configuration (although the documentation was clearly saying that it has to resolve to A/AAAA so maybe it was an unknown bug?)

This no longer works with mimir.

To Reproduce

Configure mimir with:
bucket_store:
metadata_cache:
backend: memcached
memcached:
addresses: dns+memcached.example.com

where memcached.example.com is a CNAME to someserver.example.com and someserver.example.com IN A 192.0.2.1

The mimir output will return:
name=metadata-cacche msg="failed to resolve addresses for memcached" addresses=dns+memcached.example.com err="2 errors: lookup IP address - invalid A or AAA response record [..] IN CNAME somserver.example.com

Additional Context

Unfortunately due to my infrastructure is deployed I can only have a CNAME for the memcached servers (and no SRV records either).

Would there be a workaround here for me to try?

Thank you.

@pracucci pracucci added the bug Something isn't working label Apr 7, 2022
@pracucci
Copy link
Collaborator

pracucci commented Apr 7, 2022

Thanks for your report!

I did a brief investigation and I've been able to reproduce it. The change has been introduced in #142 where memcached client DNS resolver moved from golang one to miekgdns.

To better understand your use case and properly fix it, could you show me the output of dig memcached.example.com (replacing memcached.example.com with the the actual host and then redacting any sensitive data), please?

@oneacl
Copy link
Contributor Author

oneacl commented Apr 7, 2022

Thanks for the quick reply and also figuring out where it was introduced.

The redacted output looks like this:

;; ANSWER SECTION:
memcached.example.com. 10 IN CNAME cluster-abc.example.com
cluster-abc.example.com. 60 IN A 192.0.2.1
cluster-abc.example.com. 60 IN A 192.0.2.2

In my environment everything except memcached1.example.com is dynamic (including the cluster1.example.com name) - hence I need to use the cname.

I'm also expecting the resolver to obey the TTLs as quite frequently it will change to (along the lines of)

;; ANSWER SECTION:
memcached.example.com 10 IN CNAME cluster-def.example.com
cluster-def.example.com 60 IN A 192.0.2.3
cluster-def.example.com. 60 IN A 192.0.2.4

Thanks again.

@pracucci
Copy link
Collaborator

pracucci commented Apr 7, 2022

Thanks a lot for your reply. I've opened a Thanos PR that should fix it:
thanos-io/thanos#5271

@oneacl
Copy link
Contributor Author

oneacl commented Apr 7, 2022

Thank you too for the prompt fix, really appreciate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants