Bind upgrade producing errors on pfsense 2.5 upgrade

anthonypants

@wrgraves I mentioned it earlier, but if you run named from the console and don't give it the configuration file, it seems to work fine.

viktor_g

@nordeep said in Bind upgrade producing errors on pfsense 2.5 upgrade:

After upgrade to 2.5. Simple run: /usr/local/sbin/named -4 -c /etc/namedb/named.conf -u bind -t /cf/named/ result is Segmentation fault.

I'm using common bind setup - 1 view, 2 zones, 4 ACLs, No Sync.

/usr/local/sbin/named -4 -c /etc/namedb/named.conf -u bind -t /cf/named/ works fine for me

Could you provide your views/zones/acls configuration?
You can hide your private data by changing domain/IP.

nordeep

@viktor_g said in Bind upgrade producing errors on pfsense 2.5 upgrade:

Could you provide your views/zones/acls configuration?

cat /cf/named//etc/namedb/named.conf

#Bind pfsense configuration
#Do not edit this file!!!

 key "rndc-key" {
        algorithm hmac-sha256;
        secret "====";
 };

 controls {
        inet 127.0.0.1 port 953
                allow { 127.0.0.1; } keys { "rndc-key"; };
 };



options {
        directory "/etc/namedb";
        pid-file "/var/run/named/pid";
        statistics-file "/var/log/named.stats";
        max-cache-size 256M;
        dnssec-validation auto;

        listen-on-v6 port 53 { any; };
        listen-on port 53 { any; };
        notify yes;
        version none;

};



acl "ff" {
        8.8.8.8;
        8.8.4.4;
        4.4.8.8;
};

acl "dd" {
        8.8.8.8;
};

acl "gw" {
        9.9.9.9;
};

view "default" {
        recursion yes;
        match-clients { any; };
        allow-recursion { localhost; localnets; };

        zone "13" {
                type master;
                file "/etc/namedb/master/default/13.DB";
                allow-query { any; localhost; localnets; ff; dd; gw; };
                allow-transfer { ff; };
                allow-update { localhost; gw; };
                also-notify { 9.9.9.9;};
        };

        zone "tt.spb.ru" {
                type master;
                file "/etc/namedb/master/default/tt.spb.ru.DB";
                allow-query { any; };
                allow-transfer { ff; };
                allow-update { localhost; };
        };

        zone "." {
                type hint;
                file "/etc/namedb/named.root";
        };

};

madforic

Same issue after upgrade to 2.5.0
unable to start bind

wrgraves

@viktor_g Ok, brought up a test machine and installed a fresh pfsense 2.5 and of course the caching bind config works so I restored my config and of course it gets the segment fault in named and dies so I decided to find an example install for bind, I used this one -> https://www.youtube.com/watch?v=Sgn4oNy85_o
And as I went thru it I corrected several mistakes in my zones. Then used Status/Services to restart named and it works now. It looks like a bad zone will segment fault and crash your bind. I've been using these zones for years and that never happened in the past. A new feature?
I put the changes in my production machine.
and now I am up!!!

matthijs

@viktor_g What mistakes were in your zones ? and how to correct if all this configuration gets generated by the webinterface ?

horrza

@wrgraves Thank you!

horrza

@matthijs "Name Server" and "Base Domain IP" was the problem in my case.

matthijs

@horrza

I cannot understand that is causing the issue in my case these fields will result in the following records in de zone file (fictional IP and FQDN)

@ IN NS nameserver.fqdn.com.
@ IN A 1.1.1.1

horrza

@matthijs

I did as shown in the video on YouTube https://www.youtube.com/watch?v=Sgn4oNy85_o&t=337s

wrgraves

@matthijs The video is a tutorial about configuring bind in pfsense and I just followed it while I looked at my config via the GUI. I wouldn't of even though some of the mistakes were mistakes. Like I put in the wrong base ip in the reverse zone and one of the reverse zones had localhost in the name of the nameserver and I changed it to 127.0.0.1. I cleared all the serial numbers so they were generated, probably no effect on that one. In my 2.16.172 reverse some I changed the first record from 1.2.16.172 to 1 PTR pfsense.localdomain. I increased the the Memory limit in the main config from 256M to 1024M, now that could of had an effect. Most of it was just little differences and all of the changes were made with the GUI.

wrgraves

