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.

Sign up for GitHub

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

Jump to bottom

Chained CNAME resolution fails #321

Closed
armon opened this issue Sep 5, 2014 · 7 comments · Fixed by #862
Closed

Chained CNAME resolution fails #321

armon opened this issue Sep 5, 2014 · 7 comments · Fixed by #862
Labels
type/bug Feature does not function as expected
Milestone
0.5.1

Comments

@armon
Copy link
Member

armon commented Sep 5, 2014

Consul only does a single level of CNAME resolution, but this may not be enough for services like RDS.
@armon armon added the bug label Sep 5, 2014
@noazark
Copy link

noazark commented Sep 25, 2014

This was discussed here: Debugging issue with external service - Google Groups. I believe I'm having the same issue, any updates?

@armon
Copy link
Member Author

armon commented Sep 29, 2014

@noazark It's been tagged, but not yet resolved.

@cwstrommer
Copy link

I was the one who reported the original issue. I haven't had much time to look at the code, but what I tested so far seems to indicated that in func agent/nodeLookup the qType is set to TypeANY instead of TypeA, which causes the DNS lookup to just return the top result.

alouche pushed a commit to alouche/consul that referenced this issue Dec 13, 2014
fix hashicorp#321 (dont break resolve chain: cname->cname->A)
79837b8
@alouche
Copy link

alouche commented Dec 15, 2014

Small explanation to the proposed fix: The problem occurs because only dns.TypeA and TypeAAAA returned records are added to the record list consul builds (cf. https://github.com/hashicorp/consul/blob/master/command/agent/dns.go#L470). Since in a chained cname, the (n-1) records until the A lookup will be CNAME type, the fix only required adding CNAME returned records to the record list.

@begriffs
Copy link

I am also encountering this problem when trying to use an RDS external service. What is the priority on this issue, any plans to incorporate the above fix?

@armon
Copy link
Member Author

armon commented Mar 25, 2015

@begriffs Should be an easy enough fix, we'll try to make sure its in 0.5.1

@begriffs
Copy link

Thanks a lot.

@armon armon modified the milestone: 0.5.1 Apr 9, 2015
@ryanuber ryanuber mentioned this issue Apr 14, 2015
Merged
@armon armon closed this as completed in #862 May 4, 2015
@discordianfish discordianfish mentioned this issue Jun 3, 2015
Closed
duckhan pushed a commit to duckhan/consul that referenced this issue Oct 24, 2021
@lkysow
Merge pull request hashicorp#321 from hashicorp/rename-job
9cc2e9d 
Add -job to filename to match convention
duckhan pushed a commit to duckhan/consul that referenced this issue Oct 24, 2021
@ishustava
Connect: only look for service account secrets when creating/updating…
9a19fe9 
… auth method (hashicorp#321)

Kubernetes service account could have multiple secrets associated with it.
Previously, we were only looking at the first secret in the list and using
that secret to create or update the auth method in Consul.
However, on some platforms (Openshift) the service account may contain other types of secrets.
Specifically, in the case of Openshift, there are two secrets: one for the service account token
and the other for docker credentials. This second secret gets injected automatically by Openshift.
This changes our implementation to use the first secret of type kubernetes.io/service-account-token.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type/bug Feature does not function as expected
Projects
None yet
Milestone
0.5.1
Development

Successfully merging a pull request may close this issue.

Return all CNAME's during service DNS resolution hashicorp/consul
5 participants
@alouche @noazark @armon @begriffs @cwstrommer