Re: DNS caching and forwarding in Cloud Foundry with Consul Agents


Hector Rivas Gandara
 

If you are able to configure consul-release to (a) not rewrite
/etc/resolv.conf and (b) not listen on port 53,
why would you need to specify which recursors consul hits, given that you
would probably never
send it queries outside consul's domain anyways, thus it would never try
any recursing?

Sorry I did not explain myself.

I did not mean that I want to implement all scenarios at the same time. I
meant that consul-release should be flexible enough to allow one to:

* Do not rewrite resolv.conf
* Bind to different port than 53.
* Allow override recursors with a explicit list of nameservers.

With these 3 options, one can implement any scenario without having to fork
consul-release.

I am telling you which minimum features think should be implemented in
consul-release, but that does not mean that somebody will use all these
options together.



On 22 August 2016 at 16:55, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi Hector,

If you are able to configure consul-release to (a) not rewrite
/etc/resolv.conf and (b) not listen on port 53, then I assume you would run
your own thing like bind or dnsmasq there, and only forward specific
queries to the consul agent. In this case, why would you need to specify
which recursors consul hits, given that you would probably never send it
queries outside consul's domain anyways, thus it would never try any
recursing?

Best,
Amit

On Mon, Aug 22, 2016 at 5:21 AM, Hector Rivas Gandara <
hector.rivas.gandara(a)digital.cabinet-office.gov.uk> wrote:

This all sounds great. Sounds like you just want options to (1)
configure
which port Consul DNS binds to, and (2) toggle whether or not it makes
changes to /etc/resolv.conf, at minimum.
Yeah, that would be the minimum required.

Then, I would add:

(3) override the recursors to be used by consul.

With those 3x options, consul can be configured to support any
scenario without having to fork any release.

Is this something you'd want to configure Consul to do, or
would you configure your upstream component like dnsmasq or bind to
only hit
the Consul DNS server port when it receives a query for that search
domain?

Yes, that should be the pattern.

You also mentioned you don't like Consul's recursor behaviour, and want
to
"turn it off". Independently, other people have asked for Consul to be
able
to do more recursing, by being able to provide it a list of IPs to
recurse
to *in addition* to the ones it pulls out of /etc/resolv.conf. So I
see a
few use cases people might have:

(a) make Consul not do any recursing at all, and let the logic live
upstream
(in something like dnsmasq or bind) to try a different server when
Consul
isn't able to resolve an address
(b) doesn't matter at all what Consul recursing does, because you want
to
configure something like dnsmasq to only send queries to Consul when it
matches a certain domain, so no matter how Consul is configured to
recurse,
in practice this would never happen
(c) doesn't matter at all what Consul recursing does, because you want
to
configure Consul itself to only handle queries which match a certain
domain,
so no matter how Consul is configured to recurse, in practice this would
never happen
(d) be able to override the set of recursors Consul uses (instead of
what it
reads out of /etc/resolv.conf), so that you could set it to an empty
array
or whatever you like -- this is one way to generalize use case (a)
(e) be able to add a set of recursors to the ones Consul reads out of
/etc/resolv.conf, because the stuff in /etc/resolv.conf is determined
by the
BOSH Director, and not necessarily something you want to mess with, but
may
be something you want to add to, to get over limitations like "MAXNS 3".
See: https://www.pivotaltracker.com/story/show/121335409

If consul-release makes it possible to change the binding port and
toggle it
not to modify /etc/resolv.conf, then would you say your use cases falls
into
bucket (b)? If so, that's good because it requires fewer additional
changes
and also supports consul-release being able to support use case (e) as
well
at some point, without conflict.
Yes, I think that would be the case.

IMO I think it is enough to allow the cases b and d. That can be done
by implementing the features 1, 2 and 3 mention before.


(e) be able to add a set of recursors to the ones Consul reads out of
/etc/resolv.conf, because the stuff in /etc/resolv.conf is determined
by the
BOSH Director, and not necessarily something you want to mess with, but
may
be something you want to add to, to get over limitations like "MAXNS 3".
See: https://www.pivotaltracker.com/story/show/121335409
Rare case and suboptimal.

Be aware that in the current consul implementation, each recursor will
be queried in round robin, with a hardcoded timeout of 2 seconds. So,
if you have 4x recursors, you query might tike 8s to complete! and
given that the default timeout in linux is 5 seconds with 2x retries,
you will have to override that as well.

As I commented in a previous mail, the consul recursor logic is not
smart at all, compared with other agents like dnsmasq, pdnsd or bind.
If somebody wants to customise and improve the resolution logic, they
should look at those agents, not at consul.

Because that, I don't think it makes sense to put an option of "add
new recursors to the list". Instead limit it to optionally specify the
full list of DNS to be configured as recursors (and empty to disable).
"Add recursors" is a rare case and I think it is OK to have to a
little bit of duplication of defining the DNS nameservers twice.



--
Regards
Hector Rivas | GDS / Multi-Cloud PaaS

--
Regards
Hector Rivas | GDS / Multi-Cloud PaaS

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.