KSK Rollover

Discussion:

KSK Rollover

Brent Swingle

2018-09-06 17:34:21 UTC

I recently received an email indicating that our DNS servers are not properly equipped for the planned KSK Rollover that is coming. It leads off with this line "On 11 October 2018, ICANN will change or "roll over" the DNSSEC key signing key (KSK) of the DNS root zone."

Reading through the email there are links on how to check our server setup and make adjustments. My specific question to the group is in regards to one of the steps outlined for checking the current configuration.

This is the link that outlines the server test steps:
https://www.icann.org/dns-resolvers-checking-current-trust-anchors

This is the command that does not work and the output received:
[***@ns2 ~]# rndc secroots
rndc: 'secroots' failed: permission denied
[***@ns2 ~]#

This are the versions that I am running:
[***@ns2 ~]# named -v
BIND 9.10.2-P4-RedHat-9.10.2-5.P4.fc22

Might anyone be able to tell me what adjustment I would need to make in order for this command to work properly so I can look at the output file and verify my config?

Thanks,

John W. Blue

2018-09-06 18:14:20 UTC

Permalink

As I personally understand it you can ignore this notice if:

a) you are not enforcing DNSSEC validation
b) if you are running a version of BIND that supports automatic KSK updates.

John

Sent from Nine<http://www.9folders.com/>
________________________________
From: Brent Swingle <***@havilandtelco.com>
Sent: Thursday, September 6, 2018 12:36 PM
To: bind-***@lists.isc.org
Subject: KSK Rollover

I recently received an email indicating that our DNS servers are not properly equipped for the planned KSK Rollover that is coming. It leads off with this line "On 11 October 2018, ICANN will change or "roll over" the DNSSEC key signing key (KSK) of the DNS root zone."

Reading through the email there are links on how to check our server setup and make adjustments. My specific question to the group is in regards to one of the steps outlined for checking the current configuration.

This is the link that outlines the server test steps:
https://www.icann.org/dns-resolvers-checking-current-trust-anchors

This is the command that does not work and the output received:
[***@ns2 ~]# rndc secroots
rndc: 'secroots' failed: permission denied
[***@ns2 ~]#

This are the versions that I am running:
[***@ns2 ~]# named -v
BIND 9.10.2-P4-RedHat-9.10.2-5.P4.fc22

Might anyone be able to tell me what adjustment I would need to make in order for this command to work properly so I can look at the output file and verify my config?

Thanks,

Evan Hunt

2018-09-06 18:22:10 UTC

Permalink

Post by Brent Swingle
rndc: 'secroots' failed: permission denied

Have you set up your server to accept rndc commands?

If not, run "rndc-confgen" and follow the directions.

--
Evan Hunt -- ***@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Brent Swingle

2018-09-06 20:32:38 UTC

Permalink

Evan,

I ran the command and followed the directions to build out rndc as you have suggested. However, I am not sure that it made much of a difference. I should have been a little clearer from the beginning. I had worked with rndc to issue other commands and had received what appeared to be valid responses as if rndc was functional. I had somewhat assumed that rndc was baked in behind the scenes and ready to go. Either way I it has a rndc.conf and is specified in named.conf at this point.

I have two of these servers that are identical from an SW perspective. As a test, I issued "rndc secroots" on the server that I have modified to configure rndc and observed the following lines appear in the /var/log/messages file. When I issued "rndc secroots" from the non-modified file I get the same 3 lines. It acts like the process is running but it is unable to write output to the named.secroots file.

Sep 6 14:33:13 ns2 named[31189]: received control channel command 'secroots'
Sep 6 14:33:13 ns2 named[31189]: could not open secroots dump file 'named.secroots': permission denied
Sep 6 14:33:13 ns2 named[31189]: dumpsecroots failed: permission denied

As a test, I manually created named.secroots with weakened permissions to see if that made a difference but it still won't print output to it.
[***@ns3 etc]# ls -lh named.secroots
-rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots

-----Original Message-----
From: Evan Hunt [mailto:***@isc.org]
Sent: Thursday, September 06, 2018 1:22 PM
To: Brent Swingle <***@havilandtelco.com>
Cc: bind-***@lists.isc.org
Subject: Re: KSK Rollover

Post by Brent Swingle
rndc: 'secroots' failed: permission denied

Have you set up your server to accept rndc commands?

If not, run "rndc-confgen" and follow the directions.
--
Evan Hunt -- ***@isc.org
Internet Systems Consortium, Inc.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Hugo Salgado-Hernández

2018-09-06 20:39:22 UTC

Permalink

Hi Brent.
In out CentOS box, the named.secroots file is written on
/var/named/

