How to force named to write dynamic data
Bob Vance
bobvance at alumni.caltech.edu
Sat Jan 13 21:52:35 UTC 2001
I've tracked the problem down.
It requires the following:
1. 'nsupdate' name has encoded blanks, "\032"
2. kill -9 <named>
after the dynamic update
3. restart 'named' and let it load from the *.log files
(I know you'll say quit worrying about blanks, but if we're
gonna try to handle them, then we should do it correctly.
)
The problem appears to be a bug in 'named' reloading info from the log
files after a restart *if* the name has encoded blanks in it, "\032"
%~/
It drops the "\" from the "\032" *without* decoding it into a blank,
simply leaving a "032" .
Note, that if you change step 2, above, to a normal
kill <named> #(or 'ndc stop' )
then, 'named' correctly updates the dynamic zone files, removes the log
files, and terminates.
I suspect that this is because, in this case, he's probably taking data
out of memory. In the "restart" case he's loading from the log files
and
incorrectly drops the "\".
Probably just a minor omission in the latter code.
I haven't looked, but it may be dropping all "\". It probably thinks
that it
can ignore the "\" when loading into memory, since it can carry invalid
chars
there. I suspect that the code just forgot about \nnn decoding.
==========================
Supporting info:
==========================
Here is the 'nsupdate' file:
herman# cat xx
update delete harixx.dynamic.vance. 3600 IN A 192.168.1.45
update add harixx.dynamic.vance. 3600 IN A 192.168.1.45
update delete ha\032ri\032xx.dynamic.vance. 3600 IN A 192.168.1.45
update add ha\032ri\032xx.dynamic.vance. 3600 IN A 192.168.1.45
!!!!scenario 1
Start 'named' (8.2.2-p5, 8.2.2-p7, and 8.2.3T9B all behave the same way)
After Step 1, running 'nsupdate xx',
we can see the records in the log files :
herman# nsupdate xx
herman# grep -i -E 'ha.*xx' *
vance-dynamic.log:update: {delete} harixx.dynamic.vance. IN A
192.168.1.45
vance-dynamic.log:update: {add} harixx.dynamic.vance. 3600 IN A
192.168.1.45
vance-dynamic.log:update: {delete} ha\032ri\032xx.dynamic.vance. IN A
192.168.1.45
vance-dynamic.log:update: {add} ha\032ri\032xx.dynamic.vance. 3600 IN A
192.168.1.45
Also, a lookup on the "blank" name works:
herman# dig 'ha ri xx.dynamic.vance.'
...
;; QUERY SECTION:
;; ha\032ri\032xx.dynamic.vance, type = A, class = IN
;; ANSWER SECTION:
ha\032ri\032xx.dynamic.vance. 1H IN A 192.168.1.45
...
After a
kill <named> #( or 'ndc stop' )
we can see that the zone files are "correctly" updated, to the
extent that the "\032" are preserved:
herman# grep -i -E 'ha.*xx' *
vance-dynamic:ha\032ri\032xx 3600 IN A 192.168.1.45
;Cl=2
vance-dynamic:harixx 3600 IN A 192.168.1.45 ;Cl=2
!!!!scenario 2
Now, after cleaning up the files, we try the same scenario, substituting
a
'kill -9' to blow up 'named'.
Start 'named' , then
herman# nsupdate xx
herman# grep -i -E 'ha.*xx' *
vance-dynamic.log:update: {delete} harixx.dynamic.vance. IN A
192.168.1.45
vance-dynamic.log:update: {add} harixx.dynamic.vance. 3600 IN A
192.168.1.45
vance-dynamic.log:update: {delete} ha\032ri\032xx.dynamic.vance. IN A
192.168.1.45
vance-dynamic.log:update: {add} ha\032ri\032xx.dynamic.vance. 3600 IN A
192.168.1.45
Again, the log files have the data.
And a check of the cache reveals:
herman# rm /var/tmp/named_dump.db ; ndc dumpdb
Database dump initiated.
herman# grep -i -E 'ha.*xx' /var/tmp/named_dump.db
ha\032ri\032xx 3600 IN A 192.168.1.45 ;Cl=2
harixx 3600 IN A 192.168.1.45 ;Cl=2
ha\032ri\032xx 3600 IN CNAME ha\032ri\032xx.dynamic.vance.
;Cl=4
and lookup still works:
herman# dig 'ha ri xx.dynamic.vance.'
...
;; QUERY SECTION:
;; ha\032ri\032xx.dynamic.vance, type = A, class = IN
;; ANSWER SECTION:
ha\032ri\032xx.dynamic.vance. 1H IN A 192.168.1.45
Now,
kill -9 <named> # blow it out of the water !!!!!!!!!!!!
The log files *still* have the data ('named' didn't have a chance
to update the zone files and remove the logs):
herman# grep -i -E 'ha.*xx' *
vance-dynamic.log:update: {delete} harixx.dynamic.vance. IN A
192.168.1.45
vance-dynamic.log:update: {add} harixx.dynamic.vance. 3600 IN A
192.168.1.45
vance-dynamic.log:update: {delete} ha\032ri\032xx.dynamic.vance. IN A
192.168.1.45
vance-dynamic.log:update: {add} ha\032ri\032xx.dynamic.vance. 3600 IN A
192.168.1.45
Restart 'named'
Notice that the log entries are still there:
herman# grep -i -E 'ha.*xx' *
vance-dynamic.log:update: {delete} harixx.dynamic.vance. IN A
192.168.1.45
vance-dynamic.log:update: {add} harixx.dynamic.vance. 3600 IN A
192.168.1.45
vance-dynamic.log:update: {delete} ha\032ri\032xx.dynamic.vance. IN A
192.168.1.45
vance-dynamic.log:update: {add} ha\032ri\032xx.dynamic.vance. 3600 IN A
192.168.1.45
But, now, dump the cache:
herman# rm /var/tmp/named_dump.db ; ndc dumpdb
Database dump initiated.
herman# grep -i -E 'ha.*xx' /var/tmp/named_dump.db
ha032ri032xx 3600 IN A 192.168.1.45 ;Cl=2
harixx 3600 IN A 192.168.1.45 ;Cl=2
Notice that the "\" has been dropped !!
Now, stop 'named'.
herman# ndc stop
The zone files are now updated *without* the "\" :
herman# grep -i -E 'ha.*xx' *
vance-dynamic:ha032ri032xx 3600 IN A 192.168.1.45
;Cl=2
vance-dynamic:harixx 3600 IN A 192.168.1.45 ;Cl=2
-------------------------------------------------
Tks | <mailto:BVance at sbm.com>
BV | <mailto:BobVance at alumni.caltech.edu>
Sr. Technical Consultant, SBM, A Gates/Arrow Co.
Vox 770-623-3430 11455 Lakefield Dr.
Fax 770-623-3429 Duluth, GA 30097-1511
=================================================
-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
Behalf Of Mark.Andrews at nominum.com
Sent: Saturday, January 13, 2001 7:20 AM
To: bobvance at alumni.caltech.edu
Cc: bind-users at isc.org
Subject: Re: How to force named to write dynamic data
>
> I guess a concern, a priori, would be if the server crashed and the
> zone files were not updated.
> In fact, this seems to be a problem, at least with 8.2.2-p7 &
8.2.3-T9B.
> If some dynamic updates are made, they are indeed in memory.
> If I then 'kill -9' on the named process within a couple of minutes of
> restarting, then any dynamic data in those couple of minutes are lost
> forever.
If this is the case then stdio is broken on your system.
Updates are written to log files and flushed to disk prior to
returning success to the client. The log files are used to
recover state when restarting.
>
> It would seem that 'named' needs a way to save the dynamic updates to
> files and when reloading, if the files are still there, merge those
> changes back in, similar to what it does on a termination.
It does do that.
> Would the IXFR files work?
BIND 9 uses the equivalent of the IXFR files. BIND 8 uses the
log files which contain the actual update. The IXFR files
contain the effects of the update.
Mark
More information about the bind-users
mailing list