Re: Host command timing out sporadically

2012-05-02 Thread Paul Marais
So I discovered that if I just do: dig gmail.com I get no answers... but thats 
most likely because my NS is set to not allow recursion... what I didn't 
realize is that dig was not forwarding the request to my isp's NS.

When force the lookup on my isp's NS ie: dig @206.168.216.6 mx gmail.com, I get 
replies... and every 5 to 10 replies, there are one or 2 lookups that take a 
few seconds, and I think its these slower replies that postfix is timing out on.

If I do the same lookups on my home computer I experience the same delay every 
5-10 lookups... so Im thinking my ISP's NS is just a little bogged down... and 
when postfix does a lookup at the same time... it gives up because the lookup 
takes too long and logs it as host not found... even though the NS finds it... 
postfix gave up before the reply came back.

So it looks like I just need to make postfix use a longer timeout perhaps.


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 'hosthostname', 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


Re: Host command timing out sporadically

2012-05-02 Thread Paul Marais
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 'hosthostname', 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

Re: Host command timing out sporadically

2012-05-02 Thread Paul Marais
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 'hosthostname', 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