Host command timing out sporadically

Lyle Giese lyle at lcrcomputer.net
Thu May 3 02:24:27 UTC 2012


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 <http://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 <http://gmail.com/>
>>>     ;; global options: +cmd
>>>     .501632INNSm.root-servers.net <http://m.root-servers.net/>.
>>>     .501632INNSc.root-servers.net <http://c.root-servers.net/>.
>>>     .501632INNSh.root-servers.net <http://h.root-servers.net/>.
>>>     .501632INNSb.root-servers.net <http://b.root-servers.net/>.
>>>     .501632INNSe.root-servers.net <http://e.root-servers.net/>.
>>>     .501632INNSj.root-servers.net <http://j.root-servers.net/>.
>>>     .501632INNSk.root-servers.net <http://k.root-servers.net/>.
>>>     .501632INNSg.root-servers.net <http://g.root-servers.net/>.
>>>     .501632INNSf.root-servers.net <http://f.root-servers.net/>.
>>>     .501632INNSi.root-servers.net <http://i.root-servers.net/>.
>>>     .501632INNSl.root-servers.net <http://l.root-servers.net/>.
>>>     .501632INNSa.root-servers.net <http://a.root-servers.net/>.
>>>     .501632INNSd.root-servers.net <http://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 <http://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 <http://example.com/>
>>>>
>>>> If the answer is mail.example.com <http://mail.example.com/> do this:
>>>>
>>>> dig mx example.com <http://example.com/>
>>>>
>>>> if either fail do this:
>>>>
>>>> dig +trace mx example.com <http://example.com/>
>>>> or
>>>> dig +trace mail.example.com <http://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 at lists.isc.org <mailto:bind-users at 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 at lists.isc.org <mailto:bind-users at lists.isc.org>
>> https://lists.isc.org/mailman/listinfo/bind-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120502/bb987186/attachment.html>


More information about the bind-users mailing list