Caching-only Name server does Zone Updates

[Ashish]

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.

Please advice.

Thanks a lot
Ashish

-----Original Message-----
From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org] 
Sent: Tuesday, February 03, 2009 11:32 AM
To: Ashish
Cc: Niall.oReilly at ucd.ie; bind-users at lists.isc.org
Subject: Re: Caching-only Name server does Zone Updates 


In message <009201c985c0$aff05cb0$f9281fac at wipro74039c7ca>, "Ashish" writes:
> Hello All,
> 
> Thank you for your replies.
> 
> Our configuration file is fairly simple (I have changed the domain name
for
> security). 

	You care about security yet you run BIND 4?
 
> domain          example.group.net                                         
> cache           .                            /etc/dnscache  
> 
> We use BIND 4. Actually our DNS was doing lot of CPU utilization and when
we
> started it in Debug mode we found that there was a reverse lookup for some
> IP address which was in the dnscache file. (dnscache is the root hint
file)
> 
> This started zone updates, as we can observe in the debug file which calls
> function db_update()
> 
> Here is the debug file content (I have modified the IP address for
security
> reasons. Here 21.x.x.x is one of the entries in dnscache file. I mean that
> there was a network address starting with 21 in our dnscache file)
> 
> dgram from 1.2.3.4, 22222 (2222)
>  ns_req()
>  req: nlookup(5.6.7.21.in-addr.arpa) id 111 type=11
>  req: found '5.6.7.21.in-addr.arpa' as '21.in-addr.arpa' (cname=0)
>  findns: np 0x6b41e
>  findns: 2 NS's added for '21'
>  ns_forw()
>  qnew(x45gte8)
>  nslookup(nsp=x2433d,qp=xfdgfv4)
>  nslookup: NS server01.example.grp.net c1 t2 (x0)
>  nslookup: 1 ns addrs
>  nslookup: NS cerver01.example.grp.net c1 t2 (x0)
>  nslookup: 2 ns addrs
>  nslookup: 2 ns addrs total
>  retrytime: nstime 0ms.
>  schedretry(0x1dfd8, 4sec)
> 
> Dgram from 21.x.x.x
> Ns_req()
> Qfindid(12345)
> USER response nsid=xxxx id xxxx
> Respose from upexpected source 21.x.x.x
> Stime zzzzz/zzzzz now yyyyyy/yyyyyy rtt x
> NS #2 addr 21.x.x.x used rtt y
> NS #1 21.x.x.x rtt now z
> Resp: ancount 0, aucount 1, arcount 0
> 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)
> 
> This is strange, there was NSLOOKUP for some IP 5.6.7.21 which caused zone
> updates and we do not have any zone specified in our configuration file.

	zone 0 is the cache.  The cache was updated.

	Mark
 
> Kindly advice
> 
> Thanks 
> Ashish
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message 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