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
>>>>> [email protected]
>>>>> 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
>>> [email protected]
>>> 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
> [email protected]
> 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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
