Re: bind-chroot is not re-positioning my forward and reverse tables
On 7/1/21 9:10 AM, Petr Menšík wrote:
Hi,
On 6/30/21 5:11 AM, ToddAndMargo via bind-users wrote:
On 6/27/21 4:01 PM, Reindl Harald wrote:
seriosly i am beginning to wonder if you should simply give up bind-chroot
Never quit! :-)
Is is not a bad idea. If you are running SELinux in enforcing mode,
I do, but there are extenuating circumstances. I will explain in a bit.
it
already limits named service in more restrictive way than bind-chroot. I
think there is no real advantage running bind-chroot, just more
configuration quirks required. Please try to use SELinux if possible.
When it is enforcing, I think named.service is just fine. No chroot is
needed for additional security.
Hi Petr,
The reason I am running bind-chroot is because I want
my machine to emulate what I have at my customers.
And I have a customer with a $$ piece of software
that despises SELinux and the vendor won't fix it.
It is one of those pieces of software where they stitch
together other pieces of software like legos and then
charge out the nose for it. There is not a lot of
original content. So I run named-chroot on his server
(and mine too).
it's not the job of the chroot bind-mount setup to mount each and
every file and 'file "abc.hosts.rev"' without any path makes no sense
just write your files where they are expected from the viewpoint of
the chroot and ignore "/var/named/chroot" in your configs because it
simply
don't exist from the viewpoint of the process running inside the chroot
anyways, that's not a bind topic at all
Odd, I would have thought that bind-chroot was part of the bind project.
Anyway, I figured it out. I will post it in another reply
No- bind-chroot is a Red Hat provided helper to chroot ability of BIND
to setup chroot easy way. Only smaller part of configuration is specific
to BIND project itself. Larger part of bind-chroot scripts belongs to
Fedora or RHEL, because chroot setup is implementation provided by
Fedora project package, not by any of ISC releases.
Is there a specific support site for bind-chroot?
I think your attempts fail, because setup script
/usr/libexec/setup-named-chroot.sh tests, whether destination directory
is empty.
That means, /var/named would be mounted to /var/named/chroot/var/named
only when /var/named/chroot/var/named directory is empty. It is mounted
on named-chroot-setup.service, started before named-chroot.service. That
means you have to move your backups out of that directory, not only to
different filenames anywhere under that directory. If there are files,
that copies are used instead. It should be reasony why it cannot find
your zone data.
Move it out of chroot as a backup, when bind-chroot.service is stopped.
# mkdir -p /var/named/backup-chroot/var/named
# mv /var/named/chroot/var/named/* /var/named/backup-chroot/var/named
# systemctl restart bind-chroot
# ls -l /var/named/{,chroot/var/named} # check files are the same
Cheers,
Petr
Did you see my other thread in this post? I wrote down
the exact method I used to fix things. You were close,
by the way. I got my ass handed to me in step 2,
which is where all my issues were. Fortunately
they were all easy to fix (all four of them).
If you can't find it, I will send it to you directly.
It is a nice blue print to follow when (re)installing
bind-chroot.
The moral of the story is that is has to work with
regular bind before switching to bind-chroot. No
skirting the problem in regular bind by directly
writing into the chroot, which is were I got into
deep doodoo.
Thank you for all the help on this and my other posting
(in other places) with bind-chroot! Dang you are
good at this stuff! (No getting the big head.)
-T
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-chroot is not re-positioning my forward and reverse tables
On 6/24/21 9:00 PM, ToddAndMargo via bind-users wrote:
Hi All,
Fedora 34
bind-chroot-9.16.16-1.fc34.x86_64
I am trying to clean up my bind-chroot forward and reverse files.
The goal is to have bind-chroot do its thing by duplicating these two
files over into
/var/named/chroot/var/named/slaves/
with the identical inodes like it does with named.root and named.root.key:
# stat /etc/named.root.key /var/named/chroot/etc/named.root.key
...
File: /etc/named.root.key
Inode: 60033354
...
File: /var/named/chroot/etc/named.root.key
...
Inode: 60033354
In my /etc/named.conf, I have
zone "abc.local" {
type master;
# file "/var/named/chroot/var/named/slaves/abc.hosts";
file "slaves/abc.hosts";
allow-update { key DHCP_UPDATER; };
};
zone "255.168.192.in-addr.arpa" {
type master;
# file "/var/named/chroot/var/named/slaves/abc.hosts.rev";
file "slaves/abc.hosts.rev";
allow-update { key DHCP_UPDATER; };
};
After I stopped
# systemctl start named-chroot
I copied and moved the following:
Before:
# find /var/named/ -iname abc.hosts\*
/var/named/chroot/var/named/slaves/abc.hosts.000
/var/named/chroot/var/named/slaves/abc.hosts.rev.000
# cp /var/named/chroot/var/named/slaves/abc.hosts
/var/named/chroot/var/named/slaves/abc.hosts.000
# mv /var/named/chroot/var/named/slaves/abc.hosts .
# cp /var/named/chroot/var/named/slaves/abc.hosts.rev
/var/named/chroot/var/named/slaves/abc.hosts.rev.000
# mv /var/named/chroot/var/named/slaves/abc.hosts.rev .
# find /var/named/ -iname abc.hosts*
After:
# find /var/named/ -iname abc.hosts\*
/var/named/slaves/abc.hosts.rev
/var/named/slaves/abc.hosts
/var/named/chroot/var/named/slaves/abc.hosts.000
/var/named/chroot/var/named/slaves/abc.hosts.rev.000
But when I restarted named-chroot, my great plans got dashed:
# systemctl start named-chroot
...
Jun 24 20:35:45 rn6.abc.local bash[83464]: zone abc.local/IN:
loading from master file /slaves/abc.hosts faile>
Jun 24 20:35:45 rn6.abc.local bash[83464]: zone abc.local/IN: not
loaded due to errors.
Jun 24 20:35:45 rn6.abc.local bash[83464]: _default/abc.local/IN:
file not found
Jun 24 20:35:45 rn6.abc.local bash[83464]: zone
255.168.192.in-addr.arpa/IN: loading from master file /slaves/abc.host>
Jun 24 20:35:45 rn6.abc.local bash[83464]: zone
255.168.192.in-addr.arpa/IN: not loaded due to errors.
Jun 24 20:35:45 rn6.abc.local bash[83464]:
_default/255.168.192.in-addr.arpa/IN: file not found
Jun 24 20:35:45 rn6.abc.local bash[83464]: zone
0.0.127.in-addr.arpa/IN: loaded serial 1997022700
named-chroot can't find abc.hosts or abc.hosts.rev in
/var/named/chroot/var/named/slaves
And in case they got copied to somewhere else I did another find:
# find /var/named/ -iname abc.hosts\*
/var/named/slaves/abc.hosts.rev
/var/named/slaves/abc.hosts
/var/named/chroot/var/named/slaves/abc.hosts.000
/var/named/chroot/var/named/slaves/abc.hosts.rev.000
No change.
What am I missing?
Many thanks,
-T
Along with some excellent help for Ed over on the
Fedora mailing list, I did get it figured out.
I got my ass handed to me on step 2.
Here are my notes:
-T
bind-chroot: how to start over clean:
On 6/27/21 5:34 PM, Ed Greshko wrote (with additions from T):
0) backup your zone tables (3+), named.config,
named.root.key, named.local files
1) stop named-chroot,
# systemctl stopnamed-chroot.service
Verify it is dead:
# systemctl status named-chroot.service
2) start the named server
# systemctl start named.service
make sure it doesn't produced errors. Fix any you do find
To check errors:
# systemctl statusnamed.service
3) If that check ok, then stop named.
# systemctl stopnamed.service
4) Then do
Remove:
# rpm -e --nodeps bind-chroot
# rm -rf /var/named/chroot
Reinstall:
# dnf install bind-chroot
# systemctl enable named-chroot.service
5) Then, without moving any files or doing anything, start named-chroot
# systemctl start named-chroot.service
6) double check your mount --bind's
# stat /etc/named.root.key | grepInode | awk '{print $3 " " $4}'
Inode: 60033354
# stat /var/named/chroot/etc/named.root.key | grepInode | awk
'{print $3 " " $4}'
Inode: 60033354
# stat /etc/named.conf | grepInode | awk '{print $3 " " $4}'
Inode: 27396278
# stat /var/named/chroot/etc/named.conf | grepInode | awk
'{print $3 " " $4}'
Inode: 27396278
# stat /var/named/named.local | grepInode | awk '{print $3 " " $4}'
Inode: 20186605
# stat /var/named/chroot/var/named/named.local | g
Re: bind-chroot is not re-positioning my forward and reverse tables
On 6/27/21 4:01 PM, Reindl Harald wrote: seriosly i am beginning to wonder if you should simply give up bind-chroot Never quit! :-) it's not the job of the chroot bind-mount setup to mount each and every file and 'file "abc.hosts.rev"' without any path makes no sense just write your files where they are expected from the viewpoint of the chroot and ignore "/var/named/chroot" in your configs because it simply don't exist from the viewpoint of the process running inside the chroot anyways, that's not a bind topic at all Odd, I would have thought that bind-chroot was part of the bind project. Anyway, I figured it out. I will post it in another reply ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-chroot is not re-positioning my forward and reverse tables
On 6/27/21 3:40 PM, ToddAndMargo via bind-users wrote:
On 6/26/21 7:31 PM, ToddAndMargo via bind-users wrote:
On 6/24/21 9:00 PM, ToddAndMargo via bind-users wrote:
The goal is to have bind-chroot do its thing
mount --bind
https://bugzilla.redhat.com/show_bug.cgi?id=1972022#c3
It is not occurring on my zone files. Is it suppose to?
I have moved my zone fines to /var/named
Mount bind still does not get them. I had to
manually copy them over.
zone "abc.local" {
type master;
# file "/var/named/chroot/var/named/abc.hosts";
file "abc.hosts";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
zone "255.168.192.in-addr.arpa" {
type master;
# file "/var/named/chroot/var/named/abc.hosts.rev";
file "abc.hosts.rev";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
I am beginning to wonder if mount bind does not
mount bind your zone files, only /etc/named.conf and
named.root.key
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-chroot is not re-positioning my forward and reverse tables
On 6/26/21 7:31 PM, ToddAndMargo via bind-users wrote:
On 6/24/21 9:00 PM, ToddAndMargo via bind-users wrote:
The goal is to have bind-chroot do its thing
mount --bind
https://bugzilla.redhat.com/show_bug.cgi?id=1972022#c3
It is not occurring on my zone files. Is it suppose to?
I have moved my zone fines to /var/named
Mount bind still does not get them. I had to
manually copy them over.
zone "abc.local" {
type master;
# file "/var/named/chroot/var/named/abc.hosts";
file "abc.hosts";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
zone "255.168.192.in-addr.arpa" {
type master;
# file "/var/named/chroot/var/named/abc.hosts.rev";
file "abc.hosts.rev";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-chroot is not re-positioning my forward and reverse tables
On 6/24/21 9:00 PM, ToddAndMargo via bind-users wrote: The goal is to have bind-chroot do its thing mount --bind https://bugzilla.redhat.com/show_bug.cgi?id=1972022#c3 It is not occurring on my zone files. Is it suppose to? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind-chroot is not re-positioning my forward and reverse tables
Hi All,
Fedora 34
bind-chroot-9.16.16-1.fc34.x86_64
I am trying to clean up my bind-chroot forward and reverse files.
The goal is to have bind-chroot do its thing by duplicating these two
files over into
/var/named/chroot/var/named/slaves/
with the identical inodes like it does with named.root and named.root.key:
# stat /etc/named.root.key /var/named/chroot/etc/named.root.key
...
File: /etc/named.root.key
Inode: 60033354
...
File: /var/named/chroot/etc/named.root.key
...
Inode: 60033354
In my /etc/named.conf, I have
zone "abc.local" {
type master;
# file "/var/named/chroot/var/named/slaves/abc.hosts";
file "slaves/abc.hosts";
allow-update { key DHCP_UPDATER; };
};
zone "255.168.192.in-addr.arpa" {
type master;
# file "/var/named/chroot/var/named/slaves/abc.hosts.rev";
file "slaves/abc.hosts.rev";
allow-update { key DHCP_UPDATER; };
};
After I stopped
# systemctl start named-chroot
I copied and moved the following:
Before:
# find /var/named/ -iname abc.hosts\*
/var/named/chroot/var/named/slaves/abc.hosts.000
/var/named/chroot/var/named/slaves/abc.hosts.rev.000
# cp /var/named/chroot/var/named/slaves/abc.hosts
/var/named/chroot/var/named/slaves/abc.hosts.000
# mv /var/named/chroot/var/named/slaves/abc.hosts .
# cp /var/named/chroot/var/named/slaves/abc.hosts.rev
/var/named/chroot/var/named/slaves/abc.hosts.rev.000
# mv /var/named/chroot/var/named/slaves/abc.hosts.rev .
# find /var/named/ -iname abc.hosts*
After:
# find /var/named/ -iname abc.hosts\*
/var/named/slaves/abc.hosts.rev
/var/named/slaves/abc.hosts
/var/named/chroot/var/named/slaves/abc.hosts.000
/var/named/chroot/var/named/slaves/abc.hosts.rev.000
But when I restarted named-chroot, my great plans got dashed:
# systemctl start named-chroot
...
Jun 24 20:35:45 rn6.abc.local bash[83464]: zone abc.local/IN:
loading from master file /slaves/abc.hosts faile>
Jun 24 20:35:45 rn6.abc.local bash[83464]: zone abc.local/IN: not
loaded due to errors.
Jun 24 20:35:45 rn6.abc.local bash[83464]: _default/abc.local/IN:
file not found
Jun 24 20:35:45 rn6.abc.local bash[83464]: zone
255.168.192.in-addr.arpa/IN: loading from master file /slaves/abc.host>
Jun 24 20:35:45 rn6.abc.local bash[83464]: zone
255.168.192.in-addr.arpa/IN: not loaded due to errors.
Jun 24 20:35:45 rn6.abc.local bash[83464]:
_default/255.168.192.in-addr.arpa/IN: file not found
Jun 24 20:35:45 rn6.abc.local bash[83464]: zone
0.0.127.in-addr.arpa/IN: loaded serial 1997022700
named-chroot can't find abc.hosts or abc.hosts.rev in
/var/named/chroot/var/named/slaves
And in case they got copied to somewhere else I did another find:
# find /var/named/ -iname abc.hosts\*
/var/named/slaves/abc.hosts.rev
/var/named/slaves/abc.hosts
/var/named/chroot/var/named/slaves/abc.hosts.000
/var/named/chroot/var/named/slaves/abc.hosts.rev.000
No change.
What am I missing?
Many thanks,
-T
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/17/21 3:12 AM, Reindl Harald wrote: however, in the real world just write "sudo command" is the best you can do - for the average user it's complete and leaves no questions for power users which don't like sudo it should be no deal-breaker to type the command without "sudo" in a root shell case closed All I have to do is get over hating the sudo command. And I kinda-sorta of expect anyone that uses "bind" (power uses in the extreme -- genius level) to know what # and $ at the prompt means. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/16/21 12:45 PM, Richard T.A. Neal wrote: On 16 June 2021 7:31 pm, ToddAndMargo wrote: Does this alteration at the top make it any clearer? Note: at the command prompt, I use the following terminology: # means run as root $ means run as user Inside a file, "#" mean it is a comment Others might have better suggestions but the way I tend to do this is to simply prefix any commands that must be run as root with 'sudo', eg; $ sudo rndc reconfig $ tail /var/log/syslog Thus it’s hopefully clear which lines need to be run with root privileges and demonstrates using sudo to achieve this. Best, Richard. I have used su for such in the past: $ su root -c "command and parameters" to make it obvious it is a root command. I personally can't stand the sudo command, so I usually avoid it. Lately, I just use # and $, but I can see now where that would cause some confusion. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
A question on logging
Hi All,
In my named.conf
logging {
channel update_debug {
# file
"/var/named/chroot/var/named/slaves/named-update-debug.log";
file "slaves/named-update-debug.log";
severity debug 3;
print-category yes;
print-severity yes;
print-time yes;
};
channel security_info{
file "slaves/named-auth.info";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category update { update_debug; };
category security { security_info; };
};
Questions:
1) is there some pruning of old stuff mechanism to
keep my drive from being over run with logging
data?
2) If I want to comment out the section, is there
a block comment that can be used at the top
and bottom of my logging statement that will
keep me from having to put a # in front of
every line?
Many thanks,
-T
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/16/21 2:16 AM, Reindl Harald wrote: Am 16.06.21 um 09:31 schrieb ToddAndMargo via bind-users: ... # means root $ means user ... Sometimes, in your configuration file extracts, you use '#' meaning 'this line is a comment'. I guess this is a write-up for a novice. The non-novices here have overlooked it, but I'm much closer to the novice end of the BIND user spectrum than they are and If I were a *complete* novice, I'd find these uses of '#' very confusing. Which lines? lines starting with # -- here it is a comment sign Change /etc/resolv.conf back to search your_domain nameserver your_IP # nameserver 208.67.222.123 -- here it is meant as command running as root Then restart the service: # systemctl restart bind-named.service Does this alteration at the top make it any clearer? Note: at the command prompt, I use the following terminology: # means run as root $ means run as user Inside a file, "#" mean it is a comment ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/15/21 11:54 PM, G.W. Haywood via bind-users wrote: Hi there, On Wed, 16 Jun 2021, ToddAndMargo wrote: Re: My FC33->FC34 bind-chroot upgrade notes I hope this is the last time I have to revise this! ... Unfortunately perhaps not. :'( ... # means root $ means user ... Sometimes, in your configuration file extracts, you use '#' meaning 'this line is a comment'. I guess this is a write-up for a novice. The non-novices here have overlooked it, but I'm much closer to the novice end of the BIND user spectrum than they are and If I were a *complete* novice, I'd find these uses of '#' very confusing. Which lines? BIND is a hair puller at times. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/15/21 6:59 PM, ToddAndMargo via bind-users wrote:
On 6/15/21 12:51 PM, ToddAndMargo via bind-users wrote:
On 6/14/21 10:02 PM, ToddAndMargo via bind-users wrote:
Hi All,
Thank you all for the enormous help in me getting bind-chroot
working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Here are my revised, revised note. Ed had to
straighten me out on some boo-boos:
I hope this is the last time I have to revise this!
Broken bind-chroot repair after upgrading to Fedora 34:
# means root
$ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to
# search your_domain
# nameserver your_IP
nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled
the service after upgrading it.
To repair:
# systemctl enable named-chroot.service
# systemctl start named-chroot.service
Other useful command(s):
# systemctl stopnamed-chroot.service
# systemctl status named-chroot.service
# systemctl restart named-chroot.service
3) position named.conf and named.root.key:
When the bind-chroot service starts, it copies the following into
the chroot directory. Don't you do it! This will fail if it find
them there already. Then things get really confusing.
/etc/named.conf copies to /var/named/chroot/etc/.
/etc/named.root.key copies to /var/named/chroot/etc/.
The ones in your /etc directory are your masters.
When the named-chroot service is stopped. Make sure you do not have
two copies of either or both `/named/conf` and `named.root.key` kicking
around:
/etc/named.conf
/var/named/chroot/etc/named.conf <-- should not be there
when stopped
/etc/named.root.key
/var/named/chroot/etc/named.root.key <-- should not be there
when stopped
The ones in the chroot directory should have disappeared. Make sure you
only have one /etc/named.conf and /etc/named.root.key.
If you have two named.root.key's kicking around, the one that starts
with
trust-anchors {
is the good one.
To trigger the copy:
a) make sure /etc/named/conf and /etc/named.root.key are your masters
b) stop name-bind
# systemctl stop named-chroot
c) make sure the follow do not exist:
/var/named/chroot/etc/named.conf
/var/named/chroot/etc/named.root.key
d) update /etc/named.conf and /etc/named.root.key as desired
e) restart the service
# systemctl start named-chroot
4) the new version of bind-chroot enables "dns security validation" by
default.
Note: make sure /etc/named.root.key starts with `trust-anchors {`.
`managed-keys {` is depreciated.
Note: you should only have one named.root.key. /etc/named.root.key is
your master. If the named-chroot service is stopped, the one
in /var/named/chroot/etc should disappear.
To properly configure (repair), place the following in your named.conf:
add the following to your "options" block:
dnssec-validation yes;
by itself at the bottom:
include "/etc/named.root.key";
Then restart the service:
# systemctl restart bind-named.service
Other useful command(s):
Validation check:
$ delv @$IP com ds
$ delv @208.67.222.123 com ds
; fully validated
...
5) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Zones:
# named-checkzone -t directory domain filename
Note: the "domain name" is theh "zone" name from named.conf
zone, not `domainname`. For example:
zone "abc.local" {
type master;
file "slaves/abc.hosts";
allow-update { key DHCP_UPDATER; };
};
The "domain" is the name of the "zone". "abc.local" in the above.
You should check both your forward and reverse zones.
Examples:
# named-checkzone -t /var/named/chroot/var/named/slaves
abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
# named-checkzone -t /var/named/chroot/var/named/slaves
255.168.192.in-addr.arpa abc.hosts.rev
zone 255.168.192.in-addr.arpa/IN: loaded serial 213
OK
6) restart the bind-chroot service:
Change /etc/resolv.conf back to
search your_domain
nameserver your_IP
# nameserver 208.67.222.123
Restart the service:
# systemctl restart named-chroot.service
Check for and repair startup errors with:
$ systemctl status named-chroot.service
# tail -f /var/log/messages
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/15/21 12:51 PM, ToddAndMargo via bind-users wrote:
On 6/14/21 10:02 PM, ToddAndMargo via bind-users wrote:
Hi All,
Thank you all for the enormous help in me getting bind-chroot
working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Here are my revised, revised note. Ed had to
straighten me out on some boo-boos:
Broken bind-chroot repair after upgrading to Fedora 34:
# means root
$ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to
# search your_domain
# nameserver your_IP
nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled
the service after upgrading it. See the following bug I posted
on 2021-06-14:
Bind-chroot upgrade from FC3 to FC34 disables the service
breaking a server
https://bugzilla.redhat.com/show_bug.cgi?id=1972000
To repair:
# systemctl enable named-chroot.service
# systemctl start named-chroot.service
Other useful command(s):
# systemctl stopnamed-chroot.service
# systemctl status named-chroot.service
# systemctl restart named-chroot.service
3) position named.conf and named.root.key:
When the bind-chroot service starts, it copies the following into
the chroot directory.
Don't you do it!
cp /etc/named.conf /var/named/chroot/etc/.
cp /etc/named.root.key /var/named/chroot/etc/.
So the ones in your /etc/ directory are your masters.
To trigger this:
a) make sure /etc/named/conf and /etc/named.root.key are your masters
b) stop name-bind
# systemctl stop named-chroot
c) make sure the follow do not exist:
/var/named/chroot/etc/named.conf
/var/named/chroot/etc/named.root.key
d) restart the service
# systemctl start named-chroot
4) the new version of bind-chroot enables "dns security validation" by
default.
Make sure you do not have two `named.root.key` kicking around. One in
/etc/named.root.key
and one in
/var/named/chroot/etc/named.root.key
The bad one is the one that starts with `managed-keys {`, which is
depreciated.
The good one starts with `trust-anchors {`
If the one in chroot is bad:
# mv /var/named/chroot/etc/named.root.key
/var/named/chroot/etc/named.root.key.deprediated
# mv /etc/named.root.key /var/named/chroot/etc/named.root.key
# ln -s /var/named/chroot/etc/named.root.key /etc/named.root.key
To repair, place the following in your named.conf:
by itself at the bottom:
include "/etc/named.root.key";
Note: the actual location is: /var/named/chroot/etc/named.root.key
add the following to your "options" block:
dnssec-validation yes;
Other useful command(s):
Validation check:
$ delv @$IP com ds
$ delv @208.67.222.123 com ds
; fully validated
...
5) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Note: if you get the following error message,
`/etc/named.root.key:1: option 'managed-keys' is
deprecated`
you may have to seperate named.root.conf files. This will
read the one in chroot.
Zones:
# named-checkzone -t directory domain filename
Note: the "domain name" in the following comes from named.conf
zone, not `domainname`. For example:
zone "abc.local" {
type master;
file "slaves/rent-a-nerd.hosts";
allow-update { key DHCP_UPDATER; };
};
The "domain" is the name of the "zone". "abc.local" in the above
# named-checkzone -t /var/named/chroot/var/named/slaves
abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
# named-checkzone -t /var/named/chroot/var/named/slaves
255.168.192.in-addr.arpa abc.hosts.rev
zone 255.168.192.in-addr.arpa/IN: loaded serial 213
OK
6) restart the bind-chroot service:
Change /etc/resolv.conf back to
search your_domain
nameserver your_IP
# nameserver 208.67.222.123
# systemctl restart named-chroot.service
check for and repair errors with:
$ systemctl status named-chroot.service
# tail -f /var/log/messages
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: My FC33->FC34 bind-chroot upgrade notes
On 6/14/21 10:02 PM, ToddAndMargo via bind-users wrote:
Hi All,
Thank you all for the enormous help in me getting bind-chroot
working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Well, if at first you don't succeed, revise! See
changes to named.root.key
Broken bind-chroot repair after upgrading to Fedora 34:
# means root
$ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to
# search your_domain
# nameserver your_IP
nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled
the service after upgrading it. See the following bug I posted
on 2021-06-14:
Bind-chroot upgrade from FC3 to FC34 disables the service
breaking a server
https://bugzilla.redhat.com/show_bug.cgi?id=1972000
To repair:
# systemctl enable named-chroot.service
# systemctl start named-chroot.service
Other useful command(s):
# systemctl stopnamed-chroot.service
# systemctl status named-chroot.service
# systemctl restart named-chroot.service
3) the new version of bind-chroot enables "dns security validation" by
default.
Make sure you do not have two `named.root.key` kicking around. One in
/etc/named.root.key
and one in
/var/named/chroot/etc/named.root.key
The bad one is the one that starts with `managed-keys {`, which is
depreciated.
The good one starts with `trust-anchors {`
If the one in chroot is bad:
# mv /var/named/chroot/etc/named.root.key
/var/named/chroot/etc/named.root.key.deprediated
# mv /etc/named.root.key /var/named/chroot/etc/named.root.key
# ln -s /var/named/chroot/etc/named.root.key /etc/named.root.key
To repair, place the following in your named.conf:
by itself at the bottom:
include "/etc/named.root.key";
Note: the actual location is: /var/named/chroot/etc/named.root.key
add the following to your "options" block:
dnssec-validation yes;
Other useful command(s):
Validation check:
$ delv @$IP com ds
$ delv @208.67.222.123 com ds
; fully validated
...
4) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Note: if you get the following error message,
`/etc/named.root.key:1: option 'managed-keys' is
deprecated`
you may have to seperate named.root.conf files. This will
read the one in chroot.
Zones:
# named-checkzone -t directory domain filename
Note: the "domain name" in the following comes from named.conf
zone, not `domainname`. For example:
zone "abc.local" {
type master;
file "slaves/rent-a-nerd.hosts";
allow-update { key DHCP_UPDATER; };
};
The "domain" is the name of the "zone". "abc.local" in the above
# named-checkzone -t /var/named/chroot/var/named/slaves
abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
# named-checkzone -t /var/named/chroot/var/named/slaves
255.168.192.in-addr.arpa abc.hosts.rev
zone 255.168.192.in-addr.arpa/IN: loaded serial 213
OK
5) restart the bind-chroot service:
Change /etc/resolv.conf back to
search your_domain
nameserver your_IP
# nameserver 208.67.222.123
# systemctl restart named-chroot.service
check for and repair errors with:
$ systemctl status named-chroot.service
# tail -f /var/log/messages
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: 'managed-keys' is deprecated ??
On 15-06-2021 07:46, ToddAndMargo via bind-users wrote: On 6/14/21 9:30 PM, Jim Popovitch via bind-users wrote: On Tue, 2021-06-15 at 14:27 +1000, Mark Andrews wrote: https://downloads.isc.org/isc/bind9/9.16.16/doc/arm/Bv9ARM.pdf The modern-day RTFM :-) -Jim P. "Just Google it." The new RTFM. Chuckle! And ' 'managed-keys' is deprecated" is a bug. I just reported: named-checkconf gives confusing depreciated 'managed-keys' message https://bugzilla.redhat.com/show_bug.cgi?id=1972022 :'( -T On 6/15/21 12:26 AM, Matthijs Mekking wrote: > Hi -T, > > I cannot reproduce this confusing warning message. Please use the > absolute path /var/named/chroot/etc/named.root.key in > https://bugzilla.redhat.com/show_bug.cgi?id=1972022 > > Best regards, > > Matthijs Hi Matthijs, OH POOP!!! I have TWO named.root.key's. The one in is the good one from Fedora 34 /etc/named.root.key and the one in /var/named/chroot/etc/named.root.key is the depreciated one from Fedora 33. I manually fixed the issue. Question: was the named-chroot RPM post installation script suppose to update named.root.key in chroot, or was I suppose to do that? Many thanks, -T ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'managed-keys' is deprecated ??
On 6/14/21 9:30 PM, Jim Popovitch via bind-users wrote: On Tue, 2021-06-15 at 14:27 +1000, Mark Andrews wrote: https://downloads.isc.org/isc/bind9/9.16.16/doc/arm/Bv9ARM.pdf The modern-day RTFM :-) -Jim P. "Just Google it." The new RTFM. Chuckle! And ' 'managed-keys' is deprecated" is a bug. I just reported: named-checkconf gives confusing depreciated 'managed-keys' message https://bugzilla.redhat.com/show_bug.cgi?id=1972022 :'( -T ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
My FC33->FC34 bind-chroot upgrade notes
Hi All,
Thank you all for the enormous help in me getting bind-chroot
working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Broken bind-chroot repair after upgrading to Fedora 34:
# means root
$ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to
# search your_domain
# nameserver your_IP
nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled
the service after upgrading it. See the following bug I posted
on 2021-06-14:
Bind-chroot upgrade from FC3 to FC34 disables the service
breaking a server
https://bugzilla.redhat.com/show_bug.cgi?id=1972000
To repair:
# systemctl enable named-chroot.service
# systemctl start named-chroot.service
Other useful command(s):
# systemctl stopnamed-chroot.service
# systemctl status named-chroot.service
# systemctl restart named-chroot.service
3) the new version of bind-chroot enables "dns security validation" by
default.
To repair, place the following in your named.conf:
by itself at the bottom:
include "/etc/named.root.key";
add the following to your "options" block:
dnssec-validation yes;
Other useful command(s):
Validation check:
$ delv @$IP com ds
$ delv @208.67.222.123 com ds
; fully validated
...
4) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Note: if you get the following error message,
`/etc/named.root.key:1: option 'managed-keys' is
deprecated`
it is a bug in named-checkconf.
See the following I posted on 2021-06-14. Just ignore
the message.
named-checkconf gives confusing depreciated
'managed-keys' message
https://bugzilla.redhat.com/show_bug.cgi?id=1972022
Zones:
# named-checkzone -t directory domain filename
Note: the "domain name" in the following comes from named.conf
zone, not `domainname`. For example:
zone "abc.local" {
type master;
file "slaves/rent-a-nerd.hosts";
allow-update { key DHCP_UPDATER; };
};
The "domain" is the name of the "zone". "abc.local" in the above
# named-checkzone -t /var/named/chroot/var/named/slaves
abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
# named-checkzone -t /var/named/chroot/var/named/slaves
255.168.192.in-addr.arpa abc.hosts.rev
zone 255.168.192.in-addr.arpa/IN: loaded serial 213
OK
5) restart the bind-chroot service:
Change /etc/resolv.conf back to
search your_domain
nameserver your_IP
# nameserver 208.67.222.123
# systemctl restart named-chroot.service
check for and repair errors with:
$ systemctl status named-chroot.service
# tail -f /var/log/messages
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
'managed-keys' is deprecated ??
Hi All, Fedora 34 bind 9.16 The Duck is failing me. Placing include "/etc/named.root.key"; in my bind.conf, give me the following error: # named-checkconf -l -t /var/named/chroot /etc/named.conf /etc/named.root.key:1: option 'managed-keys' is deprecated What do I use in its place? Many thanks, -T ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.11 to 9.16: need directions
On 6/13/21 12:13 AM, ToddAndMargo via bind-users wrote:
On 6/12/21 11:47 PM, ToddAndMargo via bind-users wrote:
Oh but no errors and it still does not work!
# host 8.8.8.8
Host 8.8.8.8.in-addr.arpa not found: 2(SERVFAIL)
# host 8.8.8.8 8.8.4.4
Using domain server:
Name: 8.8.4.4
Address: 8.8.4.4#53
Aliases: 8.8.8.8.in-addr.arpa domain name pointer dns.google.
and nothing appeared in /var/log/messages
Tears!
Okay, now I am REALLY confused!!!
# host 8.8.8.8 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
Host 8.8.8.8.in-addr.arpa not found: 2(SERVFAIL)
This is my /etc/resolv.conf (same as in FC33):
# cat /etc/resolv.conf
# Generated by NetworkManager
search abc.local
nameserver 127.0.0.1
# nameserver 8.8.8.8
Now what ?!?!?!
A workaround i at the bottom
# host google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
Host google.com not found: 2(SERVFAIL)
[root@rn6 etc]# systemctl status named-chroot.service
● named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service;
enabled; vendor preset: disabled)
Active: active (running) since Sun 2021-06-13 01:39:12 PDT; 1min
12s ago
Process: 32167 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t
/var/named/chroot -z "$NAMEDCONF"; else echo "Checki>
Process: 32170 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF}
-t /var/named/chroot $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 32171 (named)
Tasks: 14 (limit: 19025)
Memory: 97.2M
CPU: 180ms
CGroup: /system.slice/named-chroot.service
└─32171 /usr/sbin/named -u named -c /etc/named.conf -t
/var/named/chroot
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:503:c27::2:30#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:500:1::53#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:500:2::c#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:500:200::b#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:500:12::d0d#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:500:9f::42#53
Jun 13 01:40:05 rn6.abc.local named[32171]: network unreachable
resolving 'com/DS/IN': 2001:7fd::1#53
Jun 13 01:40:05 rn6.abc.local named[32171]: validating com/DS: no valid
signature found
Jun 13 01:40:05 rn6.abc.local named[32171]: no valid RRSIG resolving
'com/DS/IN': 192.36.148.17#53
Jun 13 01:40:05 rn6.abc.local named[32171]: broken trust chain resolving
'google.com/A/IN': 208.67.220.220#53
Found in /var/log/messages:
Jun 13 01:43:12 rn6 named[32171]: validating google.com/A: bad cache hit
(com/DS)
Jun 13 01:43:12 rn6 named[32171]: broken trust chain resolving
'google.com/A/IN': 208.67.220.220#53
I added this to named.conf, options block:
dnssec-validation no;
and it fixed it.
How do I fix it without dnssec-validation no; ?
-T
# host google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
google.com has address 172.217.6.78
google.com has IPv6 address 2607:f8b0:4005:80a::200e
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.11 to 9.16: need directions
On 6/12/21 11:47 PM, ToddAndMargo via bind-users wrote: Oh but no errors and it still does not work! # host 8.8.8.8 Host 8.8.8.8.in-addr.arpa not found: 2(SERVFAIL) # host 8.8.8.8 8.8.4.4 Using domain server: Name: 8.8.4.4 Address: 8.8.4.4#53 Aliases: 8.8.8.8.in-addr.arpa domain name pointer dns.google. and nothing appeared in /var/log/messages Tears! Okay, now I am REALLY confused!!! # host 8.8.8.8 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: Host 8.8.8.8.in-addr.arpa not found: 2(SERVFAIL) This is my /etc/resolv.conf (same as in FC33): # cat /etc/resolv.conf # Generated by NetworkManager search abc.local nameserver 127.0.0.1 # nameserver 8.8.8.8 Now what ?!?!?! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.11 to 9.16: need directions
Oh but no errors and it still does not work! # host 8.8.8.8 Host 8.8.8.8.in-addr.arpa not found: 2(SERVFAIL) # host 8.8.8.8 8.8.4.4 Using domain server: Name: 8.8.4.4 Address: 8.8.4.4#53 Aliases: 8.8.8.8.in-addr.arpa domain name pointer dns.google. and nothing appeared in /var/log/messages Tears! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.11 to 9.16: need directions
On 6/12/21 5:30 PM, ToddAndMargo via bind-users wrote:
Hi All,
I just upgraded from Fedora 33 to Fedora 34.
Bind was updated from 9.11 to 9.16 in Fedora 34.
It completely broke my Fedora 33 configuration.
Would someone please point me to the directions
as to how to migrate from 9.11 to 9.16?
Many thanks,
-T
Oh poop! Figured it out!
# systemctl status named-chroot.service
● named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service;
enabled; vendor preset: disabled)
Active: active (running) since Sat 2021-06-12 14:49:05 PDT; 8h ago
Process: 11410 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t
/var/named/chroot -z "$NAMEDCONF"; else echo "Checki>
Process: 11446 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF}
-t /var/named/chroot $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 11452 (named)
Tasks: 14 (limit: 19025)
Memory: 141.5M
CPU: 14.612s
CGroup: /system.slice/named-chroot.service
└─11452 /usr/sbin/named -u named -c /etc/named.conf -t
/var/named/chroot
I was starting the wrong named !!!
# systemctl disable daemon_name.service
Fixed the problem
Freaking FC34 upgrade disabled named-chroot on me!
Sorry for putting your guys through all this. Thank
you all for the tips!
-T
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.11 to 9.16: need directions
On 6/12/21 10:55 PM, Ondřej Surý wrote: Most likely SELinux policy is preventing access to those files. Check the other logs. Ondřej -- Ondřej Surý — ISC (He/Him) No SE Linux error popping up. But I shut it off temporarily anyway. No symptom change. Rats! # setenforce Permissive # systemctl start named.service Job for named.service failed because the control process exited with error code. See "systemctl status named.service" and "journalctl -xeu named.service" for details. # systemctl status named.service × named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2021-06-12 23:00:31 PDT; 10s ago Process: 26835 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is d> CPU: 11ms Jun 12 23:00:31 rn6.abc.local bash[26836]: _default/abc.local/IN: file not found Jun 12 23:00:31 rn6.abc.local bash[26836]: zone 255.168.192.in-addr.arpa/IN: loading from master file slaves/abc.hosts.rev failed: file not found Jun 12 23:00:31 rn6.abc.local bash[26836]: zone 255.168.192.in-addr.arpa/IN: not loaded due to errors. Jun 12 23:00:31 rn6.abc.local bash[26836]: _default/255.168.192.in-addr.arpa/IN: file not found Jun 12 23:00:31 rn6.abc.local bash[26836]: zone 0.0.127.in-addr.arpa/IN: loading from master file named.local failed: file not found Jun 12 23:00:31 rn6.abc.local bash[26836]: zone 0.0.127.in-addr.arpa/IN: not loaded due to errors. Jun 12 23:00:31 rn6.abc.local bash[26836]: _default/0.0.127.in-addr.arpa/IN: file not found Jun 12 23:00:31 rn6.abc.local systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE Jun 12 23:00:31 rn6.abc.local systemd[1]: named.service: Failed with result 'exit-code'. Jun 12 23:00:31 rn6.abc.local systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.11 to 9.16: need directions
On 6/12/21 8:30 PM, ToddAndMargo via bind-users wrote:
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local
abc.hosts.rev
abc.hosts.rev:3: ignoring out-of-zone data (255.168.192.in-addr.arpa)
abc.hosts.rev:14: ignoring out-of-zone data
abc.hosts(10.255.168.192.in-addr.arpa)
abc.hosts.rev:17: ignoring out-of-zone data
# rpm -aq bind\*
bind-export-libs-9.11.11-1.fc30.x86_64
bind-license-9.16.16-1.fc34.noarch
bind-dnssec-doc-9.16.16-1.fc34.noarch
bind-libs-9.16.16-1.fc34.x86_64
bind-utils-9.16.16-1.fc34.x86_64
bind-dnssec-utils-9.16.16-1.fc34.x86_64
bind-9.16.16-1.fc34.x86_64
bind-chroot-9.16.16-1.fc34.x86_64
Oh poop. I had the zone name wrong again. The zone
name comes directly from named.conf. Duh!
# named-checkzone -t /var/named/chroot/var/named/slaves
255.168.192.in-addr.arpa abc.hosts.rev
zone 255.168.192.in-addr.arpa/IN: loaded serial 213
OK
Now I also have
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
and
# named-checkconf -l -t /var/named/chroot /etc/named.conf
abc.local IN _default master
255.168.192.in-addr.arpa IN _default master
0.0.127.in-addr.arpa IN _default master
So why am I getting file not found in the following?
# systemctl status named.service
× named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled;
vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2021-06-12 16:31:16
PDT; 3h 46min ago
Process: 18368 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
"$NAMEDCONF"; else echo "Checking of zone files is >
CPU: 12ms
Jun 12 16:31:16 rn6.abc.local bash[18369]: _default/abc.local/IN: file
not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone
255.168.192.in-addr.arpa/IN: loading from master file
slaves/abc.hosts.rev failed: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone
255.168.192.in-addr.arpa/IN: not loaded due to errors.
Jun 12 16:31:16 rn6.abc.local bash[18369]:
_default/255.168.192.in-addr.arpa/IN: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone 0.0.127.in-addr.arpa/IN:
loading from master file named.local failed: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone 0.0.127.in-addr.arpa/IN:
not loaded due to errors.
Jun 12 16:31:16 rn6.abc.local bash[18369]:
_default/0.0.127.in-addr.arpa/IN: file not found
Jun 12 16:31:16 rn6.abc.local systemd[1]: named.service: Control process
exited, code=exited, status=1/FAILURE
Jun 12 16:31:16 rn6.abc.local systemd[1]: named.service: Failed with
result 'exit-code'.
Jun 12 16:31:16 rn6.abc.local systemd[1]: Failed to start Berkeley
Internet Name Domain (DNS).
My /etc/named.local
// generated by named-bootconf.pl
options {
# the following forwarders is Family freindly Open DNS:
# forwarders { 208.67.222.122; 208.67.220.120; };
# the following forwarders is for Open DNS
forwarders { 208.67.222.222; 208.67.220.220; };
# the following forwarders is for Google's DNS
#forwarders { 8.8.8.8; 8.8.4.4; };
directory "/var/named";
# pid-file "/var/named/chroot/run/named/named.pid";
# pid-file "/var/named/chroot/run/named/nonamed.pid";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
key DHCP_UPDATER {
algorithm hmac-md5;
secret cgGq509uDODGTU4J9QZwgQ==;
};
zone "abc.local" {
type master;
# file "/var/named/chroot/var/named/slaves/abc.hosts";
file "slaves/abc.hosts";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
zone "255.168.192.in-addr.arpa" {
type master;
# file "/var/named/chroot/var/named/slaves/abc.hosts.rev";
file "slaves/abc.hosts.rev";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
zone "0.0.127.in-addr.arpa" {
type master;
# file "/var/named/chroot/var/named/named.local";
file "named.local";
};
# logging {
# channel update_debug {
# file
"/var/named/chroot/var/named/slaves/named-update-debug.log";
# severity debug 3;
# print-category yes;
# print-severity yes;
# print-time yes;
# };
# channel security_info{
# file "slaves/named-auth.info";
# severity info;
# pr
Re: 9.11 to 9.16: need directions
On 6/12/21 7:49 PM, Mark Andrews wrote:
Please don’t hid details if you want help.
If you really want help post all the un-doctored log messages.
B.T.W. The messages below are because you used the wrong zone name on the
named-checkconf command line. The zone file is for xyz.local and you said the
zone name you used was xyz without the .local.
I posted the error I have see so far. Please give me a list of other
error reporting options.
Please note that everything worked perfectly under Fedora 33 and bind 9,11.
Now that I have the .local, things improved for abc.hosts,
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local abc.hosts
zone abc.local/IN: loaded serial 265
OK
but not abc.hosts.rev
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local
abc.hosts.rev
abc.hosts.rev:3: ignoring out-of-zone data (255.168.192.in-addr.arpa)
abc.hosts.rev:14: ignoring out-of-zone data
abc.hosts(10.255.168.192.in-addr.arpa)
abc.hosts.rev:17: ignoring out-of-zone data
12 repeats
zone abc.local/IN: has 0 SOA records
zone abc.local/IN: has no NS records
zone abc.local/IN: not loaded due to errors.
# cat --number /var/named/chroot/var/named/slaves/abc.hosts.rev
1 $ORIGIN .
2 $TTL 86400 ; 1 day
3 255.168.192.in-addr.arpa IN SOA rn6.abc.local.
root\@rn6.abc.local. (
4 213; serial
5 10800 ; refresh (3 hours)
6 3600 ; retry (1 hour)
7 360; expire (5 weeks 6 days 16
hours)
8 86400 ; minimum (1 day)
9 )
10 NS rn6.abc.local.
11 A 192.168.255.10
12 PTR rn6.abc.local.
13 $ORIGIN 255.168.192.in-addr.arpa.
14 10 A 192.168.255.10
15 PTR rn6.abc.local.
16 $TTL 3600 ; 1 hour
17 112 PTR KVM-W7.abc.local.
What exactly is wrong with the zone?
3 255.168.192.in-addr.arpa IN SOA rn6.abc.local.
And here is status ("not loaded due to errors"):
# systemctl status named.service
× named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled;
vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2021-06-12 16:31:16
PDT; 3h 46min ago
Process: 18368 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
"$NAMEDCONF"; else echo "Checking of zone files is >
CPU: 12ms
Jun 12 16:31:16 rn6.abc.local bash[18369]: _default/abc.local/IN: file
not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone
255.168.192.in-addr.arpa/IN: loading from master file
slaves/abc.hosts.rev failed: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone
255.168.192.in-addr.arpa/IN: not loaded due to errors.
Jun 12 16:31:16 rn6.abc.local bash[18369]:
_default/255.168.192.in-addr.arpa/IN: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone 0.0.127.in-addr.arpa/IN:
loading from master file named.local failed: file not found
Jun 12 16:31:16 rn6.abc.local bash[18369]: zone 0.0.127.in-addr.arpa/IN:
not loaded due to errors.
Jun 12 16:31:16 rn6.abc.local bash[18369]:
_default/0.0.127.in-addr.arpa/IN: file not found
Jun 12 16:31:16 rn6.abc.local systemd[1]: named.service: Control process
exited, code=exited, status=1/FAILURE
Jun 12 16:31:16 rn6.abc.local systemd[1]: named.service: Failed with
result 'exit-code'.
Jun 12 16:31:16 rn6.abc.local systemd[1]: Failed to start Berkeley
Internet Name Domain (DNS).
from named.local:
zone "255.168.192.in-addr.arpa" {
type master;
# file "/var/named/chroot/var/named/slaves/abc.hosts.rev";
file "slaves/abc.hosts.rev";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
Thank you for the help. Let me know if I did if I
missed posting enough information.
-T
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.11 to 9.16: need directions
On 6/12/21 5:30 PM, ToddAndMargo via bind-users wrote: Hi All, I just upgraded from Fedora 33 to Fedora 34. Bind was updated from 9.11 to 9.16 in Fedora 34. It completely broke my Fedora 33 configuration. Would someone please point me to the directions as to how to migrate from 9.11 to 9.16? Many thanks, -T Some of my error messages: # named-checkzone -t /var/named/chroot/var/named/slaves xyz xyz.hosts xyz.hosts:3: ignoring out-of-zone data (xyz.local) xyz.hosts:15: ignoring out-of-zone data (DeadStick.xyz.local) 1$ORIGIN . 2$TTL 86400; 1 day 3xyz.localIN SOAxyz.local. root\@rn6.xyz.local. ( 4265; serial 510800 ; refresh (3 hours) 63600 ; retry (1 hour) 7360; expire (5 weeks 6 days 16 hours) 886400 ; minimum (1 day) 9) 10NSxyz.local. 11A192.168.255.10 12MX10 xyz.local. 13$ORIGIN xyz.local. 14$TTL 3600; 1 hour 15DeadStickA192.168.255.156 16TXT"310702541c5622d0e6001136bd71a6578b" ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
9.11 to 9.16: need directions
Hi All, I just upgraded from Fedora 33 to Fedora 34. Bind was updated from 9.11 to 9.16 in Fedora 34. It completely broke my Fedora 33 configuration. Would someone please point me to the directions as to how to migrate from 9.11 to 9.16? Many thanks, -T ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Confused about SELinux error
- Original Message -
From: "ToddAndMargo" <toddandma...@zoho.com>
To: bind-users@lists.isc.org
Sent: Friday, August 11, 2017 10:39:11 PM
Subject: Confused about SELinux error
Hi All,
What does this SELinux error mean when I start bin-chroot?
# semanage fcontext -a -t FILE_TYPE 'session.key'
where FILE_TYPE is one of the following: dnssec_trigger_var_run_t,
ipa_var_lib_t, krb5_host_rcache_t, krb5_keytab_t, named_cache_t,
named_log_t, named_tmp_t, named_var_run_t.
# semanage fcontext -a -t named_var_run_t 'session.key'
# restorecon -v 'session.key'
How am I suppose to know what "FILE_TYPE" they are talking about?
-T
On 08/14/2017 06:26 AM, Petr Mensik wrote:
Hi Todd,
that means you are trying to save session.key into directory where SELinux is
forbidding write access to named.
Session.key is file created once per start and removed before shutdown. I think
you have something wrong with link /var/run/named -> /run/named link.
Default built-in value is /var/run/named/session.key. Default Fedora
configuration uses /run/named/session.key. Both paths should work without
difference.
Correct selinux type for files in /run/named is named_var_run_t. I think you
should run instead:
$ restorecon -rv /run/named /var/run/named
Then restart named service. Context of a new file should be already correct.
Do you have this option in you configuration file? What is its value?
# options { ...
session-keyfile "/run/named/session.key";
It would be helpful if you include you configuration in readable form, please.
Chuckle. I promise not to use zoho's web mail. And
I tough gMail's web mail stunk!
Listed types are more likely types named is allowed to touch. I admit SELinux
errors are often confusing. What you written here are hints to you how to solve
the error, not the error itself.
More helpful errors would be printed by:
$ ausearch -i -ts today -m avc -m user_avc -m selinux_err
Regards,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com PGP: 65C6C973
Hi Petr,
Thank you for responding! I have attached by my
named.conf and my dhcpd.conf
I have an rndc.key in /var/named/chroot/etc/:
key "rndckey" {
algorithm hmac-md5;
secret "";
};
But I don't see named.conf calling it out. It may
be a hold over from the previous CentOS 5 installation.
I do see "key DHCP_UPDATER" called out. Perhaps
that is what rndckey is about?
-T
~ named.conf ~~~
options {
# the following forwarders is for Open DNS
forwarders { 208.67.222.222; 208.67.220.220; };
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
key DHCP_UPDATER {
algorithm hmac-md5;
secret ;
};
zone ".local" {
type master;
file "slaves/x.hosts";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
zone "yyy.168.192.in-addr.arpa" {
type master;
file "slaves/x.hosts.rev";
allow-update { key DHCP_UPDATER; };
# allow-update { 127.0.0.1; };
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
logging {
channel update_debug {
file "slaves/named-update-debug.log";
severity debug 3;
print-category yes;
print-severity yes;
print-time yes;
};
channel security_info{
file "slaves/named-auth.info";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category update { update_debug; };
category security { security_info; };
};
~ dhcpd.conf ~~~
DHCPDARGS=eno1;
ddns-updates on;
ddns-update-style interim;
ignore client-updates;
update-static-leases on;
option ntp-servers 192.168.xxx.yyy;
option domain-name "xx.local";
option domain-name-servers 192.168.xxx.yyy;
option netbios-node-type 8;
key DHCP_UPDATER {
algorithm hmac-md5;
secret xxx;
};
zone x.local. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
zone xxx.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
subnet 192.168.xxx.0 netmask 255.255.255.0 {
range 192.168.xxx.100 192.168.xxx.200;
default-lease-time 10368000;
max-lease-time 10368000;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.xxx.255;
option routers 192.168.xxx.yyy;
option domain-name-servers 192.168.xxx.yyy;
option domain-name "xx.local";
Re: need to look up short names
On 08/11/2017 02:40 PM, ToddAndMargo wrote: On 08/10/2017 07:07 PM, Grant Taylor via bind-users wrote: On 08/10/2017 06:21 PM, toddandmargo wrote: Fedora 26 Fedora = Linux (vs Windows vs other) I am stumped. I need to be able to look up short names on my local network. ... What am I missing? domain and / or search configuration in /etc/resolv.conf man resolv.conf Follow up: I had goofed my /etc/resolv.conf. The hostname was suppose to be ".local" not ".com". mumble, mumble -T Setting the host and domain name has gotten a little "interesting" in Fedora as of late. # hostnamectl set-hostname FedoraServer..local –static And it updates resolv.conf too ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: need to look up short names
On 08/10/2017 07:07 PM, Grant Taylor via bind-users wrote: On 08/10/2017 06:21 PM, toddandmargo wrote: Fedora 26 Fedora = Linux (vs Windows vs other) I am stumped. I need to be able to look up short names on my local network. ... What am I missing? domain and / or search configuration in /etc/resolv.conf man resolv.conf Follow up: I had goofed my /etc/resolv.conf. The hostname was suppose to be ".local" not ".com". mumble, mumble -T ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Confused about SELinux error
Hi All, What does this SELinux error mean when I start bin-chroot? # semanage fcontext -a -t FILE_TYPE 'session.key' where FILE_TYPE is one of the following: dnssec_trigger_var_run_t, ipa_var_lib_t, krb5_host_rcache_t, krb5_keytab_t, named_cache_t, named_log_t, named_tmp_t, named_var_run_t. # semanage fcontext -a -t named_var_run_t 'session.key' # restorecon -v 'session.key' How am I suppose to know what "FILE_TYPE" they are talking about? -T ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
need to look up short names
Hi All, Fedora 26 bind-chroot-9.11.1-2.P2.fc26.x86_64 I am stumped. I need to be able to look up short names on my local network. Long names work: # host pop3.xxx.local pop3.xxx.local is an alias for FedoraServer.xxx.local. FedoraServer.xxx.local has address 192.168.255.12 But not short names: # host pop3 Host pop3 not found: 3(NXDOMAIN) My hosts.xxx look like this for pop3: FedoraServerA 192.168.255.12 pop3CNAME FedoraServer What am I missing? Many thanks, -T ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
I need of list of SELinux rules for bind.
Hi All, Fedora 26 x64 Xfce 4.12 # rpm -qa \bind\* bind-libs-lite-9.11.1-2.P2.fc26.x86_64 bind99-libs-9.9.10-1.P2.fc26.x86_64 bind-chroot-9.11.1-2.P2.fc26.x86_64 bind-license-9.11.1-2.P2.fc26.noarch bind-9.11.1-2.P2.fc26.x86_64 bind-libs-9.11.1-2.P2.fc26.x86_64 bind99-license-9.9.10-1.P2.fc26.noarch bind-utils-9.11.1-2.P2.fc26.x86_64 Would someone point me to a list of SELinux rules for use with bind-chroot? Many thanks, -T ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-chroot, runs, works, dies
that did the trick. Thank you On Wed, 09 Aug 2017 15:19:02 -0700 Reindl Haraldh.rei...@thelounge.net wrote [Service] Type=simple ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind-chroot, runs, works, dies
Hi All,
Help!
Fedora 26 x64
Xfce 4.12
# rpm -qa \bind\*
bind-libs-lite-9.11.1-2.P2.fc26.x86_64
bind99-libs-9.9.10-1.P2.fc26.x86_64
bind-chroot-9.11.1-2.P2.fc26.x86_64
bind-license-9.11.1-2.P2.fc26.noarch
bind-9.11.1-2.P2.fc26.x86_64
bind-libs-9.11.1-2.P2.fc26.x86_64
bind99-license-9.9.10-1.P2.fc26.noarch
bind-utils-9.11.1-2.P2.fc26.x86_64I have a weird one. I am trying to set up
bind-chroot. When I run it, it works
for about 30 seconds, then dies. And for the entire 30 seconds, it works
beautifully. I can go anywhere with Firefox and look up anything with "host".
Then it breaks my heart.
# systemctl start named-chroot Job for named-chroot.service canceled. This is
my error logs:
Aug 8 15:58:49 FedoraServer named[10120]: all zones loaded Aug 8 15:58:49
FedoraServer named[10120]: running Aug 8 15:58:49 FedoraServer named[10120]:
zone 255.168.192.in-addr.arpa/IN: sending notifies (serial 57) Aug 8 15:58:49
FedoraServer named[10120]: zone alpine.local/IN: sending notifies (serial 60)
Aug 8 15:58:49 FedoraServer systemd: named-chroot.service: PID file
/var/named/chroot/run/named/named.pid not readable (yet?) after start: No such
file or directory Aug 8 16:00:19 FedoraServer systemd: named-chroot.service:
Start operation timed out. Terminating. Aug 8 16:00:19 FedoraServer
named[10120]: shutting down Aug 8 16:00:19 FedoraServer named[10120]: stopping
command channel on 127.0.0.1#953 Aug 8 16:00:19 FedoraServer named[10120]:
stopping command channel on ::1#953 Aug 8 16:00:19 FedoraServer named[10120]:
no longer listening on ::#53 Aug 8 16:00:19 FedoraServer named[10120]: no
longer listening on 127.0.0.1#53 Aug 8 16:00:19 FedoraServer named[10120]: no
longer listening on 50.124.80.106#53 Aug 8 16:00:19 FedoraServer named[10120]:
exiting Aug 8 16:00:19 FedoraServer systemd: Stopped Berkeley Internet Name
Domain (DNS). Aug 8 16:00:19 FedoraServer systemd: named-chroot.service: Unit
entered failed state. Aug 8 16:00:19 FedoraServer systemd:
named-chroot.service: Failed with result 'timeout'. Aug 8 16:00:19 FedoraServer
systemd: Stopping Set-up/destroy chroot environment for named (DNS)... Aug 8
16:00:19 FedoraServer audit: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=named-chroot
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=failed' Aug 8 16:00:20 FedoraServer systemd: Stopped Set-up/destroy chroot
environment for named (DNS). Aug 8 16:00:20 FedoraServer audit: SERVICE_STOP
pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=named-chroot-setup comm="systemd" exe="/usr/lib/systemd/systemd"
hostname=? addr=? terminal=? res=success' I find the
PID file /var/named/chroot/run/named/named.pid not readable (yet?) after
start: No such file or directory error to be a bit weird as the directory does
exist and the entire directory tree from /var/named is owned by "named". This
is usually SELinux's doing. But SELinux does not throw an error.
My "named.conf":
// generated by named-bootconf.pl options { # the following forwarders is for
Open DNS forwarders { 208.67.222.222; 208.67.220.220; }; directory
"/var/named"; # pid-file "/var/named/chroot/run/named/named.pid"; # pid-file
"/var/named/chroot/run/named/nonamed.pid"; /* * If there is a firewall between
you and nameservers you want * to talk to, you might need to uncomment the
query-source * directive below. Previous versions of BIND always asked *
questions using port 53, but BIND 8.1 uses an unprivileged * port by default.
*/ // query-source address * port 53; }; // // /etc/named.boot // // This is
the boot file that /etc/init.d/inetsvc uses to run in.named // // // The
"directory path" statement points to where the name server (and // its
files) will be running. // example: // directory /var/named // // // // The
"cache . named.ca" statement appears on all servers and tells the // server
which servers are authoritative name servers for the root zone. // The
addresses of the "higher authorities" are listed in the named.ca file. // zone
"." { type hint; file "named.ca"; }; // // // forwarders 206.40.79.2 //
forward-only // // key DHCP_UPDATER { algorithm hmac-md5; secret
dgGQZwgQ==; }; zone "alpine.local" { type master; file
"slaves/alpine.hosts"; allow-update { key DHCP_UPDATER; }; # allow-update {
127.0.0.1; }; }; zone "255.168.192.in-addr.arpa" { type master; file
"slaves/alpine.hosts.rev"; allow-update { key DHCP_UPDATER; }; # allow-update {
127.0.0.1; }; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local";
}; logging { channel update_debug { file "slaves/named-update-debug.log";
severity debug 3; print-category yes; print-severity yes; print-time yes; };
channel security_info { file "slaves/named-auth.info"; severity info;
print-category yes; print-severity yes; print-time yes; }; category update {
update_debug; }; category security { security_info; }; };
