[BIND] RE: KSK Rollover

Mark Elkins mje at posix.co.za
Fri Sep 7 16:15:59 UTC 2018


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?


On 09/07/2018 04:45 PM, Petr Mensik wrote:
> Hi Mark,
>
> Dne 7.9.2018 v 10:49 Mark Elkins napsal(a):
>> 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.
>>
>> On 09/06/2018 10:58 PM, Brent Swingle wrote:
>>> 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:
>>> [root at 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:hsalgado at nic.cl] 
>>> Sent: Thursday, September 06, 2018 3:39 PM
>>> To: Brent Swingle <brent at havilandtelco.com>
>>> Cc: Evan Hunt <each at isc.org>; bind-users at 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
>>>
>>> On 20:32 06/09, Brent Swingle wrote:
>>>> 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.
>>>> [root at 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:each at isc.org]
>>>> Sent: Thursday, September 06, 2018 1:22 PM
>>>> To: Brent Swingle <brent at havilandtelco.com>
>>>> Cc: bind-users at lists.isc.org
>>>> Subject: Re: KSK Rollover
>>>>
>>>> On Thu, Sep 06, 2018 at 05:34:21PM +0000, Brent Swingle wrote:
>>>>> This is the command that does not work and the output received:
>>>>> [root at ns2 ~]# rndc secroots
>>>>> rndc: 'secroots' failed: permission denied
>>>>> [root at ns2 ~]#
>>>> Have you set up your server to accept rndc commands?
>>>>
>>>> If not, run "rndc-confgen" and follow the directions.
>>>>
>>>> --
>>>> Evan Hunt -- each at 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-users at lists.isc.org
>>>> 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-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users

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



More information about the bind-users mailing list