Hi all,
My CentOS 5 nameserver is seemingly unable to be queried by anything but itself (localhost, 127.0.0.1). From any other machine, including the primary which *does* transfer zone files correctly to this machine (which is secondary), requests time out.
I've put SELinux into permissive mode, so I don't think that's an issue.
/var/named/chroot/etc/named.conf begins thus: ===================================== options { directory "/var/named/slaves"; listen-on { localhost; 127.0.0.1; 64.135.16.15; }; }; =====================================
I've placed a copy of resolv.conf in /etc/ as well as /var/named/chroot/etc as a result of seeing this message in /var/log/messages (the file in /etc/ had been a symlink to the file in the chrooted path before this)
Aug 22 13:10:06 sunspot restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) No such file or directory
/etc/init.d/named status returns:
[root@sunspot etc]# /etc/init.d/named status number of zones: 172 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/1000 tcp clients: 0/100 server is up and running
So....while I'm sure it's simple, I'm stumped.
Any help will be greatly appreciated.
Kind regards, ~Ray
Ray Leventhal wrote:
Hi all,
My CentOS 5 nameserver is seemingly unable to be queried by anything but itself (localhost, 127.0.0.1). From any other machine, including the primary which *does* transfer zone files correctly to this machine (which is secondary), requests time out.
I've put SELinux into permissive mode, so I don't think that's an issue.
/var/named/chroot/etc/named.conf begins thus:
options { directory "/var/named/slaves"; listen-on { localhost; 127.0.0.1; 64.135.16.15; }; }; =====================================
Are you using views? If you only have a 'localhost' view (kind how namecacheserver is set up), then no one else can query.
Do you have match-clients and match-destinations set up? I think the default for these are 'any', but if you have them and they are wrong?
I've placed a copy of resolv.conf in /etc/ as well as /var/named/chroot/etc as a result of seeing this message in /var/log/messages (the file in /etc/ had been a symlink to the file in the chrooted path before this)
Aug 22 13:10:06 sunspot restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) No such file or directory
/etc/init.d/named status returns:
[root@sunspot etc]# /etc/init.d/named status number of zones: 172 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/1000 tcp clients: 0/100 server is up and running
So....while I'm sure it's simple, I'm stumped.
Any help will be greatly appreciated.
Kind regards, ~Ray _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ray Leventhal wrote:
Hi all,
My CentOS 5 nameserver is seemingly unable to be queried by anything but itself (localhost, 127.0.0.1). From any other machine, including the primary which *does* transfer zone files correctly to this machine (which is secondary), requests time out.
I've put SELinux into permissive mode, so I don't think that's an issue.
Are you running the firewall and have DNS allowed?
This is a separate issue from SELinux.
/var/named/chroot/etc/named.conf begins thus:
options { directory "/var/named/slaves"; listen-on { localhost; 127.0.0.1; 64.135.16.15; }; }; =====================================
Do a netstat -na|grep 53
Lets be really sure.
<snip>
Do a netstat -na|grep 53
Lets be really sure.
Hi Robert,
Thanks for the reply.
as requested:
[root@sunspot ray]# netstat -na|grep 53 tcp 0 0 64.135.16.15:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN tcp 0 0 ::1:953 :::* LISTEN udp 0 0 64.135.16.15:53 0.0.0.0:* udp 0 0 127.0.0.1:53 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 :::5353 :::* unix 3 [ ] STREAM CONNECTED 8253 unix 3 [ ] STREAM CONNECTED 6953 /var/run/audit_events
Appears to be listening how I expected it to be, unless I'm not reading this right.
Thanks again, ~Ray
Hello Ray,
Appears to be listening how I expected it to be, unless I'm not reading this right.
Running 'dig www.swhi.net @64.135.16.15'
; <<>> DiG 9.2.4 <<>> www.swhi.net @64.135.16.15 ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached
Robert suggested looking at your firewall. What rules do you have related to port 53 udp?
Feizhou wrote:
Hello Ray,
Appears to be listening how I expected it to be, unless I'm not reading this right.
Running 'dig www.swhi.net @64.135.16.15'
; <<>> DiG 9.2.4 <<>> www.swhi.net @64.135.16.15 ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached
Robert suggested looking at your firewall. What rules do you have related to port 53 udp? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Feizhou,
As I'm not at all expert in my understanding of iptables I can't say definitely that there are any rules on port 53 udp but, here's the output of /sbin/iptables -L:
[root@sunspot ray]# /sbin/iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT esp -- anywhere anywhere ACCEPT ah -- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT tcp -- anywhere anywhere tcp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
From what is posted above, does it appear that iptables is the issue?
Thanks for all the help and advice!
Kind regards, ~Ray
From what I see you have iptables 'in the way'.
Try to add the following rule to iptables and then try again :) iptables -I RH-Firewall-1-INPUT -j ACCEPT -p udp --dport 53
If you like to have zone transfers or large queries done as well then you also need to open a port for tcp/53 iptables -I RH-Firewall-1-INPUT -j ACCEPT -p tcp --dport 53
(to make the changes permanent do a 'service iptables save' after adding the lines)
Regards,
Michel
On Thu, 23 Aug 2007 08:28:05 -0400, Ray Leventhal wrote
Feizhou wrote:
Hello Ray,
Appears to be listening how I expected it to be, unless I'm not reading this right.
Running 'dig www.swhi.net @64.135.16.15'
; <<>> DiG 9.2.4 <<>> www.swhi.net @64.135.16.15 ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached
Robert suggested looking at your firewall. What rules do you have related to port 53 udp? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Feizhou,
As I'm not at all expert in my understanding of iptables I can't say definitely that there are any rules on port 53 udp but, here's the output of /sbin/iptables -L:
[root@sunspot ray]# /sbin/iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT esp -- anywhere anywhere ACCEPT ah -- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT tcp -- anywhere anywhere tcp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
From what is posted above, does it appear that iptables is the issue?
Thanks for all the help and advice!
Kind regards, ~Ray _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
BEGIN-ANTISPAM-VOTING-LINKS
Teach CanIt if this mail (ID 900640) is spam: Spam: http://neelix.grote.net/canit/b.php?c=s&i=900640&m=45a487d73292 Not spam: http://neelix.grote.net/canit/b.php?c=n&i=900640&m=45a487d73292 Forget vote: http://neelix.grote.net/canit/b.php?c=f&i=900640&m=45a487d73292
END-ANTISPAM-VOTING-LINKS
-- Het.Grote.Net WebMail, powered by OpenWebMail --
<big snip> Michel van Deventer wrote:
From what I see you have iptables 'in the way'.
Try to add the following rule to iptables and then try again :) iptables -I RH-Firewall-1-INPUT -j ACCEPT -p udp --dport 53
If you like to have zone transfers or large queries done as well then you also need to open a port for tcp/53 iptables -I RH-Firewall-1-INPUT -j ACCEPT -p tcp --dport 53
(to make the changes permanent do a 'service iptables save' after adding the lines)
Regards,
Michel
Hi Michel,
Thank you! I applied the udp rule and all appears well.
This server is already receiving zones correctly. The primary feeding it will not likely ever have more than 300 zones. Does that qualify as 'large queries' to the point where the tcp rule should be applied as well?
Thanks again for all help offered. The community support for CentOS has solidified my confidence as having chosen CentOS as my distro of choice.
Many thanks and kind regards, ~Ray
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Ray Leventhal Sent: Thursday, August 23, 2007 10:23 AM To: CentOS mailing list Subject: Re: [CentOS] BIND issues, server not responding
<big snip> Michel van Deventer wrote: > >From what I see you have iptables 'in the way'. > Try to add the following rule to iptables and then try again :) > iptables -I RH-Firewall-1-INPUT -j ACCEPT -p udp --dport 53 > > If you like to have zone transfers or large queries done as well then you also > need to open a port for tcp/53 > iptables -I RH-Firewall-1-INPUT -j ACCEPT -p tcp --dport 53 > > (to make the changes permanent do a 'service iptables save' after adding the > lines) > > Regards, > > Michel > > >
Hi Michel,
Thank you! I applied the udp rule and all appears well.
This server is already receiving zones correctly. The primary feeding it will not likely ever have more than 300 zones. Does that qualify as 'large queries' to the point where the tcp rule should be applied as well?
Thanks again for all help offered. The community support for CentOS has solidified my confidence as having chosen CentOS as my distro of choice.
You only need the tcp rule if you plan on serving up zone transfers, not if plan on only requesting them.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
You only need the tcp rule if you plan on serving up zone transfers, not if plan on only requesting them.
Well, very rare but answers that are over 512 bytes will have to be sent over tcp since the rfc 1035 mandates maximum 512 bytes for the udp payload. So tcp is not just for zone transfers only.
On Thu, 23 Aug 2007, Feizhou wrote:
You only need the tcp rule if you plan on serving up zone transfers, not if plan on only requesting them.
Well, very rare but answers that are over 512 bytes will have to be sent over tcp since the rfc 1035 mandates maximum 512 bytes for the udp payload. So tcp is not just for zone transfers only.
Note that by default Win 2003 uses a packet size of 1280 per Paul Vixie's suggestion in RFC 2671 section 4.5.1. I don't know if any other OS implementations do the same.
In any event, I've found it helpful to allow up to 1280 bytes of DNS UDP traffic. Setting the limit at 512 triggers a noticable number of retries, at least in our environment.
Paul Heinlein wrote:
On Thu, 23 Aug 2007, Feizhou wrote:
You only need the tcp rule if you plan on serving up zone transfers, not if plan on only requesting them.
Well, very rare but answers that are over 512 bytes will have to be sent over tcp since the rfc 1035 mandates maximum 512 bytes for the udp payload. So tcp is not just for zone transfers only.
Note that by default Win 2003 uses a packet size of 1280 per Paul Vixie's suggestion in RFC 2671 section 4.5.1. I don't know if any other OS implementations do the same.
In any event, I've found it helpful to allow up to 1280 bytes of DNS UDP traffic. Setting the limit at 512 triggers a noticable number of retries, at least in our environment.
Sigh. I can see some caching servers with big scissors to apply to udp packets...if they at all issue queries that get such large replies...
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Feizhou Sent: Thursday, August 23, 2007 11:02 AM To: CentOS mailing list Subject: Re: [CentOS] BIND issues, server not responding
You only need the tcp rule if you plan on serving up zone transfers, not if plan on only requesting them.
Well, very rare but answers that are over 512 bytes will have to be sent over tcp since the rfc 1035 mandates maximum 512 bytes for the udp payload. So tcp is not just for zone transfers only.
True, but the client will then be responsible for opening up the tcp session and since it will be EST, there is no need to define incoming SYN packets no?
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
You only need the tcp rule if you plan on serving up zone transfers, not if plan on only requesting them.
Well, very rare but answers that are over 512 bytes will have to be sent over tcp since the rfc 1035 mandates maximum 512 bytes for the udp payload. So tcp is not just for zone transfers only.
True, but the client will then be responsible for opening up the tcp session and since it will be EST, there is no need to define incoming SYN packets no?
Hmm...no idea if a stateful udp role involves tcp at all...this requires a netfilter dude to answer :-D
Chain RH-Firewall-1-INPUT (2 references)
ugh. I absolutely detest the tool behind this.
This is what I do.
Trusted interfaces like lo and networks go first and then packets belonging to established connections are shorted which leaves connection requests to be branched out into tcp, udp and icmp chains. Further branching can then be done as desired. Eg: If you firewall a lot of spam sources, you could test for smtp packets going to port 25 and branch those out to another chain that deals solely with the spam sources and spare other connection requests having to go through rules that they are definitely not going to match.
iptables -L -n Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 10.9.0.0/17 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED tcp_packets tcp -- 0.0.0.0/0 0.0.0.0/0 udp_packets udp -- 0.0.0.0/0 0.0.0.0/0 icmp_packets icmp -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Chain icmp_packets (1 references) target prot opt source destination ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 11 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
Chain tcp_packets (1 references) target prot opt source destination REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 reject-with tcp-reset ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:993 state NEW ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:143 state NEW ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:587 state NEW ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:465 state NEW ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:1194 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 state NEW ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:110
Chain udp_packets (1 references) target prot opt source destination ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:123
-
Feizhou -
Michel van Deventer -
Paul Heinlein -
Ray Leventhal -
Robert Moskowitz -
Ross S. W. Walker