Denied Update Messages On Secondary Servers

[Smith, William E. (Bill), Jr.]

Well wasn't paying attention to what message I was replying to so as to
hopefully avoid any confusion I'll reply to the correct one!


I have some additional information that may or may not shed lite.  I've
tracked this problem a little further and found that two of the offending
hosts/IP's are frequent offenders.  When I looked into exactly what they
were(platform, etc), I found one was a static NT 4 server running some
flavor of SNMP while the other was a W2K server running some flavor of SNMP.
Both of these are statically defined clients and not DHCP.  Is it possible
that something in the SNMP software is triggering these update attempts to
the secondary?  Also, these offending IP's do not make attempts to update on
all of our secondaries though sometimes this is the case. 

Bill

-----Original Message-----
From: Jim Reid [mailto:jim at rfc1035.com] 
Sent: Tuesday, July 17, 2001 12:42 PM
To: Smith, William E. (Bill), Jr.
Cc: bind-users at isc.org
Subject: Re: Denied Update Messages On Secondary Servers


>>>>> "Bill" == Smith, William E (Bill), <Bill.Smith at jhuapl.edu> writes:

    Bill> I have logging configured on my secondaries such that any
    Bill> unapproved updates, etc are written to a log file.  I've
    Bill> noticed that a lot of denied from IP for zone type messages
    Bill> on each of my secondaries.  What I don't understand is why
    Bill> I'm seeing them on my secondaries since the clients should
    Bill> be going to the primary to try and update.

There is no underestimating the stupidity of DNS client software. Especially
the stuff coming from a company in the top left hand corner of the USA.

The dynamic update protocol allows update requests to be sent to a slave
server. It is supposed to forward them to the master. This didn't work in
BIND8, so sending updates to a slave server then wasn't a good idea. Update
forwarding does work properly in BIND9. [Well, in 9.1 upwards IIRC.] However
if this is used, it should be used in conjunction with TSIG authentication,
not on IP address. IP addresses are easily faked, so using them for
authentication is not wise at the best of times. With update forwarding,
address based authentication means that it's the slave server which forwards
the request that gets authenticated, not the client that sent the request to
the slave.