dig with and without +norec

[lauren]

I am assuming you work for an ISP... I would bet that one
of your customers was attempting to do something nasty on
a US Air Force system and tripped one or more of the IDSs.
Therefore your entire block of IPs probably got blocked
at the AF perimeter. 


> 
>  
> --- Ladislav Vobr <lvobr at ies.etisalat.ae> wrote:
> > 
> > >     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.
> > 
> > 
> 
> 
> __________________________________
> Do you Yahoo!?
> Get better spam protection with Yahoo! Mail.
> http://antispam.yahoo.com/tools
> 


__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools