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
Am 05.01.2016 um 22:03 schrieb Emmett Culley:
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
here: relationship123.com
If I change the zone defs to include the full path:
From
zone "relationships123.com." IN { type master; file "relationships123.com.db"; };
there: relationships123.com.db
Looks to me like a typo in your configuration.
To
zone "relationships123.com." IN { type master; file "/var/named/chroot/var/named/relationships123.com.db"; };
That's not valid for the chrooted named as the path is relative to the chroot dir.
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
Alexander
On 01/05/2016 02:00 PM, Alexander Dalloz wrote:
Am 05.01.2016 um 22:03 schrieb Emmett Culley:
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
here: relationship123.com
??
If I change the zone defs to include the full path:
From
zone "relationships123.com." IN { type master; file "relationships123.com.db"; };
there: relationships123.com.db
??
Looks to me like a typo in your configuration.
To
zone "relationships123.com." IN { type master; file "/var/named/chroot/var/named/relationships123.com.db"; };
That's not valid for the chrooted named as the path is relative to the chroot dir.
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
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.
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?
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
Alexander
Thanks for the reply
Emmett
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
here: relationship123.com
??
If I change the zone defs to include the full path:
From
zone "relationships123.com." IN { type master; file "relationships123.com.db"; };
there: relationships123.com.db
??
A missing "s".
Sylvain CANOINE. Pensez ENVIRONNEMENT : n'imprimer que si ncessaire
Am 06.01.2016 um 00:21 schrieb Emmett Culley:
On 01/05/2016 02:00 PM, Alexander Dalloz wrote:
Am 05.01.2016 um 22:03 schrieb Emmett Culley:
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
here: relationship123.com
??
If I change the zone defs to include the full path:
From
zone "relationships123.com." IN { type master; file "relationships123.com.db"; };
there: relationships123.com.db
??
Showing faked names?
relationship123.com != relationships123.com
Alexander
On 01/06/2016 01:09 PM, Alexander Dalloz wrote:
Am 06.01.2016 um 00:21 schrieb Emmett Culley:
On 01/05/2016 02:00 PM, Alexander Dalloz wrote:
Am 05.01.2016 um 22:03 schrieb Emmett Culley:
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
here: relationship123.com
??
If I change the zone defs to include the full path:
From
zone "relationships123.com." IN { type master; file "relationships123.com.db"; };
there: relationships123.com.db
??
Showing faked names?
relationship123.com != relationships123.com
Alexander
Ah, I was just being lazy.
Emmett
On Jan 5, 2016, at 1:03 PM, Emmett Culley lst_manage@webengineer.com wrote:
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
[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.
On 01/05/2016 03:34 PM, David Nelson wrote:
On Jan 5, 2016, at 1:03 PM, Emmett Culley lst_manage@webengineer.com wrote:
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
[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. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
SELinux is disabled.
On 01/05/2016 01:03 PM, Emmett Culley wrote:
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
I was able to get named to start and resolve DNS requests by creating two named.conf files. One in /etc/named.conf, that contains zone file definitions that included the absolute path to the zone file, like this:
zone "relationships123.com." IN { type master; file "/var/named/chroot/var/named/relationships123.com.db"; };
And another in /var/named/chroot/etc/named.conf that contains zone file definitions with only the zone file name (no path). Like this:
zone "relationships123.com." IN { type master; file "relationships123.com.db"; };
None of this makes sense to me as the previous configuration (that worked before upgrade to 7.2) used symbolic links in /etc to the files in /var/named/chroot/etc. While trying to figure this out I found, from the documentation, that if the named.conf file does not exist in the chroot structure, a copy of the file in /etc is "copied" to be used by the running chrooted server.
Now, after updating to bind 9.9.4-29.el7_2.1 (CentOS 7.2) from bind 9.9.4-29.el7 (CentOS 7.1, latest) I have to use two separate files to get bind to initialize and run.
Any ideas why I seem to be the only one seeing this?
Emmett
-
Alexander Dalloz -
David Nelson -
Emmett Culley -
Sylvain CANOINE