Re: dig with and without +norec

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