You should check permissions there too.

Hugo

Post by Brent Swingle
Evan,
I ran the command and followed the directions to build out rndc as you have suggested. However, I am not sure that it made much of a difference. I should have been a little clearer from the beginning. I had worked with rndc to issue other commands and had received what appeared to be valid responses as if rndc was functional. I had somewhat assumed that rndc was baked in behind the scenes and ready to go. Either way I it has a rndc.conf and is specified in named.conf at this point.
I have two of these servers that are identical from an SW perspective. As a test, I issued "rndc secroots" on the server that I have modified to configure rndc and observed the following lines appear in the /var/log/messages file. When I issued "rndc secroots" from the non-modified file I get the same 3 lines. It acts like the process is running but it is unable to write output to the named.secroots file.
Sep 6 14:33:13 ns2 named[31189]: received control channel command 'secroots'
Sep 6 14:33:13 ns2 named[31189]: could not open secroots dump file 'named.secroots': permission denied
Sep 6 14:33:13 ns2 named[31189]: dumpsecroots failed: permission denied
As a test, I manually created named.secroots with weakened permissions to see if that made a difference but it still won't print output to it.
-rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots
-----Original Message-----
Sent: Thursday, September 06, 2018 1:22 PM
Subject: Re: KSK Rollover

Post by Brent Swingle
rndc: 'secroots' failed: permission denied

Have you set up your server to accept rndc commands?
If not, run "rndc-confgen" and follow the directions.
--
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Brent Swingle

2018-09-06 20:58:03 UTC

Permalink

I moved the file from /etc to /var/named and now I get an additional error line printed in /var/log/messages.

Sep 6 15:44:40 ns3 named[15443]: received control channel command 'secroots'
Sep 6 15:44:40 ns3 named[15443]: could not open secroots dump file 'named.secroots': permission denied
Sep 6 15:44:40 ns3 named[15443]: dumpsecroots failed: permission denied
Sep 6 15:44:40 ns3 audit: <audit-1400> { write } for pid=15447 comm="named" name="named.secroots" dev="dm-0" ino=135707451 scontext=system_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0

This error also appears in the audit.log file and a search is pointing to SELinux as the hangup. Any pointers on dealing with SELinux would be appreciated.

type=AVC msg=audit(1536266680.663:75671): avc: denied { write } for pid=15447 comm="named" name="named.secroots" dev="dm-0" ino=135707451 scontext=system_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0

I left all of the permissions the same and I think they should be lenient enough:
[***@ns3 named]# ls -lh named.secroots
-rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots

-----Original Message-----
From: Hugo Salgado-Hernández [mailto:***@nic.cl]
Sent: Thursday, September 06, 2018 3:39 PM
To: Brent Swingle <***@havilandtelco.com>
Cc: Evan Hunt <***@isc.org>; bind-***@lists.isc.org
Subject: Re: [BIND] RE: KSK Rollover

Hi Brent.
In out CentOS box, the named.secroots file is written on
/var/named/

You should check permissions there too.

Hugo

Post by Brent Swingle
Evan,
I ran the command and followed the directions to build out rndc as you have suggested. However, I am not sure that it made much of a difference. I should have been a little clearer from the beginning. I had worked with rndc to issue other commands and had received what appeared to be valid responses as if rndc was functional. I had somewhat assumed that rndc was baked in behind the scenes and ready to go. Either way I it has a rndc.conf and is specified in named.conf at this point.
I have two of these servers that are identical from an SW perspective. As a test, I issued "rndc secroots" on the server that I have modified to configure rndc and observed the following lines appear in the /var/log/messages file. When I issued "rndc secroots" from the non-modified file I get the same 3 lines. It acts like the process is running but it is unable to write output to the named.secroots file.
Sep 6 14:33:13 ns2 named[31189]: received control channel command 'secroots'
Sep 6 14:33:13 ns2 named[31189]: could not open secroots dump file
dumpsecroots failed: permission denied
As a test, I manually created named.secroots with weakened permissions to see if that made a difference but it still won't print output to it.
-rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots
-----Original Message-----
Sent: Thursday, September 06, 2018 1:22 PM
Subject: Re: KSK Rollover

Post by Brent Swingle
rndc: 'secroots' failed: permission denied

Have you set up your server to accept rndc commands?
If not, run "rndc-confgen" and follow the directions.
--
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Carl Byington

2018-09-06 21:34:18 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Brent Swingle
-rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots

Does the 'named' user have write access to /var/named? The default
redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
the default redhat selinux config prevents named writing to /var/named.