Here's a diff of the bind part of my backed up config...
</serial>
<allowupdate>localhost,localnets,localdomain</allowup | <allowupdate>any</allowupdate>
<allowquery>localhost,localnets,localdomain</allowque | <allowquery>none,any</allowquery>
<allowtransfer>localhost,localnets,localdomain</allow | <allowtransfer>any</allowtransfer>
<hostname>1.2.16.172.in-addr.arpa.</hostname> | <hostname>1</hostname>
<resultconfig>JFRUTCAxRAo7CiRPUklHSU4gMi4xNi4xNzIuaW4 | <resultconfig>JFRUTCAxRAo7CiRPUklHSU4gMi4xNi4xNzIuaW4
<serial>3</serial> | <serial>2614104211</serial>
<allowupdate>localhost,localnets</allowupdate> | <allowupdate>any</allowupdate>
<allowquery>localhost,localnets</allowquery> | <allowquery>any</allowquery>
<allowtransfer>localhost,localnets</allowtransfer> | <allowtransfer>any</allowtransfer>
<row> <
<hostname>KB9UNZ.DDNS.WS</hostname> <
<hosttype>A</hosttype> <
<hostvalue></hostvalue> <
<hostdst>127.0.0.1</hostdst> <
</row> <
<customzonerecords>R1cxLkFNUFIuREFWRVMuTkVUIElOIEEgMT | <customzonerecords></customzonerecords>
<resultconfig>JFRUTCA0MzIwMAo7CiRPUklHSU4gbG9jYWxob3N | <resultconfig>JFRUTCA0MzIwMAo7CiRPUklHSU4gbG9jYWxob3N
> <rpz></rpz>
<serial>2</serial> | <serial>2614104300</serial>
<allowupdate>localhost,localnets</allowupdate> | <allowupdate>any</allowupdate>
<allowquery>localhost,localnets</allowquery> | <allowquery>any</allowquery>
<allowtransfer>localhost,localnets</allowtransfer> | <allowtransfer>any</allowtransfer>
<hostname>1.0.0.127.in-addr.arpa.</hostname> | <hostname>1</hostname>
<resultconfig>JFRUTCAxRAo7CiRPUklHSU4gMC4wLjEyNy5pbi1 | <resultconfig>JFRUTCAxRAo7CiRPUklHSU4gMC4wLjEyNy5pbi1
<wireguard> | <wireguard></wireguard>
</wireguard> <
root@ubt:~/Downloads#

Well that didn't turn out like I hoped but I deleted a couple of things too.

wrgraves

missed a line
<bind_ram_limit>256M</bind_ra | <bind_ram_limit>1024M</bind_r
Been marked as a spammer so I can't edit the previous entry. Note that you can turn off zones and that may help in debugging. Just go to the little box at the beginning of the zone and disable it and see if it stops crashing.

freebsd-man

Hi!

Could the usage of an additional ACL cause the problem?

Debian Discussion: Bug#980786: named: after upgrade to bind9=1:9.16.11-1 named is killed with status=11/SEGV

nordeep

@freebsd-man Thanks. It's make sense.

madforic

@freebsd-man That is the issue!
In my case I disabled any named acl and bind started as expected.
Named acls make sense only for master zones. Slave and forward zones works with named acls without proplems.

matthijs

Is there maybe a way to workaround for this ACL issue ? I have two ACLs and I really need them (one is an ACL containing secondary name servers who are allowed to do zone transfers, the other is an ACL containing hosts who are allowed to do dynamic updates)

Or should I wait till this bug is fixed and a new release is provided ?

md0

I'm not sure if I have the same issue, but after upgrading to 2.5.0, named service, along with several other downloaded packages, fail to start upon reboot. A manual start of the named service clears the blockage and all the other services then proceed to start normally.

No logs whatsoever are saved on the first (automatic) start attempt. Afterwards, no error is shown, I've tried to delete my only named ACL, but the problem persists. Reinstalling the Bind package is also of no use.

Any hints on how I could debug this further would be appreciated.

matthijs

I read that this Bind bug (bug 980786) where freebsd-man is referring to is already fixed.
Can Netgate update the Bind package to the latest version?

viktor_g

try to update it directly (on x86):

# pkg add -f https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/lmdb-0.9.28,1.txz
# pkg add -f https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/bind916-9.16.12.txz