problems receiving e-mail to my server redux
Cowles, Steve
steve at stevecowles.com
Wed Jul 7 17:07:31 UTC 2004
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
More information about the redhat-list
mailing list