Re: Authoritative and caching
Sending from the correct alias this time!
On Sun, 16 Mar 2025 at 09:03, Greg Choules
wrote:
> Thank you.
> The problem is that named is running as user "bind" but that user
> doesn't have file system permissions to create and write to files (the .jnl
> and .jbk files at least) in places that it needs to be writable: the
> directories it's working in are owned by "root".
>
> You might also check what group the user "bind" is in using the command
> "id bind". It is probably (but not necessarily) in the group "bind" as
> well. Even though the directory "zones" has group write privilege, its
> parent directory doesn't.
>
> I would either change ownership of "/etc/bind" and all files and folders
> below that from "root" to "bind", or, if the group for user "bind" is also
> "bind", leave ownership as root but change group permissions to rwx for
> everything "/etc/bind" and below. You could try starting with just
> "/etc/bind" and see if that helps. Then continue down if not.
>
> Some more Linux-savvy people will no doubt have something to say on the
> matter :)
>
> Cheers, Greg
>
> On Sat, 15 Mar 2025 at 21:25, Danjel Jungersen via bind-users <
> bind-users@lists.isc.org> wrote:
>
>> Off-list I was asked.
>>
>> root@ns1:/etc/bind# ls -la
>> total 60
>> drwxr-sr-x 3 root bind 4096 Mar 15 16:31 .
>> drwxr-xr-x 71 root root 4096 Jan 6 08:40 ..
>> -rw-r--r-- 1 root root 2403 Jul 27 2024 bind.keys
>> -rw-r--r-- 1 root root 255 Jul 27 2024 db.0
>> -rw-r--r-- 1 root root 271 Jul 27 2024 db.127
>> -rw-r--r-- 1 root root 237 Jul 27 2024 db.255
>> -rw-r--r-- 1 root root 353 Jul 27 2024 db.empty
>> -rw-r--r-- 1 root root 270 Jul 27 2024 db.local
>> -rw-r--r-- 1 root bind 458 Jul 27 2024 named.conf
>> -rw-r--r-- 1 root bind 498 Jul 27 2024 named.conf.default-zones
>> -rw-r--r-- 1 root bind 737 Mar 13 08:41 named.conf.local
>> -rw-r--r-- 1 root bind 950 Jan 30 08:58 named.conf.options
>> -rw-r- 1 bind bind 100 Jan 3 15:27 rndc.key
>> drwxrwsr-x 2 root bind 4096 Mar 15 16:54 zones
>> -rw-r--r-- 1 root root 1317 Jul 27 2024 zones.rfc1918
>>
>> root@ns1:/etc/bind/zones# ls -la
>> total 20
>> drwxrwsr-x 2 root bind 4096 Mar 15 16:54 .
>> drwxr-sr-x 3 root bind 4096 Mar 15 16:31 ..
>> -rw-rw-r-- 1 root bind 445 Jan 5 17:58 db.192.168
>> -rw-rw-r-- 1 root bind 509 Jan 5 17:12 db.jg1.jungersen.dk
>> -rw-rw-r-- 1 root bind 681 Mar 15 16:54 db.jungersen.dk
>>
>> I was also aksed about the setgid bit, I have no reason/explanation for
>> it.
>> Nor do I have any special wishes, so if it is best practice to do it
>> differently, I can change it.
>>
>> Apparmor was also mentioned, I have no experience with that, and have not
>> changed it in any way (to my knowledge)...
>>
>> if I have opened up too much in my effort to make it work, please let me
>> know, I wish to keep it as tight as possible.
>>
>> :-)
>> Danjel
>>
>>
>> On 15-03-2025 17:31, Danjel Jungersen via bind-users wrote:
>>
>> I'm so sorry, but I have to trouble you guys again.
>>
>> The help below helped, I have no errors from checkconf or checkzone, but
>> from journalctl I get:
>> /etc/bind/zones/db.jungersen.dk.jbk: create: permission denied
>> and
>> /etc/bind/zones/db.jungersen.dk.signed.jnl: create: permission denied
>>
>> and some more, but I think these 2 are the causes.
>>
>> But if I try:
>> root@ns1:/etc/bind/zones# ps auxw|grep named
>> bind 57446 0.1 1.2 147948 48140 ?Ssl 17:12 0:01
>> /usr/sbin/named -f -4 -u bind
>> root 57472 0.0 0.0 6332 2036 pts/1S+ 17:21 0:00 grep
>> named
>>
>> It look to me like the user is "bind"
>>
>> I also have:
>> drwxrwsr-x 2 root bind 4096 Mar 15 16:54 zones
>>
>> I have added write permission for the bind group.
>>
>> I have also tried to change owner to bind, same result.
>>
>> I have .key .private and .state files is /var/cache/bind
>>
>> What does these errors mean?
>> I assume that the files that it tries to write are supposed to be
>> written(?)
>>
>> And why is it rejected?
>>
>> BR
>> Danjel
>> On 12-03-2025 23:49, Mark Andrews wrote:
>>
>> I shouldn’t have tried to write that on the phone from memory.
>>
>> dnssec-policy “unlimited” {
>> keys { csk lifetime unlimited algorithm ECDSAP256SHA256; };
>> };
>>
>> zone "jungersen.dk” {
>> type master;
>> file "/etc/bind/zones/db.jungersen.dk”;
>> allow-transfer { 192.168.20.11; };
>> dnssec-policy "unlimited";
>> };
>>
>> Mark
>>
>>
>> On 13 Mar 2025, at 09:13, Danjel Jungersen
>> wrote:
>>
>> On 20-02-2025 08:40, Mark Andrews wrote:
>>
>> The zone is available publicly, but from public serveres not hosted by me
>> (one.com).
>> And points to my external ip.
>> My internal bind redirects local traffic directly to local servers on local
>> ip's.
>>
>> DNSSEC is designed to stop spoofed answers being accepted. When you create
>> a local zone that overrides what is in the public zones you are effectively
>> spoofing answers. As you have a DNSSEC si
Re: Authoritative and caching
On 15-Mar-25 18:16, Lee wrote:
On Sat, Mar 15, 2025 at 5:25 PM Danjel Jungersen via bind-users
wrote:
Apparmor was also mentioned, I have no experience with that, and have not
changed it in any way (to my knowledge)...
On my machine,
$ journalctl -l | grep apparmor | grep bind |more
shows many lines like
Dec 14 08:00:12 spot audit[922]: AVC apparmor="DENIED"
operation="mknod" profile="named" name="/etc/bind/db.10.10.2.jbk"
pid=922 comm="isc-net-0002" requested_mask="c" denied_mask="c"
fsuid=116 ouid=116
Dec 14 08:00:12 spot audit[922]: AVC apparmor="DENIED"
operation="mknod" profile="named" name="/etc/bind/db.home.net.jbk"
pid=922 comm="isc-net-0003" requested_mask="c" denied_mask="c"
fsuid=116 ouid=116
/etc/apparmor.d/usr.sbin.named on my machine has
# /etc/bind should be read-only for bind
and I'm clearly violating that assumption :(
Rather than fix my bind config I fixed the apparmor config. If you go
that way remember to do
/etc/init.d/apparmor restart
to have the new apparmor rules take effect.
Regards,
Lee
I deal with selinux rather than apparmor, but the principles and
pitfalls are the same.
In the long run it's likely to be better to find a suitable
named-writable directory for your zone files. Or if your distribution
doesn't provide one, file a bug report.
With local policy patches, sooner or later an
upgrade/update/configuration (or staff) change will cause an issue. By
Murphy's law, at the most inconvenient time.
Treating zone file directories as read-only on "master" ("primary")
servers was a reasonable when most zone files were manually edited.
With UPDATE, and now more important, DNSSEC signing this isn't (and
shouldn't be) nearly as common. The advice to put these files in /etc
is out-of-date.
Any distribution that doesn't provide a security policy and directory
layout for these configurations is behind the times. So after checking
their documentation, file a bug report with them.
However, I'd be surprised if apparmor doesn't provide a suitable
directory, since slaves' / secondaries' zone files are always
writable...so it may simply be a documentation/default configuration issue.
Note that /etc/bind usually also contains the configurations files
(named.conf, named.conf.d, etc). And those SHOULD be read-only for
named. So making all of /etc/bind read-write defeats some of the
apparmor/selinux protection.
A typical writable location for zone files is /var/named. (Under
selinux, zone files are labeled, and whether they can be written is a
configuration switch. There should be an apparmor equivalent... )
ISC gave some webinars on "BIND 9 Security" a couple of years ago.
https://www.isc.org/blogs/bind-security-webinar-series-2021/ . There's
a recording of the one on apparmor that may be helpful. (I haven't
watched it, but the ISC webinars are usually well done.)
Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
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: Authoritative and caching
It does, and it follows the FHS, so not in /etc. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 16. 3. 2025, at 17:08, Timothe Litt via bind-users > wrote: > > In the long run it's likely to be better to find a suitable named-writable > directory for your zone files. Or if your distribution doesn't provide one, > file a bug report. > -- 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: Authoritative and caching
>I would either change ownership of "/etc/bind" and all files and folders
>below that from "root" to "bind", or, if the group for user "bind" is also
>"bind", leave ownership as root but change group permissions to rwx for
>everything "/etc/bind" and below. You could try starting with just
>"/etc/bind" and see if that helps. Then continue down if not.
>
>Some more Linux-savvy people will no doubt have something to say on the
>matter :)
I read somewhere online that it makes sense to use /var/lib/bind or
/var/cache/bind for signed zones.
???
If bind should be denied write access to /etc/... maybe this is the way to go?
:-)
Danjel
>
>Cheers, Greg
>
>On Sat, 15 Mar 2025 at 21:25, Danjel Jungersen via bind-users <
>bind-users@lists.isc.org> wrote:
>
>> Off-list I was asked.
>>
>> root@ns1:/etc/bind# ls -la
>> total 60
>> drwxr-sr-x 3 root bind 4096 Mar 15 16:31 .
>> drwxr-xr-x 71 root root 4096 Jan 6 08:40 ..
>> -rw-r--r-- 1 root root 2403 Jul 27 2024 bind.keys
>> -rw-r--r-- 1 root root 255 Jul 27 2024 db.0
>> -rw-r--r-- 1 root root 271 Jul 27 2024 db.127
>> -rw-r--r-- 1 root root 237 Jul 27 2024 db.255
>> -rw-r--r-- 1 root root 353 Jul 27 2024 db.empty
>> -rw-r--r-- 1 root root 270 Jul 27 2024 db.local
>> -rw-r--r-- 1 root bind 458 Jul 27 2024 named.conf
>> -rw-r--r-- 1 root bind 498 Jul 27 2024 named.conf.default-zones
>> -rw-r--r-- 1 root bind 737 Mar 13 08:41 named.conf.local
>> -rw-r--r-- 1 root bind 950 Jan 30 08:58 named.conf.options
>> -rw-r- 1 bind bind 100 Jan 3 15:27 rndc.key
>> drwxrwsr-x 2 root bind 4096 Mar 15 16:54 zones
>> -rw-r--r-- 1 root root 1317 Jul 27 2024 zones.rfc1918
>>
>> root@ns1:/etc/bind/zones# ls -la
>> total 20
>> drwxrwsr-x 2 root bind 4096 Mar 15 16:54 .
>> drwxr-sr-x 3 root bind 4096 Mar 15 16:31 ..
>> -rw-rw-r-- 1 root bind 445 Jan 5 17:58 db.192.168
>> -rw-rw-r-- 1 root bind 509 Jan 5 17:12 db.jg1.jungersen.dk
>> -rw-rw-r-- 1 root bind 681 Mar 15 16:54 db.jungersen.dk
>>
>> I was also aksed about the setgid bit, I have no reason/explanation for it.
>> Nor do I have any special wishes, so if it is best practice to do it
>> differently, I can change it.
>>
>> Apparmor was also mentioned, I have no experience with that, and have not
>> changed it in any way (to my knowledge)...
>>
>> if I have opened up too much in my effort to make it work, please let me
>> know, I wish to keep it as tight as possible.
>>
>> :-)
>> Danjel
>>
>>
>> On 15-03-2025 17:31, Danjel Jungersen via bind-users wrote:
>>
>> I'm so sorry, but I have to trouble you guys again.
>>
>> The help below helped, I have no errors from checkconf or checkzone, but
>> from journalctl I get:
>> /etc/bind/zones/db.jungersen.dk.jbk: create: permission denied
>> and
>> /etc/bind/zones/db.jungersen.dk.signed.jnl: create: permission denied
>>
>> and some more, but I think these 2 are the causes.
>>
>> But if I try:
>> root@ns1:/etc/bind/zones# ps auxw|grep named
>> bind 57446 0.1 1.2 147948 48140 ?Ssl 17:12 0:01
>> /usr/sbin/named -f -4 -u bind
>> root 57472 0.0 0.0 6332 2036 pts/1S+ 17:21 0:00 grep
>> named
>>
>> It look to me like the user is "bind"
>>
>> I also have:
>> drwxrwsr-x 2 root bind 4096 Mar 15 16:54 zones
>>
>> I have added write permission for the bind group.
>>
>> I have also tried to change owner to bind, same result.
>>
>> I have .key .private and .state files is /var/cache/bind
>>
>> What does these errors mean?
>> I assume that the files that it tries to write are supposed to be
>> written(?)
>>
>> And why is it rejected?
>>
>> BR
>> Danjel
>> On 12-03-2025 23:49, Mark Andrews wrote:
>>
>> I shouldn’t have tried to write that on the phone from memory.
>>
>> dnssec-policy “unlimited” {
>> keys { csk lifetime unlimited algorithm ECDSAP256SHA256; };
>> };
>>
>> zone "jungersen.dk” {
>> type master;
>> file "/etc/bind/zones/db.jungersen.dk”;
>> allow-transfer { 192.168.20.11; };
>> dnssec-policy "unlimited";
>> };
>>
>> Mark
>>
>>
>> On 13 Mar 2025, at 09:13, Danjel Jungersen
>> wrote:
>>
>> On 20-02-2025 08:40, Mark Andrews wrote:
>>
>> The zone is available publicly, but from public serveres not hosted by me
>> (one.com).
>> And points to my external ip.
>> My internal bind redirects local traffic directly to local servers on local
>> ip's.
>>
>> DNSSEC is designed to stop spoofed answers being accepted. When you create
>> a local zone that overrides what is in the public zones you are effectively
>> spoofing answers. As you have a DNSSEC signed public zone if you want to
>> have these spoofed answers accepted you need to do one of the following:
>>
>> 1) create a working chain of trust that links to your private zone content
>> Long 1 is the best long term solution
>>
>> So this is the way I will try to go.
>>
>> You currently have the following DS which means you are using
>> ECDSAP256SHA256 (13) as the DNSSEC key algorithm.
>> jungersen.dk. 7200 IN DS 26658 13
Re: Authoritative and caching
On 16-03-2025 21:40, Greg Choules wrote: Hi. From what others have said, that makes sense. For BIND's static files to be under /etc and operational files (zone data, journals etc.) to be somewhere else. What are the permissions on /var/lib/bind/ and/or /var/cache/bind? Both is root:bind and bind has write access. I have changed the named.conf.local and moved the db. file of the signed zone to /var/lib/bind and it seems to work. The K files show up in /var/cache/bind THANKS. Now I just need the rest. :-) Danjel -- 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
