Add support for '--address' in ConsulDNS like dnsmasq have

[sielaq]

Hello,

There is a nice functionality of dnsmasq (--address) that
force an IP address for specific domain like:

--address=/consul/10.20.30.40

so A record is resolved as 10.20.30.40
and SRV stays as it was.

I'm not sure if this is a part of functionality which exists already (done by #570).
if yes then - what is needed is a possibility to add "wild card" like all *.service.consul.

A record is needed for humans 😄 like HAproxy+browser
Missing this stuff forcing us to use still dnsmasq just for this small feature.
I would love to use consul only 😄

If this is already possible please correct me 😄

[armon]

I'm not entirely sure I understand. You want to hardcode the response for services?

[sielaq]

yes - but only A record response - thats a trick.

[sielaq]

so A record will point to IP of HAproxy. HAproxy will do the rest.
So human can access via browser
foo.service.consul/docs
which is swagger.io service documentation

[armon]

I think its easier to register "foo-docs.service.consul" as an external service. Otherwise we'd have some very specialized logic for hardcoding in this one scenario. I don't see this as a common use case we'd support.

[sielaq]

just to make it clear, how it works, because we do not change SRV answers,
so there is no change for consul behavior:

# host -t A -v foo.service.consul
Trying "foo.service.consul"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44088
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;foo.service.consul.                IN      A

;; ANSWER SECTION:
foo.service.consul. 0       IN      A       10.44.211.37

Received 56 bytes from 10.44.211.37#53 in 0 ms


# host -t SRV -v  foo.service.consul
Trying "foo.service.consul"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6659
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;foo.service.consul.                IN      SRV

;; ANSWER SECTION:
foo.service.consul. 0       IN      SRV     1 1 31001 paas44-1.node.integra_211.consul.
foo.service.consul. 0       IN      SRV     1 1 31000 paas44-2.node.integra_211.consul.
foo.service.consul. 0       IN      SRV     1 1 31002 paas44-1.node.integra_211.consul.

;; ADDITIONAL SECTION:
paas44-1.node.integra_211.consul. 0 IN A     10.44.211.128
paas44-2.node.integra_211.consul. 0 IN A     10.44.211.129
paas44-1.node.integra_211.consul. 0 IN A     10.44.211.128

Received 424 bytes from 10.44.211.37#53 in 2 ms

[sielaq]

I think its easier to register "foo-docs.service.consul" as an external service

registering an external service is easy, but it require twice more work to keep up to date from consul-template side and according to our developers there is "an inconsistence in naming convention".

I know, our developers have very sophisticated requirements :)
Its hard for me too :) But I thought, it is a common use case, that also humans use consul (in-directly, via HAproxy - since browsers do not support SRV 😄 )

I thought also that this doesn't change any logic of consul
it just "mask" the A record answer.

[armon]

The problem is that many (most) Consul deployments actually do depend on the A records. So in this way, it's a pretty major change. Effectively it would suppress the normal serving and filtering logic to return a hard coded result.

I think this can be better solved outside of Consul. If you guys are using consul-template, then you can always setup a specific /docs path handler to go to a hardcoded route in the KV store.

[sielaq]

Yea we solve it outside with dnsmasq which was the easiest method I suppose.

Can you elaborate little bit the solution you proposed ? I still don't get it, how end-user using browser gonna get HAproxy IP, when consul is his main DNS , knowing only service name?

EDIT:
might be also that I made mistake here telling that "--address" is changing A record - actually is just resolving address with specific IP when no type query specified.
'A record' stays as it is when it comes to SRV query. I'm confused now, but you probably got the idea.

this is same output from dig, when dnsmasq is in front with --adddress=/consul/10.44.211.37

# dig foo.service.consul SRV | grep -v '^;'
foo.service.consul. 0       IN      SRV     1 1 31001 paas44-1.node.integra_211.consul.
foo.service.consul. 0       IN      SRV     1 1 31002 paas44-2.node.integra_211.consul.
foo.service.consul. 0       IN      SRV     1 1 31000 paas44-1.node.integra_211.consul.

paas44-1.node.integra_211.consul. 0 IN A     10.44.211.128
paas44-2.node.integra_211.consul. 0 IN A     10.44.211.129
paas44-1.node.integra_211.consul. 0 IN A     10.44.211.128

# dig foo.service.consul  | grep -v '^;'
foo.service.consul. 0       IN      A       10.44.211.37

[armon]

Sorry that was unclear, my solution requires a layer of indirection being used, such that you can do HTTP path based routing. A reverse proxy of some sort. If you are using Consul directly my suggestion will not work. In that case either the DNSMasq trick or external services solution makes more sense.

[sielaq]

thx @armon, you can close ticket.

out of topic:
You have mentioned that

The problem is that many (most) Consul deployments actually do depend on the A records.

Might be, that we are doing something wrong here, thats why ask for more details :), so sorry for being so picky. Can you just tell me how only A record is being used for Consul deployments? I thought that only SRV is needed since it contains a important couple of real IP and PORT?

[armon]

@sielaq Most deployments depend on well-known ports, so the port is hardcoded and the A record is used for IP discovery. Hope that helps!