Denied Update Errors on Secondary Servers

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

I would expect anyone outside our network not to get a response from Dallas
since we aren't allowing external queries against it.  Our 3 secondaries are
what we have available for anyone to query against.etc and what we have
registered with Network Solutions. Internal clients can query with no
problems.  Our primary is a third party DNS server that we really don't want
our clients querying against..directly anyhow. Instead we want them to go to
our secondaries which they are.  Hopefully this sheds a little more light.
BIND 9 is in the works and is something we're very much looking forward to.

Bill

-----Original Message-----
From: Mark.Andrews at isc.org [mailto:Mark.Andrews at isc.org] 
Sent: Tuesday, August 28, 2001 10:14 AM
To: Smith, William E. (Bill), Jr.
Cc: bind-users at isc.org
Subject: Re: Denied Update Errors on Secondary Servers



	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