Compiling BIND9 on CentOS 7

[Sean Son]

Hello all

I know I emailed the list about compiling BIND on a SystemD distro earlier last month. This time I have a different question. After I compile BIND9 on CentOS 7 , how do I get it to start up at boot time and how do I restart it? I don't want to have to write a systemd unit configuration file for it. I want it to run using a boot script or some other way that will allow BIND to start up at boot and also allow the system administrator to restart BIND if it ever stops running.

Any help is greatly appreciated and I apologize if this topic is too similar to my previous thread.

Thank you!

Sean

[Anand Buddhdev]

On 25/04/16 17:59, Sean Son wrote:

Hi Sean Son,

> I know I emailed the list about compiling BIND on a SystemD distro earlier
> last month. This time I have a different question. After I compile BIND9 on
> CentOS 7 , how do I get it to start up at boot time and how do I restart
> it? I don't want to have to write a systemd unit configuration file for it.
> I want it to run using a boot script or some other way that will allow BIND
> to start up at boot and also allow the system administrator to restart BIND
> if it ever stops running.

A systemd unit file is the *easiest* and *simplest* way to get BIND to
start at boot. Is there any reason you don't want to use systemd? It's
not difficult at all. You just a few lines in a file to create a system
unit.

If you don't want systemd to restart BIND if it crashes, then you can
just set:

Restart=no

Then, you can start BIND by hand with "systemctl start <unitname>".

Regards,
Anand

[Sean Son]

Thank you for your reply.

The issue is, I do not know what other services/targets will need to be started prior to BIND starting. In other words, I have no idea how to set up the unit file for BIND.

Thanks

[Sean Son]

Reindl

Thank you for your response.  Let me see if what you provided will work with what I am trying to do.

Thanks again!

On Mon, Apr 25, 2016 at 1:36 PM, Reindl Harald <h.re...@thelounge.net> wrote:

Am 25.04.2016 um 19:23 schrieb Sean Son:

Thank you for your reply.

The issue is, I do not know what other services/targets will need to be
started prior to BIND starting. In other words, I have no idea how to
set up the unit file for BIND.

none - just none

and even if - how would a blind script at startup solve that question - if it don't (and it really don't) what's your exactly problem?
_______________________________________________

[Unit]
Description=DNS Server

[Service]
Type=simple
ExecStart=/usr/sbin/named -f -u named
ExecReload=/usr/bin/kill -HUP $MAINPID
ExecStop=/usr/bin/kill -TERM $MAINPID
Restart=always
RestartSec=1

[Install]
WantedBy=multi-user.target
_______________________________________________

[Carl Byington]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, 2016-04-25 at 13:54 -0400, Sean Son wrote:
> Reindl

> Thank you for your response. Let me see if what you provided will
> work
> with what I am trying to do.

If you are compiling any source code for rpm based distributions like
RedHat, you really want to look at the rpm packaging. RedHat has an rpm
spec file for their older bind on RHEL7/Centos7. I modified that for the
latest bind.

http://www.five-ten-sg.com/mapper/bind

That builds the latest version of Bind from ISC, in a manner compatible
with stock bind installs from the Centos7 distribution. The files are
installed into the same locations.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlcedWkACgkQL6j7milTFsEoRgCfY41g6L65iylYWrZvDA5cYRf1
TmcAmwbSQ1VhpmWSyj7mRGQViIFKpaaC
=M7y/
-----END PGP SIGNATURE-----

[Sean Son]

Thank you for your response. Basically what I am trying to do is migrate the BIND server from a Centos 5.11 machine to a CentOS 7.2 machine.  The BIND on CentOS 5.11 was compiled manually by source and its named.conf file looks very different than what CentOS/Red Hat provides in the RPM package named.conf file. Any tips on how I should go about migrating successfully from the 5.11 machine to the 7.2 machine? 

As for the named.service unit file that Reindl provided, will I need to call upon any RNDC services? I saw that in the named.service file that comes with the RPM/YUM package contains a call to some RNDC service which calls up some generate-rndc-key.sh script.. I am not too sure of what the names of the files are.

Thanks for all of your help!

_______________________________________________
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

[Matthew Pounsett]

On 27 April 2016 at 08:34, Sean Son <linuxmailin...@gmail.com> wrote:

Thank you for your response. Basically what I am trying to do is migrate the BIND server from a Centos 5.11 machine to a CentOS 7.2 machine.  The BIND on CentOS 5.11 was compiled manually by source and its named.conf file looks very different than what CentOS/Red Hat provides in the RPM package named.conf file. Any tips on how I should go about migrating successfully from the 5.11 machine to the 7.2 machine? 

