dns and bind and consul

1,107 views
Skip to first unread message

Greg Fausak

unread,
May 18, 2017, 5:53:43 PM5/18/17
to Consul
I have a question about bind and getting things to work with consul.  I have a rather complicated dns ecosystem where I am trying to use consul. I have set up two consul datacenters as a proof of concept.  Each of the data centers have 3 server nodes. In each data center I've create a service called consul-ui with a unique ip address per data center.  Also in each data center I have set up a single consul agent which is doing dns on port 53.  I can do a dig against those two consul dns servers and I get back appropriate answers for the services I set up. Great!

Each of my data centers also has dns (bind 9.9, zone files, authoritative for a bunch of sub-domains). fairly typical setup, a NS declaration, a glue record, and a zone declaration, and the zone works.

I have configured by consul dns servers to be in a sub-domain of my data center zones.  for example.  dc1.example.com and dc2.example.com are delegating dns service to consul.dc1.example.com and consul.dc2.example.com respectively.  I have experimented with a variety of techniques.  Starting with the published 'forward' technique and also I have tried stub, static-stub, and basic glue record delegation.  None of this has yielded satisfactory name server.  After some debugging I have found the reason why, I can't really figure out any way to get around it.

Usually, when a zone is delegated, the target name server is queried for its SOA and NS records (and ultimately the A records for the NS records). Consul is responding with an SOA record, but, it doesn't respond with a NS record for the domain, so, the domain cannot be delegated.

That appears to be a show stopper for me.

I can hack it to work.  But, I really need to be able to delegate.

Is there anything I can do to get delegation to work? The bottom line is the upstream bind mechanism does a query for consul.dc1.example.com, and since it does not respond with NS records, upstream drops it.

I've seen some talk about using templates to write zone files.  Are there any examples for that?  Is there any way to inject NS and A records for the SOA?

-g

John Dyer

unread,
May 19, 2017, 7:24:23 AM5/19/17
to Consul
So we use unbound as transparent dns proxy on each host using consul for discovery. Our local resolver the points to local unbound which points to our internal dns servers as upstream. This allows us to direct relavent records through a local stub zone which points to the consul resolver. It's not perfect but it's suited our purposes nicely. I'd put this somewhere on the scale between "perfect" and "hack" :)

Michael Leow

unread,
May 19, 2017, 12:37:13 PM5/19/17
to Consul
You probably want to encourage the Hashicorp folks (or submit your PR-fix) to fix the issue tracked at:
https://github.com/hashicorp/consul/issues/1301

Greg Fausak

unread,
May 20, 2017, 8:33:20 AM5/20/17
to Consul
I am currently looking at using unbound as a work around.  Instead of modifying each host I need to be able to do this at the dns server, so, I will be implementing a authoritative dns server with consul forwarding in unbound.  It looks almost "perfect" (it looks to me like unbound doesn't support cnames... there is always something :-) ).   The simplicity is awesome. -g

Greg Fausak

unread,
May 20, 2017, 8:35:20 AM5/20/17
to Consul
I commented on the issue.  It would be nice if you could just hook in the consul sub-domain as a delegated name service.  I would consider a fix, but, I don't know 'go' (yet).

-g

Frank Schröder

unread,
Aug 8, 2017, 8:05:29 AM8/8/17
to Consul
We've provided a patch in https://github.com/hashicorp/consul/pull/3353 which fixes the SOA and NS responses but I'm curious which part of the 'static-stub' setup wasn't working for you. I was able to query for service A records with consul 0.9.0 and a static-stub zone. You can find the test setup in https://github.com/hashicorp/consul/pull/3353#issuecomment-320934137. Please let me know whether I'm misunderstanding something or made a mistake in the setup.

We'd appreciate if you could test the issue_1301 branch and see whether it solves your problem. 

Thx a lot
Frank
Reply all
Reply to author
Forward
0 new messages