Ray,

See below....

<snipped>
>"failures" actually are DNS-based delays, is the right guess ... and
>that
>"quite a while" is around 3 minutes.

It takes about a minute and a half to get a response with telnet.

>What to do about it?
>
>First, maybe your mail server can be configured not to do reverse
>lookups.
>I'm not a qmail expert so can't help there.
I have not found any source so far that tells me how to configure it. I am considering 
asking on the qmail list but since the lrp setup is different, The responses are often 
hard to follow when asked to compare setup info.

>Second, if you do not want your mail server to be able to do DNS
>lookups,
>then the router's response -- an icmp "port unreachable" response --
>is a
>correct response. A slightly better response is to send a udp REJECT
>packet
>.... some clients recognize this but do not understand icmp port
>unreachable
>(dig through ancient archives for discussion of why LEAF routers
>normally
>leave port 113 open for the theory here). You would do this by
>adding a
>Shorewall rule to ACCEPT dport-53-udp traffic from the DMZ.

I have had ACCEPT          dmz             fw              udp     53   in place all 
along/

>
>Third, if you do want your mail server to be able to resolve these
>reverse
>lookups ... where do you want it to do so? What DNS server (or orher
>mechanism) do you want to provide? Options (for these on-LAN
>lookups) are:
>
>put the information in /etc/hosts on the DMZ machine (this may or
>
>may not work with qmail; MTAs are notorious for using ONLY DNS, not
>/etc/hosts, and I don't know about qmail in this regard)

I tried the hosts file but it does not seem to help.

>run a DNS sever authoritative for the LAN on the LEAF router
>
>run a DNS server authoritative for the LAN on the LEAF mail
>server
>
>run a DNS server authoritative for the LAN on some LAN host, and
>
>let the DMZ server have access to it through the firewall (this is
>what I
>do here, running BIND on a full-strength-Linux LAN server).
>
>From your comments below, it appears you are trying to do #2, using
>tinydns. If you want to do it that way, someone else will have to
>answe
>those questions, as I've never set up that package (on LEAF or any
>other
>host) ... as I recall, it has problems lsitening on multiple
>interfaces ...
>but I may be remembering wrong.

I think I am doing #1. I have no DNS packages running on the DMZ host.
I have tried to set the router as a default dns server for bothe the dmz and loc 
networks. It works for lookups resolving internet hosts.
I will repost and ask what the proper setup is for dns service to resolve my 2 
internal networks.


>Sorry I cannot take you all the way to an answer, but with the
>problem
>identified as a DNS misconfiguration, surely someone else here knows
>the
>details you need to wrap this up.

Thanks for alll the help. I know more now than when I started.

Kory

>
>At 09:32 PM 12/21/2003 -0500, Kory Krofft wrote:

>>the tcpdump output you sent indicates that after
>>>the
>>>POP3
>>>connection is initiated, the POP3 server is trying to do a reverse
>>>lookup
>>>on the source IP address. Several packets indicate  this, the
>>>first
>>>being --
>>>
>>>16:37:26.524013 192.168.10.1.59258 > 192.168.1.254.53:  28701+
>>>
>>>PTR? 1.10.168.192.in-addr.arpa. (43) (DF)
>>>
>>>The router responds with a "port unreachable" packet:
>>>
>>>16:37:29.547086 192.168.10.254 > 192.168.10.1: icmp:
>>>192.168.10.254 udp port 53 unreachable [tos 0xc0]
>>>
>>>This certainly indicates some sort of a configuration error, but
>>>not
>>>knowing the details of your setup, I can;t say what that error is.
>>>It does
>>>make me guess that the POP3 server does not reply, after the
>>>initial
>>>reply,
>>>because it cannot do a lookup on the IP address. Or ... a blue-sky
>>>thought
>>>here ... how long do you wait before giving up? DNS failures can,
>>>in
>>>some
>>>cases, cause delays of up  to 3 minutes in responses.
>>>
>>What would be the proper way for the router to reply to this
>>reverse lookup?
>>/etc/hosts on the router looks like this:
>>127.0.0.1       localhost.kroffts.home localhost
>>192.168.1.254   markii
>>192.168.1.1     coventry.kroffts.home coventry
>>192.168.10.1    www.kroffts.com dmz kroffts_web
>>
>>/etc/resolv.conf on router:
>>domain kroffts.home
>>nameserver 127.0.0.1
>>nameserver 192.168.1.254
>>
>>/etc/hosts on dmz:
>>127.0.0.1       localhost
>>192.168.1.254   markii
>>192.168.10.1    kroffts_web.kroffts.com kroffts_web mail.kroffts.com
>>191.168.1.1     coventry.kroffts.home   coventry
>>
>>
>>/etc/resolv.conf on dmz:
>>domain kroffts.com
>>nameserver 127.0.0.1
>>nameserver 192.168.1.254
>>nameserver 192.168.10.254
>>
>>What can you tell me about The /etc/tinydns-private/root/data file
>>from
>>the router? Does this look correct?
>>
>>kroffts.home::localhost
>>1.168.192.in-addr.arpa::localhost
>>+markii.kroffts.home:192.168.1.254    <the router>
>>=mail.kroffts.com:192.168.10.1          <the dmz host>
>>
>>I am not running any DNS daemons on the dmz. Should I be? I had
>>wanted to
>>use DHCP to configure the DMZ host but I could not get it to work
>>on two
>>separate networks. I know it should, but it didn't so I set up the
>>eth0 on
>>the dmz host as static.
>>from the /etc/network/interfaces file on the dmz host:
>>
>>auto eth0
>>iface eth0 inet static
>>address 192.168.10.1
>>masklen 24
>>broadcast 192.168.10.255
>>gateway   192.168.10.254
>>




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to