I think its fixed... just not sure why...
I removed the 'recursion no' line and its much faster now and not timing out...

I used to have :
        recursion no;
        allow-query {   any;  };
        allow-recursion {  192.168.2.0/24; 127.0.0.1; };
        allow-query-cache {   192.168.2.0/24;  127.0.0.1; };

Now I have:
        allow-query {   any;  };
        allow-recursion {  192.168.2.0/24; 127.0.0.1; };
        allow-query-cache {   192.168.2.0/24;  127.0.0.1; };




On May 2, 2012, at 7:24 PM, Lyle Giese wrote:

> If you have recursion turned off, then no it won't forward.  It tells your 
> named that if it doesn't already know the answer, tell the client I don't 
> know and won't ask anyone else.
> 
> But what about the second scenerio below?  You check on scenerio 1, but you 
> have not addressed #2.
> 
> Besides, the recursion setting in named is immaterial when doing dig +trace.  
> Once dig gets the addresses of the root server, it stops asking your local 
> copy of named and starts asking the root servers for itself and does not rely 
> any further on named.
> 
> Lyle
> 
> On 05/02/12 18:59, Paul Marais wrote:
>> 
>> I checked the firewall and I have rules to allow tcp & udp on port 53.
>> Is there anything I can do to get more information on why no connection is 
>> made to the root servers. 
>> 
>> I'm a bit confused.. if I have recursion off shouldn't my local named be 
>> forwarding the request to the name server in my "forwarders" section of the 
>> named options.
>> 
>> 
>> 
>> 
>> On May 2, 2012, at 3:48 PM, Lyle Giese wrote:
>> 
>>> Using dig +trace, dig is trying to accomplish the recursion that named 
>>> would do for you.  This tells us your local copy of named is answering 
>>> requests as that is where you received the list of root servers from.  But 
>>> when dig tries to ask the root name servers how to find gmail.com, dig is 
>>> unable to contact or get an answer from the root name servers.
>>> 
>>> This indicates one of two problems.
>>> 
>>> 1) firewall rules are not permitting both udp and tcp port 53 traffic(which 
>>> I doubt since it works sometimes).
>>> 2) your Internet connection is congested and dropping or delaying your 
>>> traffic to the point, dig gives up trying.
>>> 
>>> But the use of dig +trace shows much more diagnostic information which 
>>> points us to the real issue you have.
>>> 
>>> Lyle Giese
>>> LCR Computer Services, Inc.
>>> 
>>> On 05/02/12 16:36, Paul Marais wrote:
>>>> 
>>>> Thanks Lyle,
>>>> You're right - I started using the host command because it was giving me 
>>>> the error I found in the postfix logs... 
>>>> but as I just discovered dig +trace also give me the error...
>>>> 
>>>> I am seeing lots of mailed messages to gmail accounts... and when I do a 
>>>> trace I get the following:
>>>> 
>>>> ; <<>> DiG 9.7.3 <<>> +trace mx gmail.com
>>>> ;; global options: +cmd
>>>> . 501632 IN NS m.root-servers.net.
>>>> . 501632 IN NS c.root-servers.net.
>>>> . 501632 IN NS h.root-servers.net.
>>>> . 501632 IN NS b.root-servers.net.
>>>> . 501632 IN NS e.root-servers.net.
>>>> . 501632 IN NS j.root-servers.net.
>>>> . 501632 IN NS k.root-servers.net.
>>>> . 501632 IN NS g.root-servers.net.
>>>> . 501632 IN NS f.root-servers.net.
>>>> . 501632 IN NS i.root-servers.net.
>>>> . 501632 IN NS l.root-servers.net.
>>>> . 501632 IN NS a.root-servers.net.
>>>> . 501632 IN NS d.root-servers.net.
>>>> ;; Received 320 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>>>> 
>>>> ;; connection timed out; no servers could be reached
>>>> 
>>>> 
>>>> If I leave the trace off, I see no error messages... but I get no answer 
>>>> and I do see a warning:
>>>> 
>>>> ; <<>> DiG 9.7.3 <<>> mx gmail.com
>>>> ;; global options: +cmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32902
>>>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 5
>>>> ;; WARNING: recursion requested but not available
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On May 2, 2012, at 1:42 PM, Lyle Giese wrote:
>>>> 
>>>>> On 05/02/12 12:12, Paul Marais wrote:
>>>>>> Hi,
>>>>>> I'm having an issue where my postfix server is having trouble with some 
>>>>>> lookups.
>>>>>> When I type 'host<hostname>', 80% of the time I get decent reply speed, 
>>>>>> but for 20% I get a 5 second delay, or even a timeout.
>>>>>> 
>>>>>> My nameserver is configured to only allow recursion for hosts on my 
>>>>>> local network, and I have my ISP dns in my forwarders.
>>>>>> My resolv.conf has 127.0.0.1, my internal ip, and the ip for my isp DNS
>>>>>> 
>>>>>> Any help will be greatly appreciated.
>>>>>> 
>>>>>> Thanks
>>>>>> Paul
>>>>>> 
>>>>>> 
>>>>> Don't use host.  It's not telling us what is going wrong and it's only 
>>>>> doing an A record lookup of host name.
>>>>> 
>>>>> Postfix does an MX lookup for the domain and then an A record lookup for 
>>>>> the mail server(s) in the MX records.
>>>>> 
>>>>> Learn to use dig.
>>>>> 
>>>>> Do this:
>>>>> 
>>>>> dig mx example.com
>>>>> 
>>>>> If the answer is mail.example.com do this:
>>>>> 
>>>>> dig mx example.com
>>>>> 
>>>>> if either fail do this:
>>>>> 
>>>>> dig +trace mx example.com
>>>>> or
>>>>> dig +trace mail.example.com
>>>>> 
>>>>> And see if you can catch the failure and then we can do more for you.  
>>>>> The other side of this may be that your Internet connection is overloaded 
>>>>> and you are dropping packets or it's taking too long for the query to get 
>>>>> out and get the response.
>>>>> 
>>>>> Lyle Giese
>>>>> LCR Computer Services, Inc.
>>>>> 
>>>>> _______________________________________________
>>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>>>>> unsubscribe from this list
>>>>> 
>>>>> bind-users mailing list
>>>>> bind-users@lists.isc.org
>>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>>> unsubscribe from this list
>>> 
>>> bind-users mailing list
>>> bind-users@lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>> 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to