intermittent SERVFAIL for high visible domains such as *

Brian J. Murrell brian at
Mon Jan 22 16:58:22 UTC 2018

On Mon, 2018-01-22 at 16:10 +0000, Tony Finch wrote:
> You should make sure it is enabled, because there are vital clues in
> those
> log lines :-)

But they will only occur if there is some lameness with the ns[1-
4] records and that will already be reported with lame:n in
the "fetch completed at resolver.c" lines won't they, or am I
completely misunderstanding something here?

> Yes, and you should track down when they occur and look for other
> error
> indications areound that time.

So, over the last week of tracing I have only these lines which match
"fetch completed at resolver.c:[0-9]* for ns[1-4]":

19-Jan-2018 09:41:53.347 fetch completed at resolver.c:7492 for in 0.042154: success/success [,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
19-Jan-2018 09:41:53.350 fetch completed at resolver.c:7492 for in 0.042019: success/success [,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
19-Jan-2018 09:41:53.356 fetch completed at resolver.c:7492 for in 0.043881: success/success [,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
19-Jan-2018 09:41:53.362 fetch completed at resolver.c:7492 for in 0.047039: success/success [,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

None of them show any lame servers.

Wouldn't I see occurrences of those with lame:n if I there were any

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the bind-users mailing list