RE: problems receiving e-mail to my server redux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux