Re: dig with and without +norec

> Ladislav> ... referral answer snipped ....
>
> There will probably be a firewall or router in front of 192.168.8.91
> that's blocking recursive DNS queries. This would not be unreasonable
> if the administrator of 192.168.8.91 didn't want that server to handle
> recursive DNS queries.

jim, that administrator is me :-), there is a pix firewal, but I don't
have problem answering other recursive queries, and I don't have local
network problems. We have very redundant network setup here, and BTW
f-root in next room. I have around 1000 requests/sec normal traffic
working fine.

For some reasons all af.mil ns servers are unreachable for me. I guess
we have been blocked somewhere and investigating it...

but what was not clear to me is that my recursive bind 9.2.3 have the
data in the cache as a glue from parent server (.mil), but doesn't
provide them for recursive client, unless authoritative servers are up,
but provides them without this check to the non-recursive one.

This is what I observe here, why is that like this or what use it could
have? - right now I don't know. Perhaps it is good to verify with
authoritative server to prevent dns spoofing, or it some kind of favor
bind will do to provide more accurate information, but in my case I am
quite sure it is not spoofed and instead of favor, I would rather accept
the glue as a reply when having a choice (glue or no reply)but I don't
have any way how to provide the answer to my recursive clients, even
though I have it in the cache.

More I think about it, I understand glue is not an answer, but bind
already trust it itself, when it accepted it from the parent.

I have increased load on this server, I am keeping retrying to these
af.mil servers, and I can not even find out if there are any other ip
addresses being retried like this from the same server although they are
unreachable for perhaps days,weeks. There is no log, which tells you
these servers are unreachable I am waisting 5% of resources on each by
flooding them, because bind doesn't consider them lame and it does not
even log it anywhere or inform about it. I can mark them bogus, but how
I discover them?, just by snoop:-) why bind cannot tell look, this guy
is persistently down I will not waste my time/resources on it I will log
it for you or I will blackhole it temporarily if you configure me to do
so. This problems are not issues when you run 100-200 req/second it will
somehow work, but when you go to thousands/sec you need quite a server
for the current behaviour.


Ladislav

p.s. I apologize for what I said in my previous post, that bind9 doesn't
have Cr tag in the named_dump.db, it is there just on the next line, I
used to do grep with bind8, which doesn't show it anymore. But the
source of the cached information (ip address of the parent) is not
there, and this makes troubleshooting difficult.