Strange behaviour after nsupdate
ericham at usc.edu
Tue Nov 9 21:34:41 UTC 2010
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
>> ls -l /etc/bind/dyn/my.zone.tld.zone*
>> -rw-r--r-- 1 named named 386 2010-11-07 11:22
>> -rw-rw---- 1 root named 2636 2010-11-07 11:08
>> 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
> 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>
You are sharing 1 zone file between 2 views? If so, I don't think this
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.
More information about the bind-users