chmod 770 /var/named
setsebool -P named_write_master_zones=true
rndc secroots

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAluRnR8ACgkQL6j7milTFsF2FgCfSt7RIVrO8lK8izQlNn9TadPp
F58Anj81TEmtg34Cpjhh3DqMWEQFUCxA
=NwIr
-----END PGP SIGNATURE-----

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Mark Elkins

2018-09-07 08:49:55 UTC

Permalink

It would probably have been more helpful (speeded up finding the
problem) if the error message "file 'named.secroots': permission denied"
also gave the directory name that it was trying to write to? Just a thought.
Sometimes we don't see the obvious.

Post by Brent Swingle
I moved the file from /etc to /var/named and now I get an additional error line printed in /var/log/messages.
Sep 6 15:44:40 ns3 named[15443]: received control channel command 'secroots'
Sep 6 15:44:40 ns3 named[15443]: could not open secroots dump file 'named.secroots': permission denied
Sep 6 15:44:40 ns3 named[15443]: dumpsecroots failed: permission denied
Sep 6 15:44:40 ns3 audit: <audit-1400> { write } for pid=15447 comm="named" name="named.secroots" dev="dm-0" ino=135707451 scontext=system_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0
This error also appears in the audit.log file and a search is pointing to SELinux as the hangup. Any pointers on dealing with SELinux would be appreciated.
type=AVC msg=audit(1536266680.663:75671): avc: denied { write } for pid=15447 comm="named" name="named.secroots" dev="dm-0" ino=135707451 scontext=system_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0
-rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots
-----Original Message-----
Sent: Thursday, September 06, 2018 3:39 PM
Subject: Re: [BIND] RE: KSK Rollover
Hi Brent.
In out CentOS box, the named.secroots file is written on
/var/named/
You should check permissions there too.
Hugo

Post by Brent Swingle
Evan,
I ran the command and followed the directions to build out rndc as you have suggested. However, I am not sure that it made much of a difference. I should have been a little clearer from the beginning. I had worked with rndc to issue other commands and had received what appeared to be valid responses as if rndc was functional. I had somewhat assumed that rndc was baked in behind the scenes and ready to go. Either way I it has a rndc.conf and is specified in named.conf at this point.
I have two of these servers that are identical from an SW perspective. As a test, I issued "rndc secroots" on the server that I have modified to configure rndc and observed the following lines appear in the /var/log/messages file. When I issued "rndc secroots" from the non-modified file I get the same 3 lines. It acts like the process is running but it is unable to write output to the named.secroots file.
Sep 6 14:33:13 ns2 named[31189]: received control channel command 'secroots'
Sep 6 14:33:13 ns2 named[31189]: could not open secroots dump file
dumpsecroots failed: permission denied
As a test, I manually created named.secroots with weakened permissions to see if that made a difference but it still won't print output to it.
-rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots
-----Original Message-----
Sent: Thursday, September 06, 2018 1:22 PM
Subject: Re: KSK Rollover

Post by Brent Swingle
rndc: 'secroots' failed: permission denied

Have you set up your server to accept rndc commands?
If not, run "rndc-confgen" and follow the directions.
--
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

--
Mark James ELKINS - Posix Systems - (South) Africa
***@posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/

Petr Mensik

2018-09-07 14:45:52 UTC

Permalink

Hi Mark,

Post by Mark Elkins
It would probably have been more helpful (speeded up finding the
problem) if the error message "file 'named.secroots': permission denied"
also gave the directory name that it was trying to write to? Just a thought.
Sometimes we don't see the obvious.

It is sort of obvious, if you know the details. Bind changes current
directory to the directory listed in directory option. It actually tries
to open file path "named.secroots", in that directory. In that regard,
it is precise. It is documented, but not very obvious on the first
glance, what it really means.

Post by Mark Elkins

Post by Brent Swingle
Evan,
I ran the command and followed the directions to build out rndc as you have suggested. However, I am not sure that it made much of a difference. I should have been a little clearer from the beginning. I had worked with rndc to issue other commands and had received what appeared to be valid responses as if rndc was functional. I had somewhat assumed that rndc was baked in behind the scenes and ready to go. Either way I it has a rndc.conf and is specified in named.conf at this point.
I have two of these servers that are identical from an SW perspective. As a test, I issued "rndc secroots" on the server that I have modified to configure rndc and observed the following lines appear in the /var/log/messages file. When I issued "rndc secroots" from the non-modified file I get the same 3 lines. It acts like the process is running but it is unable to write output to the named.secroots file.
Sep 6 14:33:13 ns2 named[31189]: received control channel command 'secroots'
Sep 6 14:33:13 ns2 named[31189]: could not open secroots dump file
dumpsecroots failed: permission denied
As a test, I manually created named.secroots with weakened permissions to see if that made a difference but it still won't print output to it.
-rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots
-----Original Message-----
Sent: Thursday, September 06, 2018 1:22 PM
Subject: Re: KSK Rollover

