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}' Inod
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;
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