Bind Fails To Start After Update From 7.1 To 7.2

Home » CentOS » Bind Fails To Start After Update From 7.1 To 7.2
CentOS 7 Comments

I am seeing these lines for each domain in the systemd journal:

zone relationship123.com/IN: loading from master file relationship123.com.db failed: file not found zone relationship123.com/IN: not loaded due to errors.
_default/relationship123.com./IN: file not found

If I change the zone defs to include the full path:

From

zone “relationships123.com.” IN {
type master;
file “relationships123.com.db”;
};

To

zone “relationships123.com.” IN {
type master;
file “/var/named/chroot/var/named/relationships123.com.db”;
};

in the config file, named starts, but then fails to provide DNS replies with the following error for each request:

general: error: zone relationships123.com/IN: loading from master file /var/named/chroot/var/named/relationships123.com.db failed: file not found general: error: zone relationships123.com/IN: not loaded due to errors.

Nothing was changed in the named configuration prior to updating to 7.2

As usual I am using systemctl start named-chroot to start the server.

Any ideas?

Emmett

7 thoughts on - Bind Fails To Start After Update From 7.1 To 7.2

  • Am 05.01.2016 um 22:03 schrieb Emmett Culley:

    here: relationship123.com

    there: relationships123.com.db

    Looks to me like a typo in your configuration.

    That’s not valid for the chrooted named as the path is relative to the chroot dir.

    Alexander

  • ??

    ??

    Yes, I was aware of that, and I only used an absolute path to see if that would get me past initialization. Which it did.

    However your comment made me think of possibly using /var/named/ to prepend the file name in the zone defs.

    But then got the following for each domain at startup:

    zone relationships123.info/IN: loading from master file /var/named/relationships123.info.db failed: file not found zone relationships123.info/IN: not loaded due to errors.
    _default/relationships123.info./IN: file not found

    Should have said this was sort of expected. I meant only to point out that during initialization the absolute path found the files to load, yet the server couldn’t find them at runtime. I now see that even prepending the path from the /var/named/chroot directory won’t allow initialization.

    I had a similar problem with the slave server after updating to 7.2, It would not start unless I added the absolute path to the broadcast rDNS file. Then just now saw that it also initialized as you see below. I’ll leave it this way as that is less likely to cause a problem, though I am not sure.

    zone “255.in-addr.arpa.” IN {
    type master;
    file “/var/named/named.broadcast”;
    allow-update { none; };
    };

    What changed in bind?

    Thanks for the reply

    Emmett

  • [snip]

    Just a thought — Could it have something to do with bad SELinux context for the file(s) in question? I know those kind of problems can cause errors that make it look like there are missing files or misconfigurations. I haven’t seen how that manifests when it comes to BIND, but it might be worth a look.

  • Am 06.01.2016 um 00:21 schrieb Emmett Culley:

    Showing faked names?

    relationship123.com != relationships123.com

    Alexander