Logging question about message 'update-security: error: client update denied'

Josh Nielsen jnielsen at hudsonalpha.org
Mon May 16 23:08:21 UTC 2016


Could it maybe be dhcp related?

On Mon, May 16, 2016 at 6:03 PM, Josh Nielsen <jnielsen at hudsonalpha.org>
wrote:

> Thank you for the response Mark. I'm still a little confused at what this
> might mean though. Clearly the originating address is my slave DNS server
> (every single one of the messages say "error: client 10.20.0.101").
>
> Are you saying that some process other than named on the same server
> (10.20.0.101) is responsible for these messages (and is there a 'for
> instance' of what could do such a thing?), or that somehow other hosts are
> relaying their update requests (again: from what possible processes?)
> through my slave dns server? What can I look for to figure this out on my
> network?
>
> Thanks in advance for any clarifications.
>
> -Josh
>
> On Mon, May 16, 2016 at 4:24 PM, Mark Andrews <marka at isc.org> wrote:
>
>>
>> In message <CANX+b1K5Z28oqVnb7=
>> FxWGrHL5YSsg0Ear_fnnpYuDzJcDywNQ at mail.gmail.com>, Josh Nielsen writes:
>> > Hello,
>> >
>> > I have a message that has been showing up in my master DNS server's log
>> > over the past few weeks and I am wondering if I can find more verbose
>> > specifics from debugging messages in BIND somehow.
>> >
>> > The messsage looks like this:
>> >
>> > May 16 10:52:16 dns01 named[2591]: 16-May-2016 10:52:16.844
>> > update-security: error: client 10.20.0.101#34148: update 'my.domain/IN'
>> > denied
>>
>> It a UPDATE request being denied.  It will be some process other
>> than named sending the request unless you have configured named to
>> forward updates.
>>
>> In the best of worlds every machine would be updating its own PTR
>> records and keep its own addresses in the DNS up to date.
>>
>> Mark
>>
>> > The frequency of the messages is sporadic. Sometime two or three time
>> in an
>> > hour, sometimes once each hour, sometimes 2-3 hours go by before I see
>> one,
>> > but I get multiple a day.
>> >
>> > I take it that this means that for some reason the slave is trying to
>> > update the master with some entry, even though I haven't explicitly set
>> up
>> > my slave server to be capable of doing so (that I know of). I intended
>> to
>> > have the slaves only receive changes coming down from the master but
>> not to
>> > try pushing changes up.
>> >
>> > Here is the zone block for the domain in question in the master and
>> slave
>> > servers' /etc/named.conf:
>> >
>> > Master (10.20.0.110):
>> >
>> > zone "my.domain" in {
>> >         type master;
>> >         file "db.my.domain";
>> >         allow-transfer {
>> >                 10.20.0.100/32;
>> >                 10.20.0.101/32;
>> >         };
>> >         allow-update {
>> >                 key "xcat_key";
>> >         };
>> >         notify yes;
>> >         also-notify {10.20.0.100; 10.20.0.101;};
>> > };
>> >
>> > Slave #2 (10.20.0.101):
>> >
>> > zone "my.domain" in {
>> >         type slave;
>> >         file "slaves/db.my.domain";
>> >         masters {10.20.0.110;};
>> > };
>> >
>> > There are no complaints about Slave #1 in the master's log, though it is
>> > basically a clone of Slave #2. They provide name resolution for a
>> compute
>> > cluster and the cluster nodes point to both of them in their resolv.conf
>> > but in alternating order for load balancing purposes. Is there a way
>> that I
>> > can get more detail of what specifically the DNS slave server is trying
>> to
>> > update the master with (maybe via more verbose output on the slave
>> itself)?
>> >
>> > Master BIND version: BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
>> > Slave BIND version: BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6
>> >
>> > Thanks,
>> > Josh
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160516/7b7901cc/attachment-0001.html>


More information about the bind-users mailing list