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

federation: non-federation DNS lookup can return federation CNAME #27969

Closed
nikhiljindal opened this issue Jun 23, 2016 · 3 comments
Closed

federation: non-federation DNS lookup can return federation CNAME #27969

nikhiljindal opened this issue Jun 23, 2016 · 3 comments
Assignees
Labels
area/federation priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/multicluster Categorizes an issue or PR as relevant to SIG Multicluster.

Comments

@nikhiljindal
Copy link
Contributor

nikhiljindal commented Jun 23, 2016

With the current KubeDNS code, it can happen that a pod requests mysvc.somens and resolve.conf adds myns.svc.cluster.local as a search path so that KubeDNS gets mysvc.somns.myns.svc.cluster.local.
If there is a federation with the name myns, isFederationQuery in KubeDNS will think this is a federation query and try to resolve mysvc.somens.svc.cluster.local. If there is a local service resolving to that DNS, then user will get that as expected (all is fine). But if there isnt, then KubeDNS will return mysvc.somens.myns.svc.myzone.myregion.mydomain. If there is no federation service with that name and in that namespace, then user will still get an NXDOMAIN as expected. But if there is, then user might be pointed to a service in another cluster, which user may or may not have wanted.

We can consider this a feature, if users want it or should fix it, if we consider it a bug.

Filing this to keep track.

@kubernetes/sig-cluster-federation

@nikhiljindal
Copy link
Contributor Author

For the record, @quinton-hoole and I had discussed a potential solution which we decided not to do.

The idea was to update kubedns.isFederationQuery() to look for the pattern svcname.nsname.fedname.nsname.svc.domain instead of looking for svcname.nsname.fedname.svc.domain. That will fix the problem, but it doesnt seem logically and syntactically correct to resolve svcname.nsname.fedname.nsname.svc.domain instead of resolving svcname.nsname.fedname.svc.domain. And this solution works only because of the current ordering of search paths in resolve.conf (we first append nsname.svc.domain and then svc.domain). It can break if that order changes.

@ghost ghost added this to the next-candidate milestone Jul 25, 2016
@ghost ghost added the priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. label Aug 19, 2016
@ghost ghost added the priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. label Sep 8, 2017
@ghost
Copy link

ghost commented Sep 8, 2017

I think that we still need to fix this before GA of federation.

@ghost ghost removed the priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. label Sep 8, 2017
@csbell csbell added area/federation sig/multicluster Categorizes an issue or PR as relevant to SIG Multicluster. and removed sig/federation labels Oct 10, 2017
@irfanurrehman
Copy link
Contributor

This issue was labelled only for sig/multicluster and is thus moved over to kubernetes-retired/federation#52.
If this does not seem to be right, please reopen this and notify us @kubernetes/sig-multicluster-misc.
/close

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/federation priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/multicluster Categorizes an issue or PR as relevant to SIG Multicluster.
Projects
None yet
Development

No branches or pull requests

5 participants