Caching-only Name server does Zone Updates

[Mark Andrews]

In message <001701c985ed$311198f0$f9281fac at wipro74039c7ca>, "Ashish" writes:
> Hi Barry,
> 
> Thank you for your reply.
> 
> There was a reverse lookup done as per the Debug content.
> We have 4 Name servers so there should be 4 response containing NS records
> in the Authority Section and the corresponding A records in the Additional
> Section.
> 
> But we have thousands of statement like 
> > Db_update
> > Match
> in the Debug file.

	The last development work for BIND 4 stopped in 1997 with
	the release of BIND 4.9.6.  That over a decade ago.  Later
	releases were to address security issues.

	8.53         (vixie    01-Jun-97):      --- 4.9.6 released ---

	At this point there is almost no one running it anymore as
	it is full of known security flaws.  Everyone has moved on.
	If you want help moving to BIND 9 we can do that.  Asking
	us to explain what debug messages mean is basically a waste
	of time for everyone.

	One last answer and that will be it for me.

	What you are seeing appears to be normal cache operation.

	Mark
 
> Kindly advice.
> 
> Kind Regards,
> Ashish
> -----Original Message-----
> Date: Tue, 03 Feb 2009 03:42:32 -0500
> From: Barry Margolin <barmar at alum.mit.edu>
> Subject: Re: Caching-only Name server does Zone Updates
> To: comp-protocols-dns-bind at isc.org
> Message-ID: <barmar-900C8B.03423203022009 at mara100-84.onlink.net>
> 
> In article <gm8o6b$1vav$1 at sf1.isc.org>, "Ashish" <ashish.rao at wipro.com> 
> wrote:
> 
> > Thank you Mark,
> > 
> > Doupdate is followed by lot of statements like 
> > 
> > Db_update
> > Match
> > 
> > Please see the content below.
> > =========================================================================
> > Doupdate(zone 0, savens x, flags y)
> > Doupdate: dname 21.in-addr.arpa type 6 class 1 ttl 600
> > Db_update(21.in-addr.arpa, 0x12345, 0x56789, 087, 0x76543) match(0x9b430,
> 1,
> > 6) 1, 6
> > db_update: flags = 0x19, sizes = 71, 71 (1)
> > match(0x9123v, 1, 6) 1, 6
> > db_update: flags = 0x19, sizes = 71, 71 (1)
> > match(0x9sd33, 1, 6) 1, 6
> > db_update: flags = 0x19, sizes = 71, 71 (1)
> > match(0xdg6d8, 1, 6) 1, 6
> > db_update: flags = 0x19, sizes = 71, 71 (1)
> > match(0x6abde, 1, 6) 1, 6
> > ==========================================================================
> > 
> > Please correct me if I am wrong, I thought that for cache update it should
> > update only one record. So why so many updates are been made.
> 
> The response probably contained NS records in the Authority Section and 
> the corresponding A records in the Additional Section.  These update the 
> cache as well.
> 
> -- 
> Barry Margolin, barmar at alum.mit.edu
> Arlington, MA
> *** PLEASE don't copy me on replies, I'll read them in the group ***
> 
> 
> 
> Please do not print this email unless it is absolutely necessary. 
> 
> The information contained in this electronic message and any attachments to t
> his message are intended for the exclusive use of the addressee(s) and may co
> ntain proprietary, confidential or privileged information. If you are not the
>  intended recipient, you should not disseminate, distribute or copy this e-ma
> il. Please notify the sender immediately and destroy all copies of this messa
> ge and any attachments. 
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should 
> check this email and any attachments for the presence of viruses. The company
>  accepts no liability for any damage caused by any virus transmitted by this 
> email. 
> 
> www.wipro.com
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org