PCS, Corosync, Pacemaker, and Bind

[Mike Bernhardt]

Not sure if this is a BIND question or a PCS/Corosync question, but
hopefully someone has done this before:

I'm setting up a new CentOS 7 DNS server cluster to replace our very old
CentOS 4 cluster. The old one uses heartbeat which is no longer supported,
so I'm now using pcs, corosync, and pacemaker. The new one is running the
latest 9.10.x production release of BIND. I want BIND to listen on, query
from, etc on a particular IP address, which is virtualized. The options
currently used are:
query-source address
listen-on
notify-source

listen-on isn't a big deal, but the source address options are. This worked
fine on the old cluster. But whereas heartbeat would create a virtual
subinterface (i.e. eth0:0) to support the virtual IP, corosync does not do
that; at least it doesn't by default. So although the virtual IP exists and
is pingable, it is not tied to a "physical" interface- ifconfig does not
find it. And when BIND tries to start up, it fails because it can't find the
virtual IP it's configured to run on, even though it is reachable. I only
need IPv4, not IPv6.

So, I'm hoping that either
1) There is a way to tell BIND to use an IP address that is not on an
interface, or
2) There is a way to tell corosync (hopefully using pcsd) to create a
virtual interface, not just a virtual address, so BIND can find it.

Mike Bernhardt

[Tony Finch]

Mike Bernhardt <bern...@bart.gov> wrote:
>
> I'm setting up a new CentOS 7 DNS server cluster to replace our very old
> CentOS 4 cluster. The old one uses heartbeat which is no longer supported,
> so I'm now using pcs, corosync, and pacemaker.

I suggest having a look at keepalived: it's significantly simpler.

> I want BIND to listen on, query from, etc on a particular IP address,
> which is virtualized. The options currently used are:
> query-source address
> listen-on
> notify-source
>
> listen-on isn't a big deal, but the source address options are.

Why do you care about the query source address?

I don't set any of those options and just let BIND pick whatever source
address it wants; it might choose the server admin address or the
advertised service address, and that doesn't matter because everything
else is configured to accommodate this.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Shannon, Rockall: Southeast 4 or 5, increasing 6 at times in Shannon. Moderate
or rough. Fair. Mainly good.

[Phil Mayers]

On 15/03/16 23:06, Mike Bernhardt wrote:

> So, I'm hoping that either
> 1) There is a way to tell BIND to use an IP address that is not on an
> interface, or

I don't think there is.

I can think of all kinds of horrible workarounds - iptables SNAT, shell
script doing a config-change & rndc reconfig on pcs failover.

But in general I'd agree with what Tony Finch said - give some thought
to why you're caring about these source IPs.

TBH having used pcs/corosync I'm really curious what your use-case is.
It seems massive overkill for having highly-available DNS.

[Lightner, Jeff]

You might want to try "ip a" vs ifconfig. RHEL7 uses Network Manager and in the past I've found some things don't show up in ifconfig output when doing alias/virtual interfaces.

Usually even when other products (e.g. Oracle RAC/GRID) create virtual interfaces they still show up as valid interfaces at host level. I've not tried PCS/Corosync.

You might also look at arp output to see if it shows any traffic on a specific MAC.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Phil Mayers]

On 16/03/16 12:48, Lightner, Jeff wrote:
> You might want to try "ip a" vs ifconfig. RHEL7 uses Network
> Manager and in the past I've found some things don't show up in
> ifconfig output when doing alias/virtual interfaces.
>
> Usually even when other products (e.g. Oracle RAC/GRID) create
> virtual interfaces they still show up as valid interfaces at host
> level. I've not tried PCS/Corosync.

That's not how pcs/corosync does it IIRC. They're active on one node
only, usually as secondary IPs on the physical ethernets; dual active
doesn't work properly in that situation anyway due to ARP fighting and
other issues.

OP will need to use a different approach to make bind work in this kind
of setup.

[Mike Bernhardt]

Please confirm that if a DNS query is sent to the virtual address, the reply
will be sourced from the virtual address. The reason for restricting BIND to
a single address was mostly for firewall and administrative simplicity, but
that's not a big deal as long as the same address is used both directions.

The documentation for keepalived isn't very good, but as near as I can tell
it does not support bringing up an application like BIND along with a VRRP
address. Maybe I'm wrong? The cluster.org package works great except for the
lack of an interface, so I've posted over there also to see if it's possible
to build a virtual interface for the IP, but I doubt it.