Post by Brent Swingle
rndc: 'secroots' failed: permission denied

Have you set up your server to accept rndc commands?
If not, run "rndc-confgen" and follow the directions.
--
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: ***@redhat.com PGP: 65C6C973
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Mark Elkins

2018-09-07 16:15:59 UTC

Permalink

I kinda also wonder why the command simply doesn't output to stdout by
default. The *only* reason I've ever run the command "rndc secroots" is
to look at the output, that is, checking for the correct DNSKEY
root-anchors - which I then need to use "cat" to see... if the file is
correctly created... and if I remember where to look for it.
If I wanted the output in a file, I can always redirect stdout.
Sending output to stdout allows me to easily "filter" the output as well
with other tools.

Perhaps Evan can comment?

Post by Petr Mensik
Hi Mark,

Post by Mark Elkins

Post by Brent Swingle
Evan,
I ran the command and followed the directions to build out rndc as you have suggested. However, I am not sure that it made much of a difference. I should have been a little clearer from the beginning. I had worked with rndc to issue other commands and had received what appeared to be valid responses as if rndc was functional. I had somewhat assumed that rndc was baked in behind the scenes and ready to go. Either way I it has a rndc.conf and is specified in named.conf at this point.
I have two of these servers that are identical from an SW perspective. As a test, I issued "rndc secroots" on the server that I have modified to configure rndc and observed the following lines appear in the /var/log/messages file. When I issued "rndc secroots" from the non-modified file I get the same 3 lines. It acts like the process is running but it is unable to write output to the named.secroots file.
Sep 6 14:33:13 ns2 named[31189]: received control channel command 'secroots'
Sep 6 14:33:13 ns2 named[31189]: could not open secroots dump file
dumpsecroots failed: permission denied
As a test, I manually created named.secroots with weakened permissions to see if that made a difference but it still won't print output to it.
-rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots
-----Original Message-----
Sent: Thursday, September 06, 2018 1:22 PM
Subject: Re: KSK Rollover

Post by Brent Swingle
rndc: 'secroots' failed: permission denied

Have you set up your server to accept rndc commands?
If not, run "rndc-confgen" and follow the directions.
--
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Tony Finch

2018-09-07 16:46:18 UTC

Permalink

Post by Mark Elkins
I kinda also wonder why the command simply doesn't output to stdout by
default.

Historical reasons :-) BIND 9.11 and later have `rndc managed-keys` which
is rather more user-friendly. I get the impression that the root rollover
guides are using `rndc secroots` because that works in all the versions
that support RFC 5011 so it ends up being simpler to explain.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
Lundy, Fastnet, Irish Sea: Northwest backing southwest 4 or 5, increasing 6 at
times. Moderate throughout in southwest Fastnet, but elsewhere slight or
moderate. Rain later. Good, occasionally poor later.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Mark Elkins

2018-09-07 17:05:09 UTC

Permalink

I'm aware of: rndc managed-keys status
I'm also aware of: rndc secroots -

(a Hypen at the end of "rndc secroots" will send output to stdout)