Your best approach is to have a careful look at the named.conf you're migrating from and understand what options are required by your DNS needs, and which are just related to how the Centos 5 machine is organized.  You can then merge the former set (your requirements) into the default config of the Centos 7 machine.

 

As for the named.service unit file that Reindl provided, will I need to call upon any RNDC services? I saw that in the named.service file that comes with the RPM/YUM package contains a call to some RNDC service which calls up some generate-rndc-key.sh script.. I am not too sure of what the names of the files are.

rndc is the command line interface to a running BIND server.  (BIND == berkeley internet name domain, rndc == remote name domain controller (or something to that effect)).  The rndc.conf file must agree with the named.conf file on where BIND's controller interface is (the controls{}; clause in named.conf) and what key to use for authentication, if any.  

For example, named.conf might have something like this:

controls {

    inet 192.0.2.1 port 953 allow { 192.0.2.100; } keys {"rndc-key"; };

};

While your rndc.conf might have:

options {

    default-key "rndc-key";

    default-server 192.0.2.1;

    default-source-address 192.0.2.100;

    default-port 953;

};

It sounds to me like the named.service file you mention is probably generating a default rndc.conf file if one doesn't already exist.  

[Sean Son]

Thank you for your responses guys.  Here is a n00b question: Because this new server will be a slave DNS server, do I have to manually copy the zone files from the current slave DNS server (The CentOS 5.11) one, or does the new server automatically get the zones from the master DNS server?

Thanks again!

On Wed, Apr 27, 2016 at 11:50 AM, Reindl Harald <h.re...@thelounge.net> wrote:

Am 27.04.2016 um 17:45 schrieb Matthew Pounsett:

rndc is the command line interface to a running BIND server.  (BIND ==
berkeley internet name domain, rndc == remote name domain controller (or
something to that effect)).  The rndc.conf file must agree with the
named.conf file on where BIND's controller interface is (the controls{};
clause in named.conf) and what key to use for authentication, if any.

For example, named.conf might have something like this:
controls {
    inet 192.0.2.1 port 953 allow { 192.0.2.100; } keys {"rndc-key"; };
};
While your rndc.conf might have:
options {
    default-key "rndc-key";
    default-server 192.0.2.1;
    default-source-address 192.0.2.100;
    default-port 953;
};

It sounds to me like the named.service file you mention is probably
generating a default rndc.conf file if one doesn't already exist

no it don't and you don't need to setup rndc at all just for start/stop/reload named, systemd knows the PID and so can send a SIGHUP, works like a charme for many year on nameservers hosting hundrets of zones and running with controls { }; since nobody but the maintaining scripts have a business mangle with named and after that issue "systemctl reload"

ExecStart=/usr/sbin/named -4 -f -u named

[Bob Harold]

On Wed, Apr 27, 2016 at 11:52 AM, Sean Son <linuxmailin...@gmail.com> wrote:

Thank you for your responses guys.  Here is a n00b question: Because this new server will be a slave DNS server, do I have to manually copy the zone files from the current slave DNS server (The CentOS 5.11) one, or does the new server automatically get the zones from the master DNS server?

Thanks again!

It is automatic, and if it does not work, something is wrong.  Copying the files will only make it harder to debug.  (Unless you have a lot of files and just want to speed up the process.  But not recommended.)

-- 

Bob Harold

 

On Wed, Apr 27, 2016 at 11:50 AM, Reindl Harald <h.re...@thelounge.net> wrote:

Am 27.04.2016 um 17:45 schrieb Matthew Pounsett:

rndc is the command line interface to a running BIND server.  (BIND ==
berkeley internet name domain, rndc == remote name domain controller (or
something to that effect)).  The rndc.conf file must agree with the
named.conf file on where BIND's controller interface is (the controls{};
clause in named.conf) and what key to use for authentication, if any.

For example, named.conf might have something like this:
controls {
    inet 192.0.2.1 port 953 allow { 192.0.2.100; } keys {"rndc-key"; };
};
While your rndc.conf might have:
options {
    default-key "rndc-key";
    default-server 192.0.2.1;
    default-source-address 192.0.2.100;
    default-port 953;
};

It sounds to me like the named.service file you mention is probably
generating a default rndc.conf file if one doesn't already exist

no it don't and you don't need to setup rndc at all just for start/stop/reload named, systemd knows the PID and so can send a SIGHUP, works like a charme for many year on nameservers hosting hundrets of zones and running with controls { }; since nobody but the maintaining scripts have a business mangle with named and after that issue "systemctl reload"

ExecStart=/usr/sbin/named -4 -f -u named

ExecReload=/usr/bin/kill -HUP $MAINPID
ExecStop=/usr/bin/kill -TERM $MAINPID