feature: handle PTR requests to implement dns reverse lookup #475
Conversation
lalyos
changed the title
lalyos
force-pushed
the
reverse-lookup
branch
from
92bf7d8 to
d021c0b
Compare
|
This is looking great! Would it be possible to support IPv6? Not sure what is involved for that. |
|
Also, I think it would be better to resolve the node into the FQDN including the datacenter, e.g. "foo.node.dc1.consul" |
|
+1 for IPv6 support. |
lalyos
force-pushed
the
reverse-lookup
branch
from
d021c0b to
8f04401
Compare
Actually it involved me reading RFC about ipv6 as i never used it before. But the hardest part was to find an environment to test ipv6. Kudos to digital ocean. To refactor the PR to support ipv6 actually took replacing 5 lines with 2 ;) ( see commit ) The digital ocean test setup/result are documented in this gist |
|
I made the FQDN resolution to include the datacenter name. But it might be useful to be it configurable. @armon does it makes sense? But it should go into a new PR once this got merged. |
|
LGTM! Thanks! |
feature: handle PTR requests to implement dns reverse lookup
|
Love the innovation coming out of both HashiCorp and SequenceIQ. Awesome to see collaboration! |
|
@armon - what do you think of @lalyos' suggestion to make this configurable? This feature is currently making it hard for us to use Consul DNS, because we use our internal DNS for stuff still. Specifically, we run a service, and it currently registers itself with a home-grown service discovery system. As part of that, it takes the IP address of the host VM, does a reverse lookup, and uses that domain name to register itself. When I enabled Consul as the default DNS resolver, the service started registering itself like "deals.domain.net.node.flex.consul". This is correct as this feature is defined (nodename matches, "flex" is the datacenter name, etc), but this address is not addressable by services that don't yet have Consul running. Since we need to roll out Consul in stages, we need some way to have the reverse lookup configurable so that on specific nodes it just uses the recursor DNS servers to do the reverse lookup. |
|
@robreinhold It's probably easier to just generate the redundant entries in the home grown system so that the reverse lookup works. If we need to start adding hacks into Consul to support homegrown semantics, the project will suffer overall. It's easier to have those hacks live within the organizations that need them rather than affect the project with a much broader impact. |
|
Thanks for the reply, @armon. I think I may have cluttered up my point talking about our internal service discovery. Maybe a better way to say it is that, when doing a reverse lookup on an IP that happens to have a Consul agent running on it, we were not expecting to get back a Consul address, we were expecting to get back the DNS address that our upstream recursors would return. What I'm proposing is a config value like: The way it works right now, Consul is basically clobbering a reverse lookup of the local IP on VMs/servers that have Consul agents setup as the DNS resolver. This was not what I expected, and it breaks name resolution for anybody consuming the Consul name (node.dc.consul) that doesn't yet have Consul configured as their resolver. So this would work great on a distributed system that's not using DNS names yet, or where IPs are used exclusively, but would be very difficult for us to adopt. I'm willing to do the dev work and get you a pull request, I was just wondering how it would be received. Any chance this config option would be looked at and potentially merged? |
|
I am having a similar problem as @robreinhold but for me its happening with Mesos instances on AWS. I need the reverse lookup for the master and slave instances to go to the AWS internal FQDN not Consul. I suspect this would be a problem for any of the servers that figure out their hostname via their IP address (personally I think this is bad, but so many services in the Hadoop ecosystem do this) Is there a way to disable the reverse lookup with a config? |
|
I have come up with a limited work-around for my particular case where I only need to do reverse lookups of the machine the process is on: Add an entry in /etc/hosts for the internal address and the internal FQDN Still would be nice to have a way to disable or to blacklist nodes that shouldn't have reverse lookup |
) * Add Consul Enterprise Namespace support to endpoints controller - In order to support Consul namespaces, the controller now accepts values namespacesEnabled, consulDestinationNamespace, mirroringEnabled and mirroringPrefix which determine which Consul namespace a service and its proxy should be registered when created. This behavior is fairly straightforward when registering an endpoint but is a little trickier when de-registration is concerned. During de-registration, as we use a consul agent, we need to iterate through the list of all the namespaces in Consul that we register services against and create a Client that targets that namespace and agent to find services registered against the agent in a given namespace. - Additional changes here require creating the ACL auth-method in the default namespace if namespace mirroring is configured and but in the destination namespace otherwise. This also requires us to explicitly specify the destination namespace of the service in order to query the agent for the service being available accurately. - Update the log format of the endpoints controller to be less verbose
Some environment needs reverse dns lookups.
For example when
node1.node.consulresolves to172.17.0.1then1.0.17.172.in-addr.arpaexpected to resolvenode1.node.consul