Re: [BIND] RE: KSK Rollover
On Fri, Sep 07, 2018 at 06:15:59PM +0200, Mark Elkins wrote: > 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. -- Evan Hunt -- e...@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [BIND] RE: KSK Rollover
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.
On 09/07/2018 06:46 PM, Tony Finch wrote:
> Mark Elkins wrote:
>
>> 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.
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@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-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: [BIND] RE: KSK Rollover
Mark Elkins wrote: > 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.finchhttp://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-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [BIND] RE: KSK Rollover
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: { 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@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:hsalg...@nic.cl]
>>> Sent: Thursday, September 06, 2018 3:39 PM
>>> To: Brent Swingle
>>> Cc: Evan Hunt ; bind-users@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@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:e...@isc.org]
Sent: Thursday, September 06, 2018 1:22 PM
To: Brent Swingle
Cc: bind-users@lists.isc.org
Subject: Re: KSK Rollover
On Thu, Sep 06, 2018 at 05:34:21PM +, Brent Swingle wrote:
> This is the command that does not work and the output received:
> [root@ns2 ~]# rndc secroots
> rndc: 'secroots'
Re: [BIND] RE: KSK Rollover
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: { 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@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:hsalg...@nic.cl]
>> Sent: Thursday, September 06, 2018 3:39 PM
>> To: Brent Swingle
>> Cc: Evan Hunt ; bind-users@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@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:e...@isc.org]
>>> Sent: Thursday, September 06, 2018 1:22 PM
>>> To: Brent Swingle
>>> Cc: bind-users@lists.isc.org
>>> Subject: Re: KSK Rollover
>>>
>>> On Thu, Sep 06, 2018 at 05:34:21PM +, Brent Swingle wrote:
This is the command that does not work and the output received:
[root@ns2 ~]# rndc secroots
rndc: 'secroots' failed: permission denied
[root@ns2 ~]#
>>> Have you set up your server to accept rndc commands?
>>>
>>> If not, run "rndc-confgen" and follow the directions.
>>>
>>> --
>>> Evan Hunt -- e...@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@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
>>
>>
Re: [BIND] RE: KSK Rollover
Hi, also a few notes to it. Dne 7.9.2018 v 04:05 Brent Swingle napsal(a): > 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. > > > 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: > > [root@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 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. > > > > > 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 > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [BIND] RE: KSK Rollover
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.
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: { 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@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:hsalg...@nic.cl]
> Sent: Thursday, September 06, 2018 3:39 PM
> To: Brent Swingle
> Cc: Evan Hunt ; bind-users@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@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:e...@isc.org]
>> Sent: Thursday, September 06, 2018 1:22 PM
>> To: Brent Swingle
>> Cc: bind-users@lists.isc.org
>> Subject: Re: KSK Rollover
>>
>> On Thu, Sep 06, 2018 at 05:34:21PM +, Brent Swingle wrote:
>>> This is the command that does not work and the output received:
>>> [root@ns2 ~]# rndc secroots
>>> rndc: 'secroots' failed: permission denied
>>> [root@ns2 ~]#
>> Have you set up your server to accept rndc commands?
>>
>> If not, run "rndc-confgen" and follow the directions.
>>
>> --
>> Evan Hunt -- e...@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@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@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-users@lists.isc.org
Re: Frequent timeout
On Thu, Sep 6, 2018 at 5:56 PM John W. Blue wrote: So that file is full of nothing but queries and no responses which, sadly, is useless. Run: tcpdump -s0 -n -i eth0 port domain -w /tmp/domaincapture.pcap You don't need all of the extra stuff because -s0 captures the full packet. On 06.09.18 18:42, Alex wrote: This is the command I ran to produce the pcap file I sent: # tcpdump -s0 -vv -i eth0 -nn -w domain-capture-eth0-090518.pcap udp dst port domain and that is the problem. "dst port domain" captures packets going to DNS servers, not responses coming back. "-vv" and "-nn" are useless when producing packet capture and "-s0" is default for some time. I often add "-U" so file is flushed wich each packet. you can strip incoming queries by using filter "(src host 68.195.XXX.45 and dst port domain) or (src port domain and dst host 68.195.XXX.45)" I should also mention that, while eth0 is the physical device, there is a bridge set up to support virtual machines (none of which were active). Hopefully that's not the reason! (real IP obscured). not the reason, but using "-i br0" could be safer then. Note that the IP was seen in packet capture you have published, not needed to hide it now. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
