Robert,
While all the advice provided is good, you might also send a suggestion
to bind9-bugs.
The "received control channel command" message would be more useful if
it included the peer address & port e.g.:
"... general: info: received control channel command 'reconfig' from
127.0.0.1:48466" .
That would avoid having to use tcpdump to identify the source of these
sorts of problems.
Other thoughts:
If you have selinux enabled, you can (temporarily) deny access to port
953 with a local policy module, and use the resulting audit log entries
to determine the command. To avoid service disruption, use setenforce 0
(permissive) for the duration. This is the simplest approach (fewest
tools, quickest & most certain results). But you do need to know how to
setup a LPM... and if you're not running selinux already, it can be a
hassle to setup. (I recommend doing it, but not in the middle of this
fire.)
Every 30 mins sounds like some sort of monitor. Check that named.conf
isn't changing (which could trigger such a monitor.) Or stop all system
management/monitoring packages until you find the culprit.
Consider inotify-tools. If a monitor is keeping an eye on bind, you
can catch it looking at (or touching) named's files.
lsof is a bit heavyweight for this. Consider ss -p (ss is part of
iproute2) if you have it.
A final thought - look for log file managers (e.g. logrotate). They may
be noticing named's file size & doing a reconfig to close/reopen the log
file. (In which case, report a bug in the log manager's config -
named's own log file management avoids all those hassles.)
Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 24-Aug-15 17:55, Mark Andrews wrote:
> The first thing I would do is make sure only the users you want to
> be able to use the rndc key can read it. I would then generate a
> new rndc key and configure both rndc and named to use it.
>
> If that doesn't work generate a new rndc.conf file with a different
> name that refers to a new rndc key. Teach named to use that key
> then update all the scripts that you know about to use the new
> rndc.conf file.
>
>rndc -c rndc.conf.path
>
> Mark
>
> In message <60946bf48ada4e6fb2ed7b0aa297d...@mxph4chrw.fgremc.it>, "Darcy
> Kevin
> (FCA)" writes:
>> Does the rndc protocol have a timeout? If so, what is it set to? I don't see
>> anything about a configurable timeout interval in the man pages for rndc or r
>> ndc.conf.
>>
>> What I'd probably do is turn off rndc in named.conf, set up a "dummy" server
>> to listen on port 953, which just accepts the connection, but doesn't respond
>> to anything sent to it. That means that whatever is sending this command is
>> going to be "stuck" for some period of time -- possibly infinitely -- waiting
>> for a response from the server. Then you can use something like "lsof" (whic
>> h I assume exists in Debian) to track down which process it is.
>>
>> - Kevin
>>
>> -Original Message-
>> From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.o
>> rg] On Behalf Of Robert Senger
>> Sent: Monday, August 24, 2015 5:02 PM
>> To: bind-users@lists.isc.org
>> Subject: Identify source of "rndc reconfig" command?
>>
>> Hi all,
>>
>> after upgrading from Debian Wheezy to Jessie, bind9 receives "rndc reconfig"
>> commands every 30 minutes. I've never seen this before. Some of my own script
>> s run "rndc restart/reload" after fiddling with network interfaces, but none
>> of these is the source of the observed 30 minutes interval. There are also no
>> cron jobs.
>>
>> In the bind9 logs I see this:
>>
>> 24-Aug-2015 22:53:43.431 general: info: received control channel command 'rec
>> onfig'
>> 24-Aug-2015 22:53:43.458 general: info: loading configuration from '/etc/bind
>> /named.conf'
>> ... [more than 350 lines reconfig log]
>>
>> Running tcpdump on the lo interface gives me this:
>>
>> root@prokyon:/etc/bind# tcpdump -i lo port 953
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode li
>> stening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
>> 21:23:35.071602 IP localhost.48466 > localhost.953: Flags [S], seq 3862717043
>> , win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 0,nop,wscale 5],
>> length 0
>> 21:23:35.071699 IP localhost.953 > localhost.48466: Flags [S.], seq 239114031
>> 2, ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr
>> 196635776,nop,wscale 5], length 0
>> 21:23:35.071821 IP localhost.48466 > localhost.953: Flags [.], ack 1, win 136
>> 6, options [nop,nop,TS val 196635776 ecr 196635776], length 0
>> 21:23:35.075355 IP localhost.48466 > localhost.953: Flags [P.], seq 1:148, ac
>> k 1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147
>> 21:23:35.075435 IP localho
