Critical problem with cache need help

[Eric Allard]

I use bind 9.2.1 on Solaris version 8.

Usually with some domains, I obtain a SERVFAIL when I make queries. To 
resolve it,
I have to flush the cache (rndc flush). After flushing the cache, the 
server answers correctly.

I need help because I cannot trust my dns at all!

What should be the problem and how can I solve it?

Thank you very much!

Here an example for the domain moulespcm.com:

Here a part of the content of named_dump.db:

; glue
moulespcm.com.          10513   NS      NS.SERVICESWEBNET.NET.


                        10513   NS      NS2.SERVICESWEBNET.NET.

; glue
SERVICESWEBNET.NET.     168007  NS      NS.SERVICESWEBNET.NET.
                        168007  NS      NS2.SERVICESWEBNET.NET.
; authauthority
NS.SERVICESWEBNET.NET.  2422    \-ANY   ;-$
; authauthority
NS2.SERVICESWEBNET.NET. 2422    \-ANY   ;-$


Here the BAD dig result:

dig @empress moulespcm.com

; <<>> DiG 9.2.1 <<>> @empress moulespcm.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7024
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;moulespcm.com.                 IN      A

;; Query time: 45 msec
;; SERVER: 142.169.11.5#53(empress)
;; WHEN: Mon Aug  5 18:03:16 2002
;; MSG SIZE  rcvd: 31


Here a part of the debug result:

 Aug 05 18:03:16.839 client: debug 3: client 142.169.11.5#35310: UDP
request
Aug 05 18:03:16.839 security: debug 3: client 142.169.11.5#35310:
request is not
 signed
Aug 05 18:03:16.839 security: debug 3: client 142.169.11.5#35310:
recursion avai
lable: approved
Aug 05 18:03:16.840 client: debug 3: client 142.169.11.5#35310: query
Aug 05 18:03:16.840 queries: info: client 142.169.11.5#35310: query:
moulespcm.c
om IN A
Aug 05 18:03:16.840 security: debug 3: client 142.169.11.5#35310: query
(cache)
approved
Aug 05 18:03:16.841 client: debug 3: client 142.169.11.5#35310: replace


Aug 05 18:03:16.841 resolver: debug 1: createfetch: moulespcm.com A

Aug 05 18:03:16.843 resolver: debug 3: fctx 6c4a260: answer_response
Aug 05 18:03:16.843 resolver: debug 3: fctx 6c4a260: cache_message
Aug 05 18:03:16.844 resolver: debug 3: fctx 6c4a260: cancelquery
Aug 05 18:03:16.844 resolver: debug 3: fctx 6c4a260: done
Aug 05 18:03:16.852 resolver: debug 3: fctx 6c4a260: stopeverything
Aug 05 18:03:16.852 resolver: debug 3: fctx 6c4a260: cancelqueries
Aug 05 18:03:16.852 resolver: debug 3: fctx 6c4a260: sendevents

Aug 05 18:03:16.870 resolver: debug 3: fetch 2d2c88 (fctx 6c4a260):
destroyfetch
Aug 05 18:03:16.870 resolver: debug 3: fctx 6c4a260: shutdown



Aug 05 18:03:16.875 client: debug 3: client 142.169.11.5#35310: error
Aug 05 18:03:16.875 client: debug 3: client 142.169.11.5#35310: send
Aug 05 18:03:16.876 client: debug 3: client 142.169.11.5#35310: sendto
Aug 05 18:03:16.886 client: debug 3: client 142.169.11.5#35310: senddone

Aug 05 18:03:16.887 client: debug 3: client 142.169.11.5#35310: next
Aug 05 18:03:16.887 client: debug 3: client 142.169.11.5#35310:
endrequest
Aug 05 18:03:16.887 resolver: debug 3: fctx 6c4a260: doshutdown
Aug 05 18:03:16.895 resolver: debug 3: fctx 6c4a260: stopeverything
Aug 05 18:03:16.896 resolver: debug 3: fctx 6c4a260: cancelqueries
Aug 05 18:03:16.896 resolver: debug 3: fctx 6c4a260: destroy
Aug 05 18:03:16.896 resolver: debug 3: fctx 3279650: doshutdown
Aug 05 18:03:16.896 resolver: debug 3: fctx 3279650: stopeverything
Aug 05 18:03:16.897 resolver: debug 3: fctx 3279650: cancelqueries
Aug 05 18:03:16.897 resolver: debug 3: fctx 3279650: destroy