dig with and without +norec

[Ladislav Vobr]

>     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.