Re: [CentOS] BIND issues, server not responding
snip not certain if you intend it to be, but your 64.135.16.15 machine is not reachable from outside. an attempt to telnet to port 53 (or 25) gets me no route to host and a traceroute ends with: 8 ge2-0.cr1.bct.fl.host.net (64.135.1.9) 34.779ms 35.102ms 35.413ms 9 ge6-1.er8.bct.fl.host.net (64.135.1.58) 34.934ms 34.219ms 35.044ms 10 sunspot.swhi.net (64.135.16.15) 34.653 ms !10 34.619 ms !10 35.739 ms !10 so, from the outside, it appears that you have a firewall block (or network configuration problem). my read is that the block is at the machine, not an edge router, so this may be the source of your problem. try doing a telnet to port 53 on 64.135.16.15 (based on past messages i think that that's the correct ipnumber) from some local machine and see what you get. if it's listening you should get a connect message (even if there are access restrictions in named.conf). if you get something else, that should give a hint on where to look. - Rick Hi Rick, Telnetting on port 53 from a machine in the same /24 gives this: [EMAIL PROTECTED] ray]$ telnet 64.135.16.15 53 Trying 64.135.16.15... telnet: connect to address 64.135.16.15: No route to host Thanks for your input. I welcome any suggestions. Kind regards, ~Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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. Many thanks and kind regards, ~Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] BIND issues, server not responding
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] BIND issues, server not responding
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/00.0.0.0/0 ACCEPT all -- 0.0.0.0/00.0.0.0/0 ACCEPT all -- 10.9.0.0/17 0.0.0.0/0 ACCEPT all -- 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED tcp_packets tcp -- 0.0.0.0/00.0.0.0/0 udp_packets udp -- 0.0.0.0/00.0.0.0/0 icmp_packets icmp -- 0.0.0.0/00.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/00.0.0.0/0 icmp type 3 ACCEPT icmp -- 0.0.0.0/00.0.0.0/0 icmp type 11 ACCEPT icmp -- 0.0.0.0/00.0.0.0/0 icmp type 8 Chain tcp_packets (1 references) target prot opt source destination REJECT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:113 reject-with tcp-reset ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:443 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:53 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:80 state NEW ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:25 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:993 state NEW ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:143 state NEW ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:587 state NEW ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:465 state NEW ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:1194 ACCEPT tcp -- 0.0.0.0/00.0.0.0/0 tcp dpt:21 state NEW ACCEPT tcp -- 0.0.0.0/00.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/00.0.0.0/0 state NEW udp dpt:53 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 udp spt:123 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] BIND issues, server not responding
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] BIND issues, server not responding
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... ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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? Hmm...no idea if a stateful udp role involves tcp at all...this requires a netfilter dude to answer :-D ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] BIND issues, server not responding
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:
[EMAIL PROTECTED] 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
Sowhile 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
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] BIND issues, server not responding
[EMAIL PROTECTED] wrote: first, if you turn query logging on you'll likely get some more hints. Rick, I did miss that comment before I posted. I'll do that and query...will report the log here this evening. Kind regards, ~Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] BIND issues, server not responding
Ray Leventhal wrote: [EMAIL PROTECTED] wrote: first, if you turn query logging on you'll likely get some more hints. Rick, I did miss that comment before I posted. I'll do that and query...will report the log here this evening. Kind regards, ~Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Ok...turned query logging on, but still the same issue persists. TA for all help offered. ~Ray ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] BIND issues, server not responding
snip Do a netstat -na|grep 53 Lets be really sure. Hi Robert, Thanks for the reply. as requested: [EMAIL PROTECTED] ray]# netstat -na|grep 53 tcp0 0 64.135.16.15:53 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:953 0.0.0.0:* LISTEN tcp0 0 ::1:953 :::*LISTEN udp0 0 64.135.16.15:53 0.0.0.0:* udp0 0 127.0.0.1:530.0.0.0:* udp0 0 0.0.0.0:53530.0.0.0:* udp0 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 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] BIND issues, server not responding
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
