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

Reply via email to