Strange behaviour after nsupdate

[Eric Ham]

On 11/ 9/10 01:25 PM, Christian Ruppert wrote:
> On 11/09/2010 10:11 PM, Christian Ruppert wrote:
>> Hey guys,
>>
>> I have a zone that I update remotely via nsupdate. When I update the
>> zone and query it internal (view) I get the correct answer but when I do
>> a query from outside I still get the old A record.
>> So the same nameserver gives different answers.
>>
>> "dig my.zone.tld A +short @ns.zone.tld".
>>
>> I have a internal view as well as a external view. The biggest
>> difference between those two is that the external view has recursion,
>> additional-from-auth and additional-from-cache disabled.
>>
>> Both views include the hint (root.cache) and the same zones.conf.
>> The internal view includes additionally 127.in-addr.arpa and a localhost
>> zone.
>>
>> ls -l /etc/bind/dyn/my.zone.tld.zone*
>> -rw-r--r-- 1 named named  386 2010-11-07 11:22
>> /etc/bind/dyn/my.zone.tld.zone
>> -rw-rw---- 1 root  named 2636 2010-11-07 11:08
>> /etc/bind/dyn/my.zone.tld.zone.jnl
>>
>> Any ideas what could be wrong?
>>
> 
> I forgot to mention that I use bind-9.7.2-P2.
> Removing the journal (as a workaround for now) helps although it's no
> solution.
> The nsupdate commands are:
> server ns.zone.tld
> zone my.zone.tld
> update delete my.zone.tld <TTL> A <OLDIP>
> update add my.zone.tld <TTL> A <NEWIP>
> send

You are sharing 1 zone file between 2 views? If so, I don't think this 
is recommended.

What happens if you flush the cache on the external view and/or 
completely stop and start named? My guess is that it will then resolve 
correctly? If that works then it's probably because your connection to 
nsupdate matches your internal view and so only the cache for the 
internal view gets updated. The external view might eventually update 
after the TTL expires or you manually flush the cache or do a restart.

Regards,
-Eric