Identify source of "rndc reconfig" command?

Timothe Litt litt at acm.org
Tue Aug 25 09:36:11 UTC 2015


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 <60946bf48ada4e6fb2ed7b0aa297d5fa at 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-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.o
>> rg] On Behalf Of Robert Senger
>> Sent: Monday, August 24, 2015 5:02 PM
>> To: bind-users at 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 at 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 localhost.953 > localhost.48466: Flags [.], ack 148, win 1
>> 399, options [nop,nop,TS val 196635777 ecr 196635777], length 0
>> 21:23:35.115513 IP localhost.953 > localhost.48466: Flags [P.], seq 1:180, ac
>> k 148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 179
>> 21:23:35.115583 IP localhost.48466 > localhost.953: Flags [.], ack 180, win 1
>> 399, options [nop,nop,TS val 196635787 ecr 196635787], length 0
>> 21:23:35.116084 IP localhost.48466 > localhost.953: Flags [P.], seq 148:320, 
>> ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 1
>> 72
>> 21:23:35.116130 IP localhost.953 > localhost.48466: Flags [.], ack 320, win 1
>> 433, options [nop,nop,TS val 196635787 ecr 196635787], length 0
>> 21:23:37.092444 IP localhost.953 > localhost.48466: Flags [P.], seq 180:363, 
>> ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 1
>> 83
>> 21:23:37.094097 IP localhost.48466 > localhost.953: Flags [F.], seq 320, ack 
>> 363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0
>> 21:23:37.130367 IP localhost.953 > localhost.48466: Flags [.], ack 321, win 1
>> 433, options [nop,nop,TS val 196636291 ecr 196636281], length 0
>> 21:23:37.829134 IP localhost.953 > localhost.48466: Flags [F.], seq 363, ack 
>> 321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0
>> 21:23:37.829288 IP localhost.48466 > localhost.953: Flags [.], ack 364, win 1
>> 433, options [nop,nop,TS val 196636465 ecr 196636465], length 0
>>
>> Is there a way to identify the source of these reconfig commands? It's really
>>  annoying as it messes up the log with 350 useless lines every 30 minutes.
>>
>> Thanks!
>>
>> Robert
>>  
>>
>> --
>> Robert Senger
>>
>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4994 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150825/22019a49/attachment.bin>


More information about the bind-users mailing list