[Support] Bind9


Recommended Posts

On 5/31/2022 at 5:21 PM, VRx said:

@rwysocki_bones

If You cleared config it is possible until there is no named.conf file.
You could try to start container, and then log in Web UI, there should be information about the need to create a configuration.
After this, supervisor should start without errors.

I've completely re-installed the docker container, fresh install.
It didn't help, restarting the server seemed to work, but it went down again (I think next time docker container was restarted)
I have 2 Unraid servers so I even tried to copy the known working config from the other server, but still failing. tried installing it as host'ed network and as br0 with static IP, didn't work either way.
only things I can think off is that the working server is running combination of older version unraid and this docker container.

server1:

UNRAID 6.9.2 with [pwa666/bind9@sha256:b76ee59003e8eb4cd5199f72c87f5c89903fabb9992d30d93126c0f6687fee9a]

 

server2:

URAID 6.10.1 with [pwa666/bind9@sha256:6e315ba61f7d29b2d1cdf0012109753c461666db1fceba687ff3fb209231d8b9] (one version behind)

Also I am scared to update server2 to current 6.10.2 as there's an warning message "WARNING: combination of NIC using tg3 driver and Intel VT-d enabled may cause DATA CORRUPTION on some platforms."

I am running PowerEdge R730 8xLFF currently running the internal Ethernet card, but will be adding an Mellanox MCX311A-XCAT

 

EDIT----
I've also found that server1 has 2 files inside appdata that the server2 does not:
managed-keys.bind
managed-keys.bind.jnl

Edited by rwysocki_bones
added info about the managed-keys
Link to comment

@rwysocki_bones
go to docker console and execute:
/usr/sbin/named -4 -c /etc/bind/named.conf -L /var/log/named.log
Wait about 1 minute, check if named is not running using ps aux command, and then paste here /var/log/named.log content.
 

10 hours ago, rwysocki_bones said:

I've also found that server1 has 2 files inside appdata that the server2 does not:
managed-keys.bind
managed-keys.bind.jnl

This files are created automatically when You initiate first configuration from WebUI (watch attached screen)

If You cleared all config, first of all, run bind container, go to webUI, Create Primary Configuration File, and then check if proces 'named' is running.
If it is running, send me PM, I try to help You to copy configuration or maybe configure one from them as master, and second as slave DNS (in this case you will have to edit zones configuration only on the master)

 

!!! You can't copy only particular config files, but some others not !!!
 

config.png

Link to comment

Progress! running your command gave me this in the log file, so it must be permissions issue, I am unsure what's wrong tho, I've noticed some of my appdata folders are root:root and some are nobody:users.

06-Jun-2022 01:04:36.847 general: error: directory '/etc/bind' is not writable
06-Jun-2022 01:04:36.847 config: error: /etc/bind/named.conf:6: parsing failed: permission denied
06-Jun-2022 01:04:36.848 general: critical: loading configuration: permission denied
# ls /mnt/user/appdata -l

drwxr-xr-x 1 nobody users  42 Jun  3 02:43 bind9/
# ls /mnt/user/appdata/bind9/ -l
-rw-r--r-- 1 nobody users 170 Jun  3 02:43 local.hosts
-rw-r--r-- 1 nobody users 513 Jun  3 02:38 named.conf

 

Link to comment
59 minutes ago, VRx said:

@rwysocki_bones paste ownership and privileges from Container Console:
 

ls -la /etc/bind

 

Did You create new config by WebUI like I asked in previous post?

# ls -la /etc/bind
drwxr-xr-x    1 99       users           42 Jun  3 02:43 .
drwxr-xr-x    1 root     root           746 Jun  6 01:02 ..
-rw-r--r--    1 99       users          170 Jun  3 02:43 local.hosts
-rw-r--r--    1 99       users          513 Jun  3 02:38 named.conf

Yes I have, I've fully reinstalled the application and removed the bind9 folder from appdata then installed the container from CA and then go to GUI and set it up

Link to comment
7 minutes ago, VRx said:

@rwysocki_bones

