Denied Update Errors on Secondary Servers

Mark_Andrews at isc.org Mark_Andrews at isc.org
Tue Aug 28 14:14:06 UTC 2001


	Given I can't seem to get a answer from dallas.jhuapl.edu
	I'd look to see why it is failing to respond causing the
	DHCP server to fallover to the secondaries.

	BIND 8 does not support forwarding of UPDATES and will
	always respond with REFUSED (pre 8.2.3) / NOTIMPL (8.2.3
	and above).

	You need to go to BIND 9 if you require UPDATES to be
	forwarded note however that update forwarding has to be
	enabled.  It is off by default for security reasons.  See
	ARM for more details.

	By default the update subroutines will attempt to send the
	update to the primary server for the zone based on the NS
	and SOA content (MNAME).  If the MNAME is not a nameserver
	or it fails to respond the other servers will be tried in
	turn on the assumption that a firewall exists or there is
	a stealth primary.

	Mark

> 
> Lately, I have been seeing a lot of the following type of messages
> 
> 17-Aug-2001 11:33:30.192 denied update from [128.244.80.51].35631 for
> "244.128.i
> n-addr.arpa"
> 
> After tracing down the source, I found it was another group's AIX DHCP
> server.  We began seeing this after the admin had configured the DHCP server
> to update their client's PTR record; thus why I surmise I'm only seeing the
> error for the reverse zone.  Initially after working with the admin we
> thought that perhaps since the DHCP server had our secondary servers listed
> in the /etc/resolv.conf it was trying those first.  The admin proceeded to
> remove the secondary servers from /etc/resolv.conf and only list the primary
> server where it is allowed to do the updates. At first it seemed like that
> fixed the problem but then it starting appearing again. However, it's not
> very consistent. It might happen today but then not again for another 3 days
> or it may happen the next day.  No changes have been made on the DHCP
> server.  We've been trying to pinpoint what is causing the error.  We're
> close to running a trace to try and track down what is causing but thought
> perhaps there's something else we're missing that might be the cause. Any
> insight, etc would be appreciated.
> 
> Thanks,
> 
> 
> 
> 
> Bill Smith
> <mailto:bill.smith at jhuapl.edu> 
> The Johns Hopkins University                    Washington DC: 240-228-5523
> Applied Physics Laboratory                      MD: 443-778-5523
> 11100 Johns Hopkins Road                        Fax: 443-778-5727
> Laurel, MD 20723-6099 					Web:
> http://www.jhuapl.edu/                         
> 
> 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org


More information about the bind-users mailing list