Ed McCorduck wrote: > Hi, some of you may remember my postings from a few months ago > regarding the problems I was having with my RH 9-based Web and e-mail > server. Some of the problems have been resolved, namely my Web server > now works mostly fine, i.e. people have no problem accessing the Web > pages housed on my server through the fully-qualified domain name > assigned to my home network (which redirects all Web-page requests to > the sole RH 9 Linux box on my network), and also I can send e-mail to > any outside domain and it's addressed as coming from my domain name's > e-mail server. However, I still cannot receive any Internet mail to > my domain name, even mail that's in direct reply to the > above-mentioned type of mail I send successfully to other servers. > That is, the mail always bounces with an indication that my domain > name can't be found, which again is strange since there is no problem > accessing my domain name when it's for my Web pages. In addition to what Will McDonald pointed out in his reply... There seems to be a problem with NAT'ing by either your ISP or your firewall configuration. Example: using dig's trace option from my end... # dig +trace mccorduck.ws ; <<>> DiG 9.2.3 <<>> +trace mccorduck.ws ;; global options: printcmd . 17252 IN NS F.ROOT-SERVERS.NET. . 17252 IN NS G.ROOT-SERVERS.NET. . 17252 IN NS H.ROOT-SERVERS.NET. . 17252 IN NS I.ROOT-SERVERS.NET. . 17252 IN NS J.ROOT-SERVERS.NET. . 17252 IN NS K.ROOT-SERVERS.NET. . 17252 IN NS L.ROOT-SERVERS.NET. . 17252 IN NS M.ROOT-SERVERS.NET. . 17252 IN NS A.ROOT-SERVERS.NET. . 17252 IN NS B.ROOT-SERVERS.NET. . 17252 IN NS C.ROOT-SERVERS.NET. . 17252 IN NS D.ROOT-SERVERS.NET. . 17252 IN NS E.ROOT-SERVERS.NET. ;; Received 372 bytes from 127.0.0.1#53(127.0.0.1) in 11 ms ws. 172800 IN NS NS4.DNS.ws. ws. 172800 IN NS NS5.DNS.ws. ws. 172800 IN NS NS1.DNS.ws. ws. 172800 IN NS NS2.DNS.ws. ws. 172800 IN NS NS3.DNS.ws. ;; Received 204 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 73 ms mccorduck.ws. 21600 IN A 24.24.15.155 mccorduck.ws. 21600 IN NS mccorduck.ws. ;; Received 76 bytes from 216.52.234.102#53(NS4.DNS.ws) in 60 ms So the recursion back from the root servers which eventaully point to mccordick.ws are in place, but a DNS query to the listed IP address (SOA) for mccorduck.ws (24.24.15.155) fails # dig @24.24.15.155 mccorduck.ws soa ; <<>> DiG 9.2.3 <<>> @24.24.15.155 mccorduck.ws soa ;; global options: printcmd ;; connection timed out; no servers could be reached Furthermore, my firewall is logging an entry everytime it tries to query your name server. Note the RFC1918 192.168.1.101 listed for the ICMP port unreachable. BTW: Is 192.168.1.101 possibly a host behind your firewall??? Jul 7 10:19:50 firewall-dmz kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:70:97:a6:1d:e4:00:02:3b:01:7b:dd:0a:00 SRC=24.24.15.155 DST=xx.xx.xx.xx LEN=86 TOS=0x00 PREC=0xC0 TTL=55 ID=18158 PROTO=ICMP TYPE=3 CODE=3 [SRC=xx.xx.xx.xx DST=192.168.1.101 LEN=58 TOS=0x00 PREC=0x00 TTL=53 ID=1 DF PROTO=UDP SPT=34055 DPT=53 LEN=38 ] The xx.xx.xx.xx is the external IP address of my firewall. For an excellent description of what the above log entry means, checkout: http://www.shorewall.net/FAQ.htm#faq21 Also, a tcpdump during the query from my firewall confirms where the problem is. tcpdump: listening on eth0 10:19:50.527221 xx.xx.xx.xx.34062 > 24.24.15.155.53: 1884+ SOA? mccorduck.ws. (30) (DF) 10:19:50.630150 24.24.15.155 > xx.xx.xx.xx: icmp: 192.168.1.101 udp port 53 unreachable [tos 0xc0] Finally, a disection of the reply packet from your end using ethereal... Note that layer 3 source/dest is correct, but layer 4 (ICMP) destination is not being properly re-written for some reason. Frame 3 (100 bytes on wire, 100 bytes captured) Ethernet II, Src: 00:02:3b:01:7b:dd, Dst: 00:70:97:a6:1d:e4 Internet Protocol, Src Addr: 24.24.15.155 (24.24.15.155), Dst Addr: xx.xx.xx.xx (xx.xx.xx.xx) Version: 4 Header length: 20 bytes Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00) Total Length: 86 Identification: 0xe669 (58985) Flags: 0x00 Fragment offset: 0 Time to live: 55 Protocol: ICMP (0x01) Header checksum: 0xff15 (correct) Source: 24.24.15.155 (24.24.15.155) Destination: xx.xx.xx.xx (xx.xx.xx.xx) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Checksum: 0x34f7 (correct) Internet Protocol, Src Addr: xx.xx.xx.xx (xx.xx.xx.xx), Dst Addr: 192.168.1.101 (192.168.1.101) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 58 Identification: 0x0000 (0) Flags: 0x04 Fragment offset: 0 Time to live: 53 Protocol: UDP (0x11) Header checksum: 0x0df1 (correct) Source: xx.xx.xx.xx (xx.xx.xx.xx) Destination: 192.168.1.101 (192.168.1.101) User Datagram Protocol, Src Port: 34070 (34070), Dst Port: domain (53) Source port: 34070 (34070) Destination port: domain (53) Length: 38 Checksum: 0x024b (correct) Domain Name System (query) Transaction ID: 0x25a6 Flags: 0x0100 (Standard query) Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries mccorduck.ws: type SOA, class inet Name: mccorduck.ws Type: Start of zone of authority Class: inet Based on the above... 1) I would start by checking your firewall configuration 2) Is there a router at your ISP that is possibly causing this problem. Steve Cowles -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