chown root:root /etc/bind/*
chmod 664 /etc/bind/*


And then try to run named using container console:
 

/usr/sbin/named -4 -c /etc/bind/named.conf -L /var/log/named.log

And then check /var/log/named.log

I've run the chown and chmod on the docker container, output from named:
 

06-Jun-2022 07:47:50.274 general: info: loading configuration from '/etc/bind/named.conf'
06-Jun-2022 07:47:50.275 general: error: directory '/etc/bind' is not writable
06-Jun-2022 07:47:50.275 config: error: /etc/bind/named.conf:6: parsing failed: permission denied
06-Jun-2022 07:47:50.276 general: critical: loading configuration: permission denied
06-Jun-2022 07:47:50.276 general: critical: exiting (due to fatal error)

and ls -la after:
 

#ls -la /etc/bind
total 8
drwxr-xr-x    1 99       users           42 Jun  3 02:43 .
drwxr-xr-x    1 root     root           746 Jun  6 01:02 ..
-rw-rw-r--    1 root     root           170 Jun  3 02:43 local.hosts
-rw-rw-r--    1 root     root           513 Jun  3 02:38 named.conf

and from the UNRAID cli:
 

# ls /mnt/user/appdata/bind9/ -la
total 8
drwxr-xr-x 1 nobody users  42 Jun  3 02:43 ./
drwxrwxrwx 1 nobody users 230 Jun  6 05:02 ../
-rw-rw-r-- 1 root   root  170 Jun  3 02:43 local.hosts
-rw-rw-r-- 1 root   root  513 Jun  3 02:38 named.conf


should i chown the bind9 folder as root:root?

  • Thanks 1
Link to comment

I tried to do few tests on unraid version 6.10 but there are so many bugs on various applications with this version that I went back to version 6.9.2.
Some problematic applications are necessary for me for everyday use of the server. In this situation I would have to spend a lot of time diagnosing problems and correcting them, but this is not my responsibility, apparently other developers are not interested in their applications.
There could be some issue with file priviliges (for example rndc key), but correcting it manually should help.

Link to comment
  • 3 weeks later...

Healthcheck has been added for new users who do a fresh install.

Sometimes I got signals about errors in the docker log telling that bind is not running, such a situation can take place and it is not a bad thing. After creating initial configuration using the GUI, there will stop logging this info.

For this purpose, a healthcheck has been added, which will signal when the docker status is healthy or not.
If it shows that it is healthy, you don't have to worry about errors in docker logs.

Link to comment
  • 3 months later...
  • 5 months later...

I'm running an old bind version from sameersbn/bind image that was last updated 3y ago:
 

BIND 9.16.1-Ubuntu (Stable Release) <id:d497c32>
webmin ver: 1.941

Is there a straight-forward enough way to upgrade to your image instead?
Note current bind installation configuration/appdata bound to /data in the container looks like:
 

┌─[server]─[/mnt/user/appdata/bind]
└──╼ + tree -L 3
.
|-- bind
|   |-- etc
|   |   |-- bind.keys
|   |   |-- db.0
|   |   |-- db.127
|   |   |-- db.255
|   |   |-- db.empty
|   |   |-- db.local
|   |   |-- db.root
|   |   |-- named.conf
|   |   |-- named.conf.default-zones
|   |   |-- named.conf.local
|   |   |-- named.conf.local~
|   |   |-- named.conf.options
|   |   |-- rndc.key
|   |   `-- zones.rfc1918
|   `-- lib
|       |-- mydomain.eu.hosts
|       `-- mydomain2.eu.hosts
`-- webmin
    `-- etc
        |-- acl
        |-- adsl-client
        |-- ajaxterm
        |-- apache
        |-- at
        |-- ...etc

 

Second, 2 years ago (near beginning of this thread) it was stated '- changed network mode to bridge as default' -- now it still defaults back to host network. Does it mean we should be running it in host network again?

Edited by tuxbass
Link to comment
  • 1 month later...

@tuxbass

there is no simple way to migrate
1. You should backup Your bind/etc
2. Run container from my image

3. Create config from GUI

4. Create zones

5. Compare and update configuration in named.conf* files
6. Copy CONTENT zone files

 

About Your second question: Host and custom bridge should work properly. Bridge could not work because there is dnsmasq listenning on port 53

Link to comment
On 5/5/2023 at 12:06 PM, VRx said:

@tuxbass

there is no simple way to migrate
1. You should backup Your bind/etc
2. Run container from my image

3. Create config from GUI

4. Create zones

5. Compare and update configuration in named.conf* files
6. Copy CONTENT zone files

 

About Your second question: Host and custom bridge should work properly. Bridge could not work because there is dnsmasq listenning on port 53

GUI is rather confusing to me. Is it okay to largely copy the config files over from the old instance?

 

There also are multiple db files missing compared to the old version - is this expected? These are files such as db.local, db.127, db.0, db.255 referenced from named.conf.default-zones:
 

// prime the server with knowledge of the root servers
zone "." {
    type hint;
    file "/etc/bind/db.root";    // !! note this one is equivalent to db.cache in your version!
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
    type master;
    file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
    type master;
    file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
    type master;
    file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
    type master;
    file "/etc/bind/db.255";
};

And last, was it your decision to depart from the old convention of splitting named.conf into separate files as
 

$ cat  named.conf

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones"

if so, how come?

Edited by tuxbass
Link to comment
7 hours ago, tuxbass said:

GUI is rather confusing to me. Is it okay to largely copy the config files over from the old instance?

So why You are using gui image? Get some bind9 image from docker hub
You can try to copy config files.

7 hours ago, tuxbass said:

There also are multiple db files missing compared to the old version - is this expected? These are files such as db.local, db.127, db.0, db.255

db.local and db.127 are files for loopback interface

db.0 and db.255 are for broadcast
You can create all of them but are not required to run the container, check their contents, you probably don't have entries there.
Maybe you haven't verified yet, but my image doesn't provide any configuration files or zone files.

I don't impose any configuration, you can create each zone, including loopback and broadcast, as you wish.

The named.conf file also doesn't come with the image, it's only created when you click after logging into the GUI.

7 hours ago, tuxbass said:

And last, was it your decision to depart from the old convention of splitting named.conf into separate files as

Bind is very flexible in terms of configuration, you can put the contents of all these files inside named.conf or include hundreds of files if that's more convenient for you.

Default configuration depends on the webmin, which in this case acts as webUI. I don't remember if the configuration is different for other base images,

I've made some tests on ubuntu, but alpine linux is much smaller.

I suppose that the creator of the image you used so far decided for you and used to include several configuration files in his image.

Link to comment
11 hours ago, VRx said:

So why You are using gui image? Get some bind9 image from docker hub

Ha, fair question!
Think I was confused about the interaction of webmin and bare bind9 and what the implications are.

I just amended the config files manually and all's well. Thanks!

  • Thanks 1
Link to comment
  • 6 months later...
  • 1 month later...

Hi, 

 

had been running this docker for more than a year now without any problems. Pulled the latest version today and now bind9 just won't start. Docker logs don't reveal much information:

 

2024-01-07 11:58:27,240 INFO Set uid to user 0 succeeded
2024-01-07 11:58:27,242 INFO supervisord started with pid 1
2024-01-07 11:58:28,244 INFO spawned: 'bind' with pid 42
2024-01-07 11:58:28,345 WARN exited: bind (exit status 1; not expected)
2024-01-07 11:58:29,347 INFO spawned: 'bind' with pid 76
2024-01-07 11:58:29,432 WARN exited: bind (exit status 1; not expected)
2024-01-07 11:58:31,435 INFO spawned: 'bind' with pid 110
2024-01-07 11:58:31,519 WARN exited: bind (exit status 1; not expected)
2024-01-07 11:58:34,523 INFO spawned: 'bind' with pid 144
2024-01-07 11:58:34,619 WARN exited: bind (exit status 1; not expected)
2024-01-07 11:58:35,620 INFO gave up: bind entered FATAL state, too many start retries too quickly
2024-01-07 12:07:03,156 WARN received SIGTERM indicating exit request

 

 

A simple check of bind9 config in webmin however did help:

 

The following errors were found in the BIND configuration file /etc/bind/named.conf or referenced zone files ..
/etc/bind/named.conf:9: option 'dnssec-enable' no longer exists

 

dnssec option is no longer supported by bind. Simply delete the line from /etc/bind/named.conf. 

 

Just in case anyone else just had the same issue. 

Edited by [email protected]
  • Thanks 2
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.