BIND9 slave

[George]

Hi,

I am trying to set up a BIND9 slave server.

>From the docs I found on the internet I can see that when you add a
new domain it needs to be added on both slave and master in
named.conf. Is this correct?

Is there a way to make the slave server automatically get and update
any new domains that are added to the master server?

Please advise.

Thanks

[Matthew Pounsett]

On 07-Dec-2009, at 08:37, George wrote:

> Is there a way to make the slave server automatically get and update
> any new domains that are added to the master server?

This question pops up about once every two months on the list. There
are several other discussions on the subject that you could search for
and read.

In short, though: There's nothing in the protocol for doing that, and
BIND does not currently have a proprietary way of doing this.

Previous discussions on the list have covered a number of different
ways of implementing this yourself. Most are pretty simple
descriptions of perl scripts that modify your master sever's
named.conf to work on the slave so that it can be automatically scp'd
over when it's updated. My personal favourite is Paul Vixie's
'federated domains' example, described here:

<https://lists.isc.org/mailman/htdig/bind-users/2008-February/069304.html
>

If you search the list you'll find many, many others.

Matt

[Todd Snyder]

In BIND, no.

There are some solutions discussed (check the archives) around setting
up special zones with the meta data required for the slaves to create
their own slaves, I've even whipped up a POC, but I've not found a
ready-made tool yet.

Your best bet is to script something up. We have a standard format for
our files, so all I do is parse the named.conf from my master, change
"master" to "slave" and add the "masters" line. I then have a script
that pushes the new file out to the slaves and "rndc reconfigs" them.
This works best if you use includes for your zone configuration, keeping
it out of named.conf.

It's pretty trivial for a lab quality deployment, but for production,
I'd look around or develop something a little more robust.

Cheers,

Todd.

-----Original Message-----
From: bind-user...@lists.isc.org
[mailto:bind-user...@lists.isc.org] On Behalf Of George
Sent: Monday, December 07, 2009 8:37 AM
To: bind-...@lists.isc.org
Subject: BIND9 slave

Hi,

I am trying to set up a BIND9 slave server.

>From the docs I found on the internet I can see that when you add a
new domain it needs to be added on both slave and master in
named.conf. Is this correct?

Is there a way to make the slave server automatically get and update

any new domains that are added to the master server?

Please advise.

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

[Kevin Darcy]

George wrote:
> Hi,
>
> I am trying to set up a BIND9 slave server.
>
> >From the docs I found on the internet I can see that when you add a
> new domain it needs to be added on both slave and master in
> named.conf. Is this correct?
>
> Is there a way to make the slave server automatically get and update
> any new domains that are added to the master server?
>
>

There's no way within the DNS protocol, or as a feature of vanilla BIND,
to make this happen.

Folks have devised various ways to automate this. Commercial DNS systems
often have some sort of "push" mechanism, which updates the DNS config
file on remote sytems automatically, using their own proprietary
protocols and subsystems (which are often used for maintaining DHCP
configs as well).

Others mimic this basic approach in their own homegrown systems by
having a central slave config and then replicating it out to all of the
slaves (e.g. using rsync), along with some way to tell each slave to
reload the config when it changes (e.g. rndc).

Or, you can run a script on the slaves which consults some centralized
"zone slaving database" to determine what zones to slave, or to stop
slaving. This "zone slaving database" can take many forms. One idea is
to represent this list as a special zone within DNS itself, containing
just one entry per zone to be slaved. I prefer using PTR records for
this, over, say, TXT records, since PTR records can benefit from label
compression.

How one interprets that special "zone slaving zone" and
populates/modifies/regenerates the named.conf to reflect the slave-zone
definitions at any particular time, is left as an exercise to the
reader. Unfortunately, I can't share any code, since it's all
intellectual property of my employer...

- Kevin

[Chris Thompson]

On Dec 7 2009, Kevin Darcy wrote:

[...snip...]

>Or, you can run a script on the slaves which consults some centralized
>"zone slaving database" to determine what zones to slave, or to stop
>slaving. This "zone slaving database" can take many forms. One idea is
>to represent this list as a special zone within DNS itself, containing
>just one entry per zone to be slaved. I prefer using PTR records for
>this, over, say, TXT records, since PTR records can benefit from label
>compression.

Not to mention that they guarantee correct domain name syntax, and the
absence of duplicates (due to case-insensitivity). Ever since I first
saw you recommend this, I have wondered "why did I ever think TXT records
were the right way to do it?" ...

--
Chris Thompson
Email: ce...@cam.ac.uk

[Kevin Darcy]

Flexibility is both the greatest strength and greatest weakness of TXT
records. We don't use TXT records for *anything* in production, although
we have an LDAP database maintained in parallel with DNS that gets
populated with various forms of textual data. Keeping that stuff in LDAP
makes it a lot more searchable.

- Kevin