problems receiving e-mail to my server redux

Ed McCorduck Ed.McCorduck at Cortland.edu
Thu Jul 8 21:54:41 UTC 2004


> -----Original Message-----
> From: Cowles, Steve [mailto:steve at stevecowles.com]
> Sent: Wednesday, July 07, 2004 1:08 PM
> To: 'General Red Hat Linux discussion list'
> Subject: RE: problems receiving e-mail to my server redux
> 
> 
> 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


Thanks for your very detailed reply, Steve. I'll try to dig through your
mine of information as best as I am able, but unfortunately it's mostly
way over my head at the present state of my newbie knowledge. At least I
understand one of your questions, though, and perhaps my answer can shed
more light on the problem: 

> BTW: Is 192.168.1.101 possibly a host behind your firewall???

Yes, 192.168.1.101 is the IP address that I maintain for my Linux
computer, which houses my Web and e-mail (sendmail) servers. My
firewall, which is an integral part of my Linksys router for my home
network, I set up through Port Forwarding to send all port 25, 80 and
110 queries to this computer.  


Ed McCorduck
Department of English
State University of New York College at Cortland 
http://mccorduck.cortland.edu 
ICQ: http://mccorduck.cortland.edu/pager  
AIM: EdMcCorduck





More information about the redhat-list mailing list