-----Original Message-----
From: Tony Finch [mailto:d...@dotat.at]
Sent: Tuesday, March 15, 2016 5:40 PM
To: Mike Bernhardt
Cc: bind-...@lists.isc.org
Subject: Re: PCS, Corosync, Pacemaker, and Bind

[Mike Bernhardt]

Another question I have is, how exactly does BIND determine whether the IP
address is valid when setting listen-on or various source options? Although
ifconfig does not show the address, "ip addr" does show it and it is
reachable.

[Tony Finch]

Mike Bernhardt <bern...@bart.gov> wrote:

> Please confirm that if a DNS query is sent to the virtual address, the reply
> will be sourced from the virtual address.

Yes.

(query-source doesn't affect replies.)

> The documentation for keepalived isn't very good, but as near as I can tell
> it does not support bringing up an application like BIND along with a VRRP
> address.

I leave named permanently running on my servers. It listens on the routing
socket so it knows when keepalived changes the interface addresses.
Keepalived runs health checks so it knows when to fail over and which
standby servers are able to take over.

More details at http://fanf.livejournal.com/133294.html

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/

Dover, Wight, Portland, Plymouth: East or northeast 5 to 7, decreasing 4 at
times in shelter. Slight or moderate, occasionally rough later in Plymouth.
Fair. Moderate or good.

[Graham Clinch]

> Please confirm that if a DNS query is sent to the virtual address, the reply

> will be sourced from the virtual address. The reason for restricting BIND to
> a single address was mostly for firewall and administrative simplicity, but
> that's not a big deal as long as the same address is used both directions.

Yes, the correct source address is used (the source of a response is the
destination of the inbound query). However, onward queries that bind
makes on behalf of a client (eg if recursing) will use whatever address
(or presumably query-source/query-source-v6). The default query source
always seems to be the primary address of an interface, as far as I've seen.

> The documentation for keepalived isn't very good, but as near as I can tell
> it does not support bringing up an application like BIND along with a VRRP

> address. Maybe I'm wrong? The cluster.org package works great except for the
> lack of an interface, so I've posted over there also to see if it's possible
> to build a virtual interface for the IP, but I doubt it.

Our recursive servers run keepalived to juggle the two service addresses
that we advertise, and we don't set query-source, listen-on or
notify-source. I don't see any benefit in moving the query/notify
source addresses between hosts, especially since it makes it hard to
test/monitor a host that isn't in service at the moment.

Keepalived calls 'rndc scan' to nudge the already-running named when
addresses appear/disappear, but I think this might be a historical thing
now that bind can watch the routing socket.

Graham

>
> -----Original Message-----
> From: Tony Finch [mailto:d...@dotat.at]
> Sent: Tuesday, March 15, 2016 5:40 PM
> To: Mike Bernhardt
> Cc: bind-...@lists.isc.org
> Subject: Re: PCS, Corosync, Pacemaker, and Bind
>
> Mike Bernhardt <bern...@bart.gov> wrote:
>>
>> I'm setting up a new CentOS 7 DNS server cluster to replace our very
>> old CentOS 4 cluster. The old one uses heartbeat which is no longer
>> supported, so I'm now using pcs, corosync, and pacemaker.
>
> I suggest having a look at keepalived: it's significantly simpler.
>
>> I want BIND to listen on, query from, etc on a particular IP address,
>> which is virtualized. The options currently used are:
>> query-source address
>> listen-on
>> notify-source
>>
>> listen-on isn't a big deal, but the source address options are.
>
> Why do you care about the query source address?
>
> I don't set any of those options and just let BIND pick whatever source
> address it wants; it might choose the server admin address or the advertised
> service address, and that doesn't matter because everything else is
> configured to accommodate this.
>

> Tony.
> --

> f.anthony.n.finch <d...@dotat.at> http://dotat.at/ Shannon, Rockall:
> Southeast 4 or 5, increasing 6 at times in Shannon. Moderate or rough. Fair.
> Mainly good.
>
>

[Mike Bernhardt]

My apologies, never mind :-{

I don't know what the problem was, BIND seems to load up just fine today,
even when the option addresses don't match the virtual address. I must have
screwed up something else.