I originally suspected the Windows box but I can reproduce these
failures on other systems from the nslookup command line tool and
without using Windows 2003 for name resolution. Also on systems without
Postfix. So I started Googling and find hits like this one:
http://ubuntuforums.org/showthread.php?t=827449
My command line errors look the same as reported at that URL.
nslookup X.X.X.X
;; Got recursion not available from x.x.x.x, trying next server
;; Got recursion not available from x.x.x.x, trying next server
Server: x.x.x.x
Address: x.x.x.x#53
Non-authoritative answer:
*** Cant find X.X.X.X: No answer
Usually for me, querying a single IP will fail the first time, then
subsequent lookups against the same data will succeed. The only way
I've been able to reproduce it in succession was if an IP address
lookup fails (say 12.34.56.78) I can query 12.34.56.79, .80, .81 to see
the recursion not available message.
At this point I'm not sure if it's a problem with NSLOOKUP, or
whatever DNS library Lenny is using, or my environment specifically
so.... Has anyone run across this problem and defeated it?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/3e1f6e751ddeee98...@192.168.0.66
Please "cat /etc/resolv.conf" and post the result here.
--Mike Bird
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201101051003.3...@yosemite.net
nameserver x.x.x.x
nameserver x.x.x.x
The x's are obviously my IP's which I don't want on a public mailing
list.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/39e25269d3c9b499...@192.168.0.66
> On Wed, 5 Jan 2011 10:03:36 -0800, Mike Bird wrote:
>> On Wed January 5 2011 09:11:50 vr wrote:
>>> nslookup X.X.X.X
>>> ;; Got recursion not available from x.x.x.x, trying next server
>>> ;; Got recursion not available from x.x.x.x, trying next server
>>
>> Please "cat /etc/resolv.conf" and post the result here.
>>
>> --Mike Bird
>
> nameserver x.x.x.x
> nameserver x.x.x.x
>
> The x's are obviously my IP's which I don't want on a public mailing
> list.
Your ip is probably 99.30.25.3, which is on your mail headers.. ;)
It's strange to have your public IP used as a resolver on your local
network.
Could you give us more infos about your connection and your router? How
are the machines connected ?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87r5cru...@fermat.tourde.home
No, that's the network I'm posting to this mailing list from. ;-)
> It's strange to have your public IP used as a resolver on your local
> network.
>
> Could you give us more infos about your connection and your router? How
> are the machines connected ?
This is a little difficult because I've been able to experience it on a
few different networks with virtualized clients and virtualized DNS
servers and others with physical clients and physical DNS servers. I
suppose I can outline where I discovered it first with the hopes that
the pitchforks won't come out since it's a Linux client querying a
Windows 2003 server?
In that scenario there is one ESXi 4.0 node hosting Debian Lenny and
Windows 2003SP2. They sit on the same physical node.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/fec5f53dc6ae9cfc...@192.168.0.66
Are you talking about 99.30.25.1 and 99.30.25.2? (They should be
on different backbones in different geographical areas.)
Are your name servers configured to allow recursion?
Didn't you say earlier that your name servers run under Windows 2003?
If so, why is this a Linux issue?
--Mike Bird
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201101051157.2...@yosemite.net
No.
> Are your name servers configured to allow recursion?
>
Yes.
> Didn't you say earlier that your name servers run under Windows 2003?
>
> If so, why is this a Linux issue?
>
> --Mike Bird
In all cases of experiencing this issue, it's Linux clients querying a
DNS server. The servers queried have been both Windows & Linux. The
client that gets "recursion not available" is always Linux (Lenny).
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/a51c3e0f1df9c55e...@192.168.0.66
Older bind and newer bind have different defaults for recursion.
Older bind allowed it but newer bind defaults to it off for all but
the local subnet. Among other things this prevents bind from being
used in a distributed denial of service attack against a third party.
Are you using a nameserver on a different subnet? If so then I think
that will explain the problem. The nameserver on the other subnet
needs to allow your local subnet. You probably have one that allows
it and one that does not. This is why it works the second time.
For the first lookup it might hit a working server and just get the
answer. Or it might hit the one with recusion turned off. Then it
rotates to the next one and gets the answer. The second time around
the answer is cached and so no further lookups are done. You can
force a restart of bind in order to force it to look up for the first
time again.
If you list nameservers in the /etc/resolv.conf file then it will
always try them in the order listed. But the first nameserver there
may have forwarders configured on it. You need to follow the chain
through every nameserver that has forwarders listed until you get to
the end of the chain. Your description of the problem makes me think
the nameserver with the recursion disabled will be two away from you.
Look at the allow-recursion option to allow your subnets.
allow-recursion { 192.0.32.0/24; };
Nameservers listed in /etc/resolv.conf are tried in order with a
failure timeout. Because of that if the first nameserver is offline
then things operate but very slowly with a timeout for every lookup.
Therefore I always configure a local caching bind nameserver
configured with forwarders. That will pick the fastest responding
forwarder and avoid the timeout delay when one is down. Although
different versions of bind8 and bind9 have had different behaviors in
this area and some were better than others. If you had a local
caching nameserver configured you would probaby not have noticed your
upstream nameserver configuration errors.
Bob
Are you going to show us the named configuration of the Linux
server which is saying that recursion is not available, and
tell us the IP addresses of the client and the server?
--Mike Bird
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201101051250.1...@yosemite.net
> I'm using a Lenny system to host Postfix and Windows 2003 for name
> resolution. More frequently than I probably should, I will see NOQUEUE
> in /var/log/mail.log related to DNS lookups.
Those Postfix logs should be very useful. Can you post them?
> I've not yet narrowed it down to forward lookups, reverse lookups or
> both.
>
> I originally suspected the Windows box but I can reproduce these
> failures on other systems from the nslookup command line tool and
> without using Windows 2003 for name resolution.
(...)
Wait... what kind of tests did you run and what are the results?
"Recursion" is a DNS server capability so you have to check your DNS
servers and while making any test against them, ensure you are always
quering the same DNS server.
Tools like "dig @ip_of_name_server_to_use" (in linux) and "nslookup -
debug hostname domain" (in windows) can help a lot. Both tools, by
default, will request recursion to the server so if that option is not
available, you'll get a warning.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org