Hi all,
I have a problem using named with different CentOS5 servers (2 servers): all they are really slow to resolv any internet address and most of time fails to resolv. This situation differs if I use "forwarders" servers like opendns: resolving names it is really really quickly. And I don't understand why.
On the other hand I have tested three DNS servers using Windows 2003, Windows 2008 and Ubuntu hardy and these problems doesn't occurs (I don't need to configure forwarders on any of them): all resolves any name and really fast.
IPv6 is disabled on both CentOS servers. Somebody knows why these dns servers are slow??
Thanks.
On 2009-05-25 12:51, carlopmart wrote:
I have a problem using named with different CentOS5 servers (2 servers): all they are really slow to resolv any internet address and most of time fails to resolv. This situation differs if I use "forwarders" servers like opendns: resolving names it is really really quickly. And I don't understand why.
On the other hand I have tested three DNS servers using Windows 2003, Windows 2008 and Ubuntu hardy and these problems doesn't occurs (I don't need to configure forwarders on any of them): all resolves any name and really fast.
IPv6 is disabled on both CentOS servers. Somebody knows why these dns servers are slow??
My crystal ball is in repair. Could you in the meantime add some more hints, e.g. your config files, and how you diagnosed the slowness.
My CentOS5 DNS-servers do resolve really quickly, with or without forwarders.
Paul Bijnens wrote:
On 2009-05-25 12:51, carlopmart wrote:
I have a problem using named with different CentOS5 servers (2 servers): all they are really slow to resolv any internet address and most of time fails to resolv. This situation differs if I use "forwarders" servers like opendns: resolving names it is really really quickly. And I don't understand why.
On the other hand I have tested three DNS servers using Windows 2003, Windows 2008 and Ubuntu hardy and these problems doesn't occurs (I don't need to configure forwarders on any of them): all resolves any name and really fast.
IPv6 is disabled on both CentOS servers. Somebody knows why these dns servers are slow??
My crystal ball is in repair. Could you in the meantime add some more hints, e.g. your config files, and how you diagnosed the slowness.
My CentOS5 DNS-servers do resolve really quickly, with or without forwarders.
Ok, my named.conf:
// // named.conf //
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; listen-on port 53 { 127.0.0.1; 172.25.50.10; }; version "DNS Server v2.0"; dnssec-enable no; query-source port 53; forwarders { 208.67.220.220; 208.67.222.222; }; };
logging { channel security_channel { file "/var/named/data/security.log" versions 3 size 1m; severity debug; print-time yes; print-category yes; print-severity yes; }; channel default { syslog local4; severity info; print-category yes; print-severity yes; }; channel query_log { file "/var/named/data/query.log" versions 3 size 1m; print-time yes; }; category security { security_channel; default; }; category queries { query_log; }; channel default_debug { file "/var/named/data/named.run"; severity dynamic; }; category lame-servers { null; }; category default { default; }; };
controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; };
As you can see, I need to use "query-source port" param too with forwarders to resolv names (and this is really really ugly).
And some examples:
- Using "query-source port" and "forwarders" directives:
[root@thranduil data]# nslookup
bugs.centos.org
Server: 127.0.0.1 Address: 127.0.0.1#53
Non-authoritative answer: Name: bugs.centos.org Address: 72.232.194.162
.. all it is normal and really fast.
- Disabling "query-source port" and "forwarders" directives:
[root@thranduil data]# nslookup
www.google.com
;; connection timed out; no servers could be reached
first attempt fails ...
root@thranduil data]# nslookup
www.google.com
;; connection timed out; no servers could be reached
second attempt fails and ..
root@thranduil data]# nslookup
www.google.com
Server: 127.0.0.1 Address: 127.0.0.1#53
Non-authoritative answer: www.google.com canonical name = www.l.google.com. Name: www.l.google.com Address: 209.85.227.99 Name: www.l.google.com Address: 209.85.227.103 Name: www.l.google.com Address: 209.85.227.104 Name: www.l.google.com Address: 209.85.227.147
.. at third attempt works ...
same tests using ubuntu hardy without using "query-source" and "forwarders" directives, works.
Do you need more info??
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; listen-on port 53 { 127.0.0.1; 172.25.50.10; }; version "DNS Server v2.0"; dnssec-enable no; query-source port 53; forwarders { 208.67.220.220; 208.67.222.222; }; };
As you can see, I need to use "query-source port" param too with forwarders to resolv names (and this is really really ugly).
Explicit query-source port breaks port randomisation and is highly insecure. Your problem may be an incorrectly configured firewall that only accepts outgoing queries originating from source port 53 - it needs to accept all outgoing queries for destination port 53.
Lars Hecking wrote:
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; listen-on port 53 { 127.0.0.1; 172.25.50.10; }; version "DNS Server v2.0"; dnssec-enable no; query-source port 53; forwarders { 208.67.220.220; 208.67.222.222; }; };
As you can see, I need to use "query-source port" param too with forwarders to resolv names (and this is really really ugly).
Explicit query-source port breaks port randomisation and is highly insecure. Your problem may be an incorrectly configured firewall that only accepts outgoing queries originating from source port 53 - it needs to accept all outgoing queries for destination port 53.
Thanks lars. Correctly, firewall could be the problem, but it isn't. Because Ubuntu and Windows 2003/2008 doesn't have problems with it ... and resolves perfectly ... And I don't have configured this firewall to accept dns queries originating from source port 53 ...
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
carlopmart wrote:
Lars Hecking wrote:
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; listen-on port 53 { 127.0.0.1; 172.25.50.10; }; version "DNS Server v2.0"; dnssec-enable no; query-source port 53; forwarders { 208.67.220.220; 208.67.222.222; }; };
As you can see, I need to use "query-source port" param too with forwarders to resolv names (and this is really really ugly).
Explicit query-source port breaks port randomisation and is highly insecure. Your problem may be an incorrectly configured firewall that only accepts outgoing queries originating from source port 53 - it needs to accept all outgoing queries for destination port 53.
Thanks lars. Correctly, firewall could be the problem, but it isn't. Because Ubuntu and Windows 2003/2008 doesn't have problems with it ... and resolves perfectly ... And I don't have configured this firewall to accept dns queries originating from source port 53 ...
What does 'dig' show about your access to the root servers without forwarders and with and without forcing the query-source port? Compare it to the Ubuntu system. Maybe there's something wrong with the root hints file - or maybe your border firewall is blocking all udp to this box but permitting it to the DNS servers that work.
Les Mikesell wrote:
carlopmart wrote:
Lars Hecking wrote:
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; listen-on port 53 { 127.0.0.1; 172.25.50.10; }; version "DNS Server v2.0"; dnssec-enable no; query-source port 53; forwarders { 208.67.220.220; 208.67.222.222; }; };
As you can see, I need to use "query-source port" param too with forwarders to resolv names (and this is really really ugly).
Explicit query-source port breaks port randomisation and is highly insecure. Your problem may be an incorrectly configured firewall that only accepts outgoing queries originating from source port 53 - it needs to accept all outgoing queries for destination port 53.
Thanks lars. Correctly, firewall could be the problem, but it isn't. Because Ubuntu and Windows 2003/2008 doesn't have problems with it ... and resolves perfectly ... And I don't have configured this firewall to accept dns queries originating from source port 53 ...
What does 'dig' show about your access to the root servers without forwarders and with and without forcing the query-source port? Compare it to the Ubuntu system. Maybe there's something wrong with the root hints file - or maybe your border firewall is blocking all udp to this box but permitting it to the DNS servers that work.
Thanks Les, but I have checked it before post this problem. Ubuntu and CentOS have the same file to do querys to root servers ...
I have find a temporary solution: reduce the MTU on CentOS server (1440) ...I need to investigate why centOS loses some packages and ubuntu doesn't ....
carlopmart wrote:
Les Mikesell wrote:
carlopmart wrote:
Lars Hecking wrote:
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; listen-on port 53 { 127.0.0.1; 172.25.50.10; }; version "DNS Server v2.0"; dnssec-enable no; query-source port 53; forwarders { 208.67.220.220; 208.67.222.222; }; };
As you can see, I need to use "query-source port" param too with forwarders to resolv names (and this is really really ugly).
Explicit query-source port breaks port randomisation and is highly insecure. Your problem may be an incorrectly configured firewall that only accepts outgoing queries originating from source port 53 - it needs to accept all outgoing queries for destination port 53.
Thanks lars. Correctly, firewall could be the problem, but it isn't. Because Ubuntu and Windows 2003/2008 doesn't have problems with it ... and resolves perfectly ... And I don't have configured this firewall to accept dns queries originating from source port 53 ...
What does 'dig' show about your access to the root servers without forwarders and with and without forcing the query-source port? Compare it to the Ubuntu system. Maybe there's something wrong with the root hints file - or maybe your border firewall is blocking all udp to this box but permitting it to the DNS servers that work.
Thanks Les, but I have checked it before post this problem. Ubuntu and CentOS have the same file to do querys to root servers ...
And the results of 'dig' on each?
I have find a temporary solution: reduce the MTU on CentOS server (1440) ...I need to investigate why centOS loses some packages and ubuntu doesn't ....
Are you routing through tunnels?
Les Mikesell wrote:
carlopmart wrote:
Les Mikesell wrote:
carlopmart wrote:
Lars Hecking wrote:
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; listen-on port 53 { 127.0.0.1; 172.25.50.10; }; version "DNS Server v2.0"; dnssec-enable no; query-source port 53; forwarders { 208.67.220.220; 208.67.222.222; }; };
As you can see, I need to use "query-source port" param too with forwarders to resolv names (and this is really really ugly).
Explicit query-source port breaks port randomisation and is highly insecure. Your problem may be an incorrectly configured firewall that only accepts outgoing queries originating from source port 53 - it needs to accept all outgoing queries for destination port 53.
Thanks lars. Correctly, firewall could be the problem, but it isn't. Because Ubuntu and Windows 2003/2008 doesn't have problems with it ... and resolves perfectly ... And I don't have configured this firewall to accept dns queries originating from source port 53 ...
What does 'dig' show about your access to the root servers without forwarders and with and without forcing the query-source port? Compare it to the Ubuntu system. Maybe there's something wrong with the root hints file - or maybe your border firewall is blocking all udp to this box but permitting it to the DNS servers that work.
Thanks Les, but I have checked it before post this problem. Ubuntu and CentOS have the same file to do querys to root servers ...
And the results of 'dig' on each?
I have find a temporary solution: reduce the MTU on CentOS server (1440) ...I need to investigate why centOS loses some packages and ubuntu doesn't ....
Are you routing through tunnels?
No, all hosts (firewall and CentOS DNS server) are connected to GByte network.
carlopmart wrote:
Thanks lars. Correctly, firewall could be the problem, but it isn't. Because
Ubuntu and Windows 2003/2008 doesn't have problems with it ... and resolves perfectly ... And I don't have configured this firewall to accept dns queries originating from source port 53 ...
What does 'dig' show about your access to the root servers without forwarders and with and without forcing the query-source port? Compare it to the Ubuntu system. Maybe there's something wrong with the root hints file - or maybe your border firewall is blocking all udp to this box but permitting it to the DNS servers that work.
Thanks Les, but I have checked it before post this problem. Ubuntu and CentOS have the same file to do querys to root servers ...
And the results of 'dig' on each?
I have find a temporary solution: reduce the MTU on CentOS server (1440) ...I need to investigate why centOS loses some packages and ubuntu doesn't ....
Are you routing through tunnels?
No, all hosts (firewall and CentOS DNS server) are connected to GByte network.
That's not where the problem is. Since you are working with forwarding on, the problem has to be when you try to go directly to the internet over UDP so it would be at the firewall or border router. When DNS fails, it will retry with TCP and that might be why it eventually works. Is there anything in the path to the internet that needs a lower MTU (perhaps a DNS line running PPOE)? Or do you have jumbo packets enabled on your Gig NIC? And if you do need a small MTU, do you have firewalls blocking the ICMP messages that are required to discover that automatically?
Les Mikesell wrote:
carlopmart wrote:
> Thanks lars. Correctly, firewall could be the problem, but it isn't. Because Ubuntu and Windows 2003/2008 doesn't have problems with it ... and resolves perfectly ... And I don't have configured this firewall to accept dns queries originating from source port 53 ...
What does 'dig' show about your access to the root servers without forwarders and with and without forcing the query-source port? Compare it to the Ubuntu system. Maybe there's something wrong with the root hints file - or maybe your border firewall is blocking all udp to this box but permitting it to the DNS servers that work.
Thanks Les, but I have checked it before post this problem. Ubuntu and CentOS have the same file to do querys to root servers ...
And the results of 'dig' on each?
I have find a temporary solution: reduce the MTU on CentOS server (1440) ...I need to investigate why centOS loses some packages and ubuntu doesn't ....
Are you routing through tunnels?
No, all hosts (firewall and CentOS DNS server) are connected to GByte network.
That's not where the problem is. Since you are working with forwarding on, the problem has to be when you try to go directly to the internet over UDP so it would be at the firewall or border router. When DNS fails, it will retry with TCP and that might be why it eventually works.
That's not possible, because firewall only permits DNS querys over UDP ...
Is there anything in the path to the internet that needs a lower MTU (perhaps a DNS line running PPOE)? Or do you have jumbo packets enabled on your Gig NIC?
No, but firewalls have a mtu configured with 1450 on external interfaces ...
And if you do need a small MTU, do you have firewalls
blocking the ICMP messages that are required to discover that automatically?
Yes, ICMP messages are blocked on firewall, but are blocked for all hosts: centos dns servers, ubuntu servers, windows servers ... i don't understand why using Ubuntu or windows servers to resolve names works ok and with centos (and with either rhel5. I have just check it) doesn't ...
carlopmart wrote:
Les Mikesell wrote:
carlopmart wrote:
>> Thanks lars. Correctly, firewall could be the problem, but it isn't. Because > Ubuntu and Windows 2003/2008 doesn't have problems with it ... and resolves > perfectly ... And I don't have configured this firewall to accept dns queries > originating from source port 53 ... > What does 'dig' show about your access to the root servers without forwarders and with and without forcing the query-source port? Compare it to the Ubuntu system. Maybe there's something wrong with the root hints file - or maybe your border firewall is blocking all udp to this box but permitting it to the DNS servers that work.
Thanks Les, but I have checked it before post this problem. Ubuntu and CentOS have the same file to do querys to root servers ...
And the results of 'dig' on each?
I have find a temporary solution: reduce the MTU on CentOS server (1440) ...I need to investigate why centOS loses some packages and ubuntu doesn't ....
Are you routing through tunnels?
No, all hosts (firewall and CentOS DNS server) are connected to GByte network.
That's not where the problem is. Since you are working with forwarding on, the problem has to be when you try to go directly to the internet over UDP so it would be at the firewall or border router. When DNS fails, it will retry with TCP and that might be why it eventually works.
That's not possible, because firewall only permits DNS querys over UDP ...
I'd advise following the standards. If the response won't fit in a udp packet, it has to fail over to tcp.
Is there anything in the path to the internet that needs a lower MTU (perhaps a DNS line running PPOE)? Or do you have jumbo packets enabled on your Gig NIC?
No, but firewalls have a mtu configured with 1450 on external interfaces ...
Why?
And if you do need a small MTU, do you have firewalls
blocking the ICMP messages that are required to discover that automatically?
Yes, ICMP messages are blocked on firewall, but are blocked for all hosts: centos dns servers, ubuntu servers, windows servers ... i don't understand why using Ubuntu or windows servers to resolve names works ok and with centos (and with either rhel5. I have just check it) doesn't ...
The 'dig' response might give you a hint. But if all other network operations work OK, I'd still guess it is a firewall setting that you are missing.
ive read most of the thread, yet not all. forgive me as i might have missed some of this below in helping...
carlopmart,
what is in your /etc/resolv.conf
is it configured correctly?
are you using ipv6?
if not, is it fully disabled / turned off?
in modprobe.conf put
alias net-pf-10 off alias ipv6 off
reboot...
also, are you loading those other opsys on the same machine and getting good results or different machines?
testing other opsys on different hardware could be problematic.
did you bother to check the physical ports to see if any problems in the switch or with ethtool on the server interface ?
thoughtfully consinder following advise of others re: tcp and dns
cables...
- rh
RobertH wrote:
ive read most of the thread, yet not all. forgive me as i might have missed some of this below in helping...
carlopmart,
what is in your /etc/resolv.conf
search hpulabs.org nameserver 127.0.0.1
is it configured correctly?
are you using ipv6?
no.
if not, is it fully disabled / turned off?
in modprobe.conf put
alias net-pf-10 off alias ipv6 off
I have configured this previously ..
reboot...
also, are you loading those other opsys on the same machine and getting good results or different machines?
I have good results using different operating systems but using same hardware ..
testing other opsys on different hardware could be problematic.
did you bother to check the physical ports to see if any problems in the switch or with ethtool on the server interface ?
No, I didn't do it because i have good results using other opsys ...
thoughtfully consinder following advise of others re: tcp and dns
cables...
- rh
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, May 25, 2009 at 4:05 PM, carlopmart carlopmart@gmail.com wrote:
RobertH wrote:
ive read most of the thread, yet not all. forgive me as i might have
missed
some of this below in helping...
carlopmart,
what is in your /etc/resolv.conf
search hpulabs.org nameserver 127.0.0.1
is it configured correctly?
are you using ipv6?
no.
if not, is it fully disabled / turned off?
in modprobe.conf put
alias net-pf-10 off alias ipv6 off
I have configured this previously ..
reboot...
also, are you loading those other opsys on the same machine and getting
good
results or different machines?
I have good results using different operating systems but using same hardware ..
testing other opsys on different hardware could be problematic.
did you bother to check the physical ports to see if any problems in the switch or with ethtool on the server interface ?
No, I didn't do it because i have good results using other opsys ...
thoughtfully consinder following advise of others re: tcp and dns
cables...
- rh
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- CL Martinez carlopmart {at} gmail {d0t} com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Have you double checked your SELinux config?
You said you tested different OS'es on the same hardware? or tested different OS'es on the same hardware but different servers?
Maybe remotely could be a faulty NIC.
Victor Padro wrote:
On Mon, May 25, 2009 at 4:05 PM, carlopmart <carlopmart@gmail.com mailto:carlopmart@gmail.com> wrote:
RobertH wrote: > ive read most of the thread, yet not all. forgive me as i might have missed > some of this below in helping... > > carlopmart, > > what is in your /etc/resolv.conf search hpulabs.org <http://hpulabs.org> nameserver 127.0.0.1 > > is it configured correctly? > > are you using ipv6? no. > > if not, is it fully disabled / turned off? > > in modprobe.conf put > > alias net-pf-10 off > alias ipv6 off I have configured this previously .. > > reboot... > > also, are you loading those other opsys on the same machine and getting good > results or different machines? I have good results using different operating systems but using same hardware .. > > testing other opsys on different hardware could be problematic. > > did you bother to check the physical ports to see if any problems in the > switch or with ethtool on the server interface ? No, I didn't do it because i have good results using other opsys ... > > thoughtfully consinder following advise of others re: tcp and dns > > cables... > > - rh > > _______________________________________________ > CentOS mailing list > CentOS@centos.org <mailto:CentOS@centos.org> > http://lists.centos.org/mailman/listinfo/centos > -- CL Martinez carlopmart {at} gmail {d0t} com _______________________________________________ CentOS mailing list CentOS@centos.org <mailto:CentOS@centos.org> http://lists.centos.org/mailman/listinfo/centosHave you double checked your SELinux config?
SeLinux is disabled on both CentOS servers ...
You said you tested different OS'es on the same hardware? or tested different OS'es on the same hardware but different servers?
Same hardware and same server, because all opsys are installed on a ESXi 3.5u4 server with vmware tools ...
Maybe remotely could be a faulty NIC.
Maybe, but why only centos have problems??
-- "It is human nature to think wisely and act in an absurd fashion."
"Todo el desorden del mundo proviene de las profesiones mal o mediocremente servidas"
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, May 25, 2009 at 5:23 PM, carlopmart carlopmart@gmail.com wrote:
Victor Padro wrote:
On Mon, May 25, 2009 at 4:05 PM, carlopmart <carlopmart@gmail.com mailto:carlopmart@gmail.com> wrote:
RobertH wrote: > ive read most of the thread, yet not all. forgive me as i might have missed > some of this below in helping... > > carlopmart, > > what is in your /etc/resolv.conf
search hpulabs.org http://hpulabs.org nameserver 127.0.0.1
> > is it configured correctly? > > are you using ipv6?
no.
> > if not, is it fully disabled / turned off? > > in modprobe.conf put > > alias net-pf-10 off > alias ipv6 off
I have configured this previously ..
> > reboot... > > also, are you loading those other opsys on the same machine and getting good > results or different machines?
I have good results using different operating systems but using same hardware ..
> > testing other opsys on different hardware could be problematic. > > did you bother to check the physical ports to see if any problems in the > switch or with ethtool on the server interface ?
No, I didn't do it because i have good results using other opsys ... > > thoughtfully consinder following advise of others re: tcp and dns > > cables... > > - rh > > _______________________________________________ > CentOS mailing list > CentOS@centos.org mailto:CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos >
-- CL Martinez carlopmart {at} gmail {d0t} com _______________________________________________ CentOS mailing list CentOS@centos.org mailto:CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Have you double checked your SELinux config?
SeLinux is disabled on both CentOS servers ...
For what it is worth, you may want to double-check via chkconfig. I once told initial configuration of a CentOS box to disable SELinux, only to discover chkconfig still had it enabled. As soon as I told chkconfig to disable it, it was off.
Same for the firewall. During initial config, turned it off. chkconfig revealed it was on. I manually told chkconfig ip6tables off and iptables off, and only then did it stick.
It is worth double-checking these things - a simple chkconfig --list|grep :on to see what services are on they you may _not_ want on, and maybe, conversely, chkconfig --list|grep :off to check disabled services you may _want_ on.
Scott
You said you tested different OS'es on the same hardware? or tested different OS'es on the same hardware but different servers?
Same hardware and same server, because all opsys are installed on a ESXi 3.5u4 server with vmware tools ...
Maybe remotely could be a faulty NIC.
Maybe, but why only centos have problems??
-- "It is human nature to think wisely and act in an absurd fashion."
"Todo el desorden del mundo proviene de las profesiones mal o mediocremente servidas"
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- CL Martinez carlopmart {at} gmail {d0t} com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
At Mon, 25 May 2009 19:52:18 -0400 CentOS mailing list centos@centos.org wrote:
On Mon, May 25, 2009 at 5:23 PM, carlopmart carlopmart@gmail.com wrote:
Victor Padro wrote:
On Mon, May 25, 2009 at 4:05 PM, carlopmart <carlopmart@gmail.com mailto:carlopmart@gmail.com> wrote:
RobertH wrote: > ive read most of the thread, yet not all. forgive me as i might have missed > some of this below in helping... > > carlopmart, > > what is in your /etc/resolv.conf
search hpulabs.org http://hpulabs.org nameserver 127.0.0.1
> > is it configured correctly? > > are you using ipv6?
no.
> > if not, is it fully disabled / turned off? > > in modprobe.conf put > > alias net-pf-10 off > alias ipv6 off
I have configured this previously ..
> > reboot... > > also, are you loading those other opsys on the same machine and getting good > results or different machines?
I have good results using different operating systems but using same hardware ..
> > testing other opsys on different hardware could be problematic. > > did you bother to check the physical ports to see if any problems in the > switch or with ethtool on the server interface ?
No, I didn't do it because i have good results using other opsys ... > > thoughtfully consinder following advise of others re: tcp and dns > > cables... > > - rh > > _______________________________________________ > CentOS mailing list > CentOS@centos.org mailto:CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos >
-- CL Martinez carlopmart {at} gmail {d0t} com _______________________________________________ CentOS mailing list CentOS@centos.org mailto:CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Have you double checked your SELinux config?
SeLinux is disabled on both CentOS servers ...
For what it is worth, you may want to double-check via chkconfig. I once told initial configuration of a CentOS box to disable SELinux, only to discover chkconfig still had it enabled. As soon as I told chkconfig to disable it, it was off.
Same for the firewall. During initial config, turned it off. chkconfig revealed it was on. I manually told chkconfig ip6tables off and iptables off, and only then did it stick.
You don't want to use chkconfig to turn on/off the firewall (iptables). This is controled by the presense (or not) of /etc/sysconfig/iptables! Which in turn is controlled by system-config-securitylevel.
It is worth double-checking these things - a simple chkconfig --list|grep :on to see what services are on they you may _not_ want on, and maybe, conversely, chkconfig --list|grep :off to check disabled services you may _want_ on.
Scott
You said you tested different OS'es on the same hardware? or tested different OS'es on the same hardware but different servers?
Same hardware and same server, because all opsys are installed on a ESXi 3.5u4 server with vmware tools ...
Maybe remotely could be a faulty NIC.
Maybe, but why only centos have problems??
-- "It is human nature to think wisely and act in an absurd fashion."
"Todo el desorden del mundo proviene de las profesiones mal o mediocremente servidas"
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- CL Martinez carlopmart {at} gmail {d0t} com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, May 25, 2009 at 4:23 PM, carlopmart carlopmart@gmail.com wrote:
Victor Padro wrote:
On Mon, May 25, 2009 at 4:05 PM, carlopmart <carlopmart@gmail.com mailto:carlopmart@gmail.com> wrote:
RobertH wrote: > ive read most of the thread, yet not all. forgive me as i might have missed > some of this below in helping... > > carlopmart, > > what is in your /etc/resolv.conf search hpulabs.org <http://hpulabs.org> nameserver 127.0.0.1 > > is it configured correctly? > > are you using ipv6? no. > > if not, is it fully disabled / turned off? > > in modprobe.conf put > > alias net-pf-10 off > alias ipv6 off I have configured this previously .. > > reboot... > > also, are you loading those other opsys on the same machine and getting good > results or different machines? I have good results using different operating systems but using same hardware .. > > testing other opsys on different hardware could be problematic. > > did you bother to check the physical ports to see if any problems in the > switch or with ethtool on the server interface ? No, I didn't do it because i have good results using other opsys ... > > thoughtfully consinder following advise of others re: tcp and dns > > cables... > > - rh > > _______________________________________________ > CentOS mailing list > CentOS@centos.org <mailto:CentOS@centos.org> > http://lists.centos.org/mailman/listinfo/centos > -- CL Martinez carlopmart {at} gmail {d0t} com _______________________________________________ CentOS mailing list CentOS@centos.org <mailto:CentOS@centos.org> http://lists.centos.org/mailman/listinfo/centosHave you double checked your SELinux config?
SeLinux is disabled on both CentOS servers ...
You said you tested different OS'es on the same hardware? or tested different OS'es on the same hardware but different servers?
Same hardware and same server, because all opsys are installed on a ESXi 3.5u4 server with vmware tools ...
Maybe remotely could be a faulty NIC.
Maybe, but why only centos have problems??
-- "It is human nature to think wisely and act in an absurd fashion."
"Todo el desorden del mundo proviene de las profesiones mal o mediocremente servidas"
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- CL Martinez carlopmart {at} gmail {d0t} com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
So, the problem resides on an ESXi CentOS VM?
I thought you were using a dedicated server though.
If so, what are you using as a NIC?
Sometimes the driver for e1000 gets faulty on RHEL/CentOS VMs, happened to me a couple times, just add a new NIC to solve that.
Victor Padro wrote:
On Mon, May 25, 2009 at 4:23 PM, carlopmart <carlopmart@gmail.com mailto:carlopmart@gmail.com> wrote:
Victor Padro wrote: > > > On Mon, May 25, 2009 at 4:05 PM, carlopmart <carlopmart@gmail.com <mailto:carlopmart@gmail.com> > <mailto:carlopmart@gmail.com <mailto:carlopmart@gmail.com>>> wrote: > > RobertH wrote: > > ive read most of the thread, yet not all. forgive me as i might > have missed > > some of this below in helping... > > > > carlopmart, > > > > what is in your /etc/resolv.conf > > search hpulabs.org <http://hpulabs.org> <http://hpulabs.org> > nameserver 127.0.0.1 > > > > > is it configured correctly? > > > > are you using ipv6? > > no. > > > > > if not, is it fully disabled / turned off? > > > > in modprobe.conf put > > > > alias net-pf-10 off > > alias ipv6 off > > I have configured this previously .. > > > > > > reboot... > > > > also, are you loading those other opsys on the same machine and > getting good > > results or different machines? > > I have good results using different operating systems but using same > hardware .. > > > > > > testing other opsys on different hardware could be problematic. > > > > did you bother to check the physical ports to see if any problems > in the > > switch or with ethtool on the server interface ? > > No, I didn't do it because i have good results using other opsys ... > > > > thoughtfully consinder following advise of others re: tcp and dns > > > > cables... > > > > - rh > > > > _______________________________________________ > > CentOS mailing list > > CentOS@centos.org <mailto:CentOS@centos.org> <mailto:CentOS@centos.org <mailto:CentOS@centos.org>> > > http://lists.centos.org/mailman/listinfo/centos > > > > > -- > CL Martinez > carlopmart {at} gmail {d0t} com > _______________________________________________ > CentOS mailing list > CentOS@centos.org <mailto:CentOS@centos.org> <mailto:CentOS@centos.org <mailto:CentOS@centos.org>> > http://lists.centos.org/mailman/listinfo/centos > > > Have you double checked your SELinux config? SeLinux is disabled on both CentOS servers ... > > You said you tested different OS'es on the same hardware? or tested > different OS'es on the same hardware but different servers? Same hardware and same server, because all opsys are installed on a ESXi 3.5u4 server with vmware tools ... > > Maybe remotely could be a faulty NIC. Maybe, but why only centos have problems?? > > > > -- > "It is human nature to think wisely and act in an absurd fashion." > > "Todo el desorden del mundo proviene de las profesiones mal o > mediocremente servidas" > > > ------------------------------------------------------------------------ > > _______________________________________________ > CentOS mailing list > CentOS@centos.org <mailto:CentOS@centos.org> > http://lists.centos.org/mailman/listinfo/centos -- CL Martinez carlopmart {at} gmail {d0t} com _______________________________________________ CentOS mailing list CentOS@centos.org <mailto:CentOS@centos.org> http://lists.centos.org/mailman/listinfo/centosSo, the problem resides on an ESXi CentOS VM?
I thought you were using a dedicated server though.
If so, what are you using as a NIC?
Sometimes the driver for e1000 gets faulty on RHEL/CentOS VMs, happened to me a couple times, just add a new NIC to solve that.
-- "It is human nature to think wisely and act in an absurd fashion."
"Todo el desorden del mundo proviene de las profesiones mal o mediocremente servidas"
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
You are right, Victor. Very very strange, but using vmxnet driver problems disappears on these centos vms ... I don't understand why, because windows vms and ubuntu vms uses e1000 driver without problems ....
Many thanks to all for your help.
Les Mikesell wrote:
carlopmart wrote:
Les Mikesell wrote:
carlopmart wrote:
>>> Thanks lars. Correctly, firewall could be the problem, but it isn't. Because >> Ubuntu and Windows 2003/2008 doesn't have problems with it ... and resolves >> perfectly ... And I don't have configured this firewall to accept dns queries >> originating from source port 53 ... >> > What does 'dig' show about your access to the root servers without > forwarders and with and without forcing the query-source port? Compare > it to the Ubuntu system. Maybe there's something wrong with the root > hints file - or maybe your border firewall is blocking all udp to this > box but permitting it to the DNS servers that work. > Thanks Les, but I have checked it before post this problem. Ubuntu and CentOS have the same file to do querys to root servers ...
And the results of 'dig' on each?
I have find a temporary solution: reduce the MTU on CentOS server (1440) ...I need to investigate why centOS loses some packages and ubuntu doesn't ....
Are you routing through tunnels?
No, all hosts (firewall and CentOS DNS server) are connected to GByte network.
That's not where the problem is. Since you are working with forwarding on, the problem has to be when you try to go directly to the internet over UDP so it would be at the firewall or border router. When DNS fails, it will retry with TCP and that might be why it eventually works.
That's not possible, because firewall only permits DNS querys over UDP ...
I'd advise following the standards. If the response won't fit in a udp packet, it has to fail over to tcp.
Is there anything in the path to the internet that needs a lower MTU (perhaps a DNS line running PPOE)? Or do you have jumbo packets enabled on your Gig NIC?
No, but firewalls have a mtu configured with 1450 on external interfaces ...
Why?
Because It is a DSL line and cause errors using VPN connections if mtu it is 1500
And if you do need a small MTU, do you have firewalls
blocking the ICMP messages that are required to discover that automatically?
Yes, ICMP messages are blocked on firewall, but are blocked for all hosts: centos dns servers, ubuntu servers, windows servers ... i don't understand why using Ubuntu or windows servers to resolve names works ok and with centos (and with either rhel5. I have just check it) doesn't ...
The 'dig' response might give you a hint. But if all other network operations work OK, I'd still guess it is a firewall setting that you are missing.
ok, tested using dig:
[root@thranduil data]# dig www.mysql.com
; <<>> DiG 9.3.4-P1 <<>> www.mysql.com ;; global options: printcmd ;; connection timed out; no servers could be reached [root@thranduil data]# dig www.mysql.com
; <<>> DiG 9.3.4-P1 <<>> www.mysql.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30531 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION: ;www.mysql.com. IN A
;; ANSWER SECTION: www.mysql.com. 3600 IN A 213.136.52.29
;; AUTHORITY SECTION: mysql.com. 3600 IN NS ns1.sun.com. mysql.com. 3600 IN NS ns2.sun.com. mysql.com. 3600 IN NS ns7.sun.com. mysql.com. 3600 IN NS ns8.sun.com.
;; Query time: 3326 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon May 25 22:52:20 2009 ;; MSG SIZE rcvd: 123
I have opened 53/tcp and udp/53 on the firewall and the results are the same ... But I don't understand why only centos has this problems ... i think that I do some mistake on some configuration but i don't know where ....
On Mon, 2009-05-25 at 16:57 +0200, carlopmart wrote: <snip>
I have find a temporary solution: reduce the MTU on CentOS server (1440) ...I need to investigate why centOS loses some packages and ubuntu doesn't ....
--- What happens when you set the MTU for the type of Net Link you have? That goes for the switches and Routers also. Are the Links Auto Negotiated?
JohnStanley
On 2009-05-25 13:21, carlopmart wrote:
Paul Bijnens wrote:
On 2009-05-25 12:51, carlopmart wrote:
I have a problem using named with different CentOS5 servers (2 servers): all they are really slow to resolv any internet address and most of time fails to resolv. This situation differs if I use "forwarders" servers like opendns: resolving names it is really really quickly. And I don't understand why.
On the other hand I have tested three DNS servers using Windows 2003, Windows 2008 and Ubuntu hardy and these problems doesn't occurs (I don't need to configure forwarders on any of them): all resolves any name and really fast.
IPv6 is disabled on both CentOS servers. Somebody knows why these dns servers are slow??
My crystal ball is in repair. Could you in the meantime add some more hints, e.g. your config files, and how you diagnosed the slowness.
My CentOS5 DNS-servers do resolve really quickly, with or without forwarders.
Ok, my named.conf:
// // named.conf //
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; listen-on port 53 { 127.0.0.1; 172.25.50.10; }; version "DNS Server v2.0"; dnssec-enable no; query-source port 53; forwarders { 208.67.220.220; 208.67.222.222; }; };
logging { channel security_channel { file "/var/named/data/security.log" versions 3 size 1m; severity debug; print-time yes; print-category yes; print-severity yes; }; channel default { syslog local4; severity info; print-category yes; print-severity yes; }; channel query_log { file "/var/named/data/query.log" versions 3 size 1m; print-time yes; }; category security { security_channel; default; }; category queries { query_log; }; channel default_debug { file "/var/named/data/named.run"; severity dynamic; }; category lame-servers { null; }; category default { default; }; };
controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; };
When you're not using forwarding, the dns server should have some basic knowledge of the root servers. So add something like:
// prime the server with knowledge of the root servers zone "." { type hint; file "/path/to/the/file/having/named.root"; };
And the file itself can be downloaded (and updated now and then) from:
http://www.internic.net/zones/named.root
And to avoid forwarding on silly resolutions for localhost or 127.x.x.x you can do the same with a local "type master" zone for those two zones as well:
// be authoritative for the localhost forward and reverse zones zone "localhost" { type master; file "/path/to/the/file/having/localhost.zone"; }; zone "127.in-addr.arpa" { type master; file "/path/to/the/file/having/ptr-127.zone"; };
Paul Bijnens wrote:
On 2009-05-25 13:21, carlopmart wrote:
Paul Bijnens wrote:
On 2009-05-25 12:51, carlopmart wrote:
I have a problem using named with different CentOS5 servers (2 servers): all they are really slow to resolv any internet address and most of time fails to resolv. This situation differs if I use "forwarders" servers like opendns: resolving names it is really really quickly. And I don't understand why.
On the other hand I have tested three DNS servers using Windows 2003, Windows 2008 and Ubuntu hardy and these problems doesn't occurs (I don't need to configure forwarders on any of them): all resolves any name and really fast.
IPv6 is disabled on both CentOS servers. Somebody knows why these dns servers are slow??
My crystal ball is in repair. Could you in the meantime add some more hints, e.g. your config files, and how you diagnosed the slowness.
My CentOS5 DNS-servers do resolve really quickly, with or without forwarders.
Ok, my named.conf:
// // named.conf //
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; listen-on port 53 { 127.0.0.1; 172.25.50.10; }; version "DNS Server v2.0"; dnssec-enable no; query-source port 53; forwarders { 208.67.220.220; 208.67.222.222; }; };
logging { channel security_channel { file "/var/named/data/security.log" versions 3 size 1m; severity debug; print-time yes; print-category yes; print-severity yes; }; channel default { syslog local4; severity info; print-category yes; print-severity yes; }; channel query_log { file "/var/named/data/query.log" versions 3 size 1m; print-time yes; }; category security { security_channel; default; }; category queries { query_log; }; channel default_debug { file "/var/named/data/named.run"; severity dynamic; }; category lame-servers { null; }; category default { default; }; };
controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; };
When you're not using forwarding, the dns server should have some basic knowledge of the root servers. So add something like:
// prime the server with knowledge of the root servers zone "." { type hint; file "/path/to/the/file/having/named.root"; };
And the file itself can be downloaded (and updated now and then) from:
http://www.internic.net/zones/named.root
And to avoid forwarding on silly resolutions for localhost or 127.x.x.x you can do the same with a local "type master" zone for those two zones as well:
// be authoritative for the localhost forward and reverse zones zone "localhost" { type master; file "/path/to/the/file/having/localhost.zone"; }; zone "127.in-addr.arpa" { type master; file "/path/to/the/file/having/ptr-127.zone"; };
Thanks Paul, but I have configured this previously. I have posted only relevat parts about the topic.
On Mon, 2009-05-25 at 13:21 +0200, carlopmart wrote:
- Disabling "query-source port" and "forwarders" directives:
[root@thranduil data]# nslookup
www.google.com
;; connection timed out; no servers could be reached
Given that your resolv.conf only has 127.0.0.1 listed as a nameserver, this tends to indicate that named is either not running locally or it is responding very slowly. You might want to try running named with query-logging enabled (set the channel and log 'queries' to a separate file). This should then show you what queries it is receiving and how it is handling them.
John.
-
carlopmart -
John Horne -
JohnS -
Lars Hecking -
Les Mikesell -
Paul Bijnens -
Robert Heller -
RobertH -
Scott Ehrlich -
Victor Padro