First time not OK but subsequent query got resolved

Kevin Darcy kcd at
Wed Feb 6 22:52:04 UTC 2002

"db_update failed" probably just means that named tried to update a data structure but discovered that there was nothing to update about it (the old data already had higher "credibility" than the old data, or some such). I think it's a fairly commonplace message and does not indicate any serious problem.

As for the phenomenon of the query failing the first time but succeeding after that, this is probably caused by too many levels of glue. BIND 8 has no "query restart" so sometimes it gets part of the way through resolving a query and then stops, hoping for the client to retry the query so it can complete it and send a response. Unfortunately, the client might time
out the query before it gets that far.

                                                                                                                        - Kevin

Stanley Liu wrote:

> BIND 8.3.1 on NT.
> Could someone help me out here please?  I have a situation that every time I try to browse a URL (any valid host) the first time, it always returns "page not found".  Subsequent queries are OK.  I have switched on Debug level 4 in the nameserver and I have the following:
> 06-Feb-2002 12:02:11.000 datagram from [].53, fd 176, len 128
> 06-Feb-2002 12:02:11.000 ncache: dname, type 1, class 1
> 06-Feb-2002 12:02:11.000 db_update failed (-10), cache_n_resp()
> 06-Feb-2002 12:02:11.000 send_msg -> [].1155 (UDP 144) id=1
> evSetTimer(ctx 0x8a0020, func 0x413a90, uap 0, due 1012957333.000000000, inter 0.000000000)
> pselect(177, 0xf5f5f5f5, 0xf5f5f5f5, 0xf5f5f5f5, 2.000000000)
> select() returns 1 (err: none)
> I was testing (browsing) with URL on a test machine using its own nameserver ( as resolver.  The above log comes from the test machine (it is the problem on the test machine nameserver that I want to resolve).  What did the "db_update failed (-10), cache_n_resp()" in the above message highlight? Or is it just coincidental?
> Thanks.
> Stanley Liu
> stanley.liu at

More information about the bind-users mailing list