Re: dig with and without +norec

Barry,

Thanks for a hint, I have discovered I am being blocked by them
probably, I don't know why, but it is us air-force, perhaps middle east
should not see them :-)... I am trying to contact them to investigate.

I have 9.2.3, I though this is happening and bind although having it in
the cache is trying to verify with the authoritative. It looks like I
have even performance problem because of this, since the same servers
are hosting lot of zones especially reverse ones, and retrying to them
takes some resources out of my bind.

Will it answer from cache if I bogus all af.mil ns?

In bind9 I don't see anymore from dump_db what is the ip address of the
server I got this cached data from, or what is the level of the trust of
the cached data. It is hard to troubleshoot, when you don't know who
sent you this cache and how much bind9 trust it.

Does it mean that if I have an A record in the cache, which I got from
the parent as a glue and the authoritative server is unreachable, bind
will not answer any recursive request about this record?


Ladislav


Barry Margolin wrote:
> In article <c1p590$v89$1@sf1.isc.org>,
> Ladislav Vobr <lvobr@ies.etisalat.ae> wrote:
>
>
>>I am somehow resending my earlier post. Can somebody give a hint why
>>recursive caching server behaves like this.
>
>
> When you specify +norec, it answers with whatever it has in its cache,
> which in this case is the delegation records that came from the parent
> domain's servers.
>
> When you request recursion, it checks whether the cached information
> came from an authoritative server. If not, it tries to ask the
> authoritative servers.
>
> I'm not sure why the recursive query is failing for you, though. I have
> no problem querying any of the authoritative nameservers. However, it's
> notable that your second dig returned the NS records in the Authority
> Section rather than the Answer Section, and didn't include the glue A
> records in the Additional Section. What version of BIND are you running
> on the server?
>
>
>>I have issued the dig directly from the server.
>>
>>[dxbins1:/]#dig ns af.mil @192.168.8.91
>>
>>; <<>> DiG 9.2.3 <<>> ns af.mil @192.168.8.91
>>;; global options: printcmd
>>;; connection timed out; no servers could be reached
>>
>>
>>[dxbins1:/]#dig ns af.mil @192.168.8.91 +norec
>>
>>; <<>> DiG 9.2.3 <<>> ns af.mil @192.168.8.91 +norec
>>;; global options: printcmd
>>;; Got answer:
>>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60916
>>;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 0
>>
>>;; QUESTION SECTION:
>>;af.mil. IN NS
>>
>>;; AUTHORITY SECTION:
>>af.mil. 58999 IN NS ARTEMIS.AFNOC.af.mil.
>>af.mil. 58999 IN NS NS.USAFE.af.mil.
>>af.mil. 58999 IN NS NS.MAXWELL.af.mil.
>>af.mil. 58999 IN NS MARS.AFNOC.af.mil.
>>af.mil. 58999 IN NS PAPA1.BARKSDALE.af.mil.
>>af.mil. 58999 IN NS DELTA1.BARKSDALE.af.mil.
>>
>>;; Query time: 19 msec
>>;; SERVER: 192.168.8.91#53(192.168.8.91)
>>;; WHEN: Sat Feb 28 08:12:24 2004
>>;; MSG SIZE rcvd: 170
>
>