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

DNS should be case insensitive #189

Closed
provonet opened this issue Jun 3, 2014 · 9 comments · Fixed by #224
Closed

DNS should be case insensitive #189

provonet opened this issue Jun 3, 2014 · 9 comments · Fixed by #224
Assignees

Comments

@provonet
Copy link

provonet commented Jun 3, 2014

DNS resolving is now case sensitive which makes it impossible to ssh in to a server or container if there is a capital letter in the hostname.

example:

ping postgresql.node.consul
ping: unknown host postgresql.node.consul

but:

ping Postgresql.node.consul
PING Postgresql.node.consul (172.17.0.5) 56(84) bytes of data.
64 bytes from 172.17.0.5: icmp_seq=1 ttl=64 time=0.061 ms
64 bytes from 172.17.0.5: icmp_seq=2 ttl=64 time=0.078 ms

@provonet
Copy link
Author

provonet commented Jun 3, 2014

Forgot to add the used version, we are using version 0.2.1

@andrewwatson
Copy link
Contributor

yikes, DNS is definitely not sensitive per the RFC. 👍

@armon
Copy link
Member

armon commented Jun 6, 2014

So an interesting mis-match we have is that Consul IS case-sensitive for tags + services.
Meaning, if there happens to be a "foo" and "Foo" tag for the "postgresql" service, "foo.postgresql.service.consul" and "Foo.postgresql.service.consul" actually resolve differently.

I'm not sure how to handle case-insensitive DNS without creating an ambiguity in the lookup.

@armon
Copy link
Member

armon commented Jun 6, 2014

Similarly the "postgresql" and "POSTGRESQL" service are allowed to be distinct

@carlosdp
Copy link

carlosdp commented Jun 9, 2014

What is the use-case for having two tags/services of the same name with different casing?

@armon
Copy link
Member

armon commented Jun 10, 2014

No good use case. On thinking about this further, Consul does not currently definite case sensitivity, so we wouldn't be breaking a backwards compatibility promise. Instead, we can define case-insensitive and both fix this bug and have more clearly defined semantics. This may not happen for 0.3 but maybe 0.4

@tiwilliam
Copy link
Contributor

I had a look at this yesterday and got all interfaces case-insensitive, still need some refactoring but I'm working on this.

@tiwilliam tiwilliam self-assigned this Jun 12, 2014
@armon
Copy link
Member

armon commented Jun 12, 2014

@tiwilliam Awesome. I'd love to talk more about this while you are working on it. I think that largely we can do this all in the state store by just doing a ToLower on all the indexes and corresponding read values. I think most of the changes can actually be localized to the MDBTable

@tiwilliam
Copy link
Contributor

Yeah, that's basically what I have, and then ToLower in DNSServer.dispatch etc. I did the ToLower on one level above the MDBTable when storing, but I can try to move it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants