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 <ma...@isc.org> wrote: > > In message <CANX+b1K5Z28oqVnb7= > fxwgrhl5yssg0ear_fnnpyudzjcdy...@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: ma...@isc.org >
_______________________________________________ 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