I'm just not sure how long the 'hyphen' argument has been around for but
vaguely remember a similar discussion from long ago.
It looks like someone else also asked the same question but wasn't
allowed to change the default behaviour. :-(

So, if you are having issues running "rndc secroots", a quick suggestion
would be to try appending a 'hyphen' ('-') as an additional argument and
see if that helps.

Post by Tony Finch

Post by Mark Elkins
I kinda also wonder why the command simply doesn't output to stdout by
default.

Evan Hunt

2018-09-07 17:50:20 UTC

Permalink

Post by Mark Elkins
I kinda also wonder why the command simply doesn't output to stdout by
default. The *only* reason I've ever run the command "rndc secroots" is
to look at the output, that is, checking for the correct DNSKEY
root-anchors - which I then need to use "cat" to see... if the file is
correctly created... and if I remember where to look for it.
If I wanted the output in a file, I can always redirect stdout.
Sending output to stdout allows me to easily "filter" the output as well
with other tools.
Perhaps Evan can comment?

For a long time, the text that could be sent back over the rndc channel
from named was limited to a smallish fixed-size buffer -- I think it was
2K or something. If an rndc command produced output, but we couldn't be
sure the output would be smaller than that buffer, we'd write it to a file
instead.

At some point -- in 9.11, I think? -- it occurred to us that the size
limitation wasn't a law of physics, and we could get rid of it. So now
there are several rndc commands that print useful amounts of text, but
since "secroots" already existed before that change, we left its default
behavior the same as it had been before, and added a "-" option to return
text over the command channel.

Brent Swingle

2018-09-07 02:05:23 UTC

Permalink

This matter has been resolved with input from Evan. I was able to add a file path for secroots to the named.conf file and push the output file to a temp directory that was not permission restricted.

secroots-file "/tmp/named.secroots" ;

Ultimately when I ran "rndc secroots" it created the output file here:

/tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots

The data in the file seems to be as desired if I understand the KSK Rollover test correctly, I should see 20326 which pertains to the new key:

[***@ns3 tmp]# cat named.secroots
06-Sep-2018 18:47:16.190

Start view internal-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-chaos

dumpsecroots failed: not found

I did not fully try Carl's input below but I believe it would have worked as well. I had performed a "chmod 770 /var/named" but I did not follow it up with the SELinux modification. The last error I had was SELinux barking so I'd anticipate his suggestion was the correct one.

Does the 'named' user have write access to /var/named? The default
redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
the default redhat selinux config prevents named writing to /var/named.

chmod 770 /var/named
setsebool -P named_write_master_zones=true
rndc secroots

Thanks everyone for assisting with this matter.

Browne, Stuart via bind-users

2018-09-07 03:10:58 UTC

Permalink

The kicker was probably this line:

Sep 6 15:44:40 ns3 audit: <audit-1400> { write } for pid=15447 comm="named" name="named.secroots" dev="dm-0" ino=135707451 scontext=system_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0

The SELinux context that BIND runs in on a red hat system doesn't have access to write to a file of etc_t. After moving the file to /var/named somewhere, a restorecon should have reset it to something like var_named_t or var_named_cache_t which it would have had access to write to.

From the line, 'permissive=0' so it suggests a SELinux-enforcing environment.
Stuart

From: bind-users [mailto:bind-users-***@lists.isc.org] On Behalf Of Brent Swingle
Sent: Friday, 7 September 2018 12:05 PM
To: bind-***@lists.isc.org
Subject: Re: [BIND] RE: KSK Rollover

This matter has been resolved with input from Evan. I was able to add a file path for secroots to the named.conf file and push the output file to a temp directory that was not permission restricted.

secroots-file "/tmp/named.secroots" ;

Ultimately when I ran "rndc secroots" it created the output file here:

/tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots

The data in the file seems to be as desired if I understand the KSK Rollover test correctly, I should see 20326 which pertains to the new key:

[***@ns3 tmp]# cat named.secroots
06-Sep-2018 18:47:16.190

Start view internal-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-chaos

dumpsecroots failed: not found

I did not fully try Carl's input below but I believe it would have worked as well. I had performed a "chmod 770 /var/named" but I did not follow it up with the SELinux modification. The last error I had was SELinux barking so I'd anticipate his suggestion was the correct one.

Does the 'named' user have write access to /var/named? The default
redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
the default redhat selinux config prevents named writing to /var/named.

chmod 770 /var/named
setsebool -P named_write_master_zones=true
rndc secroots

Thanks everyone for assisting with this matter.

Petr Mensik

2018-09-07 14:12:09 UTC

Permalink

Hi,

also a few notes to it.

Post by Brent Swingle
This matter has been resolved with input from Evan. I was able to add a file path for secroots to the named.conf file and push the output file to a temp directory that was not permission restricted.
secroots-file "/tmp/named.secroots" ;

Instead, "/var/named/data/named.secroots" or maybe
"/run/named/named.secroots" should be used.

In Fedora, it should already have write access to /var/named directory
itself also from daemon. Should be already for update on supported releases.

Post by Brent Swingle
/tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots
06-Sep-2018 18:47:16.190
Start view internal-in
./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed
Start view external-in
./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed
Start view external-chaos
dumpsecroots failed: not found
I did not fully try Carl's input below but I believe it would have worked as well. I had performed a "chmod 770 /var/named" but I did not follow it up with the SELinux modification. The last error I had was SELinux barking so I'd anticipate his suggestion was the correct one.
Does the 'named' user have write access to /var/named? The default
redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
the default redhat selinux config prevents named writing to /var/named.
chmod 770 /var/named
setsebool -P named_write_master_zones=true
rndc secroots

It should not be required on upcoming RHEL 7 versions.
named_write_master_zones would be turned on by default in next minor
release. Also permissions would be fixed to allow writing by default. It
would save us to replace all paths in config file to write into
/var/named/data subdirectory. I hope also to reduce the confusion.

Post by Brent Swingle
Thanks everyone for assisting with this matter.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users