DNS "chicken-and-egg" Problem

JINMEI Tatuya / 神明達哉 Jinmei_Tatuya at isc.org
Thu Oct 30 23:42:34 UTC 2008


At Thu, 30 Oct 2008 16:07:20 -0500 (CDT),
bsfinkel at anl.gov wrote:

>     1) One of my mailers is trying to find the "A" record for
> 
>            igpp.ucla.edu
> 
>        so that it can verify that mail from that domain is
>        legitimate mail.

[snip]

>     4) Why is this information not in the cache on my server?
>        Jinmei Tatuya said it might be due to a cache-clearing bug
>        in 9.5.0 (I am running 9.5.0-P2).  I ran a test with
>        "max-cache-size 256M", and I did not see the record cached.
>        And I doubt that the cache was full.

The question is still not very clear to me.  My response mainly
focused on the "real" problem that the caching server (occasionally?)
returns SERVFAIL for that specific query.  Are you saying the server
is still returning SERVFAIL even after raising max-cache-size and even
if the server does not reach that limit?

To answer the question directly...we need more information.  What
specifically did you try and which "this information" exactly are you
talking about?  Does that happen with mostly empty cache?  Is it
reproduceable or occasional?  It would be helpful if you can show
detailed steps toward the question, like
- starting a server
- dig the server with a query
- do rndc dumpdb
and show the dump output, explaining which information you're
expecting in the cache but isn't there.  Note that there's nothing
wrong about some information not in a cache per se (entries can be
purged for various reasons, by default).  So you should first explain
that it should be in the cache according to the detailed procedure.
It should also be noted that missing cache itself is not necessarily
problematic as long as the required information is finally returned
(though suboptimal in that it may take longer time and consume more
resources).  So it's also helpful to explain whether it causes a real
problem like SERVFAIL.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.


More information about the bind-users mailing list