Postfix smtpd DNS lookup delay - Suse

This is a discussion on Postfix smtpd DNS lookup delay - Suse ; Hi all I maintain 3 sites that run SuSE 9.3 and postfix/cyrus imap. I am having an irritating smtp client delay problem (ie email stays in Outlook mailbox for maybe 5-10 secs) on 2 of the 3 sites. These two ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Postfix smtpd DNS lookup delay

  1. Postfix smtpd DNS lookup delay

    Hi all

    I maintain 3 sites that run SuSE 9.3 and postfix/cyrus imap. I am having
    an irritating smtp client delay problem (ie email stays in Outlook
    mailbox for maybe 5-10 secs) on 2 of the 3 sites. These two sites are
    running the standard 9.3 BIND9 whereas the site that works is running
    without fault has a W2003 server DNS.

    I understand the normal DNS setup requirements for postfix. MX records
    exist and the clients (and server & domain) resolve instantly (fwd and
    rev) at the command line. As a temporary workaround adding the clients
    to /etc/hosts removes the delay problem.

    If I enable smtpd debugging with no /etc/host record I get this in the
    mail log file after 5-10 secs;

    wcetfps postfix/smtpd[2760]: connect from unknown[192.168.0.240]
    wcetfps postfix/smtpd[2760]: match_hostname: unknown ~? 192.168.0.0/21
    wcetfps postfix/smtpd[2760]: match_hostaddr: 192.168.0.240 ~? 192.168.0.0/21

    With the /etc/host record in place I get this in the mail log instantly.

    wcetfps postfix/smtpd[5114]: connect from p600.local[192.168.0.240]
    wcetfps postfix/smtpd[5114]: match_hostname: p600.local ~? 192.168.0.0/21
    wcetfps postfix/smtpd[5114]: match_hostaddr: 192.168.0.240 ~? 192.168.0.0/21

    This kind of implies that the lookup is failing BEFORE it even starts
    the smtpd conversation. It is all kind of puzzling given the instant
    name resolution on the command line. Before anyone asks there is no
    firewalling in the way. It is normal BTW to get these unknown errmsgs on
    the public side of the server, mainly from spammers with no MX records.

    There is a lot of Googling data out there on this kind of problem. Much
    of it though is due to MX name resolution so is hard to filter. It would
    be nice of course to have a postfix DNS records checklist but I am
    pretty sure I have all of them covered. The following seems a good source;

    http://bind8nt.meiway.com/itsaDNSmess.cfm

    Does anyone know exactly what the first smtpd session message is
    resolving and how? Any another thoughts appreciated.

    Bob

  2. Re: Postfix smtpd DNS lookup delay

    On 2007-09-26 13:25, Bob Bob wrote:
    > Hi all
    >
    > I maintain 3 sites that run SuSE 9.3 and postfix/cyrus imap. I am having
    > an irritating smtp client delay problem (ie email stays in Outlook
    > mailbox for maybe 5-10 secs) on 2 of the 3 sites. These two sites are
    > running the standard 9.3 BIND9 whereas the site that works is running
    > without fault has a W2003 server DNS.
    >
    > I understand the normal DNS setup requirements for postfix. MX records
    > exist and the clients (and server & domain) resolve instantly (fwd and
    > rev) at the command line. As a temporary workaround adding the clients
    > to /etc/hosts removes the delay problem.
    >
    > If I enable smtpd debugging with no /etc/host record I get this in the
    > mail log file after 5-10 secs;
    >
    > wcetfps postfix/smtpd[2760]: connect from unknown[192.168.0.240]
    > wcetfps postfix/smtpd[2760]: match_hostname: unknown ~? 192.168.0.0/21
    > wcetfps postfix/smtpd[2760]: match_hostaddr: 192.168.0.240 ~? 192.168.0.0/21
    >
    > With the /etc/host record in place I get this in the mail log instantly.
    >
    > wcetfps postfix/smtpd[5114]: connect from p600.local[192.168.0.240]
    > wcetfps postfix/smtpd[5114]: match_hostname: p600.local ~? 192.168.0.0/21
    > wcetfps postfix/smtpd[5114]: match_hostaddr: 192.168.0.240 ~? 192.168.0.0/21
    >
    > This kind of implies that the lookup is failing BEFORE it even starts
    > the smtpd conversation. It is all kind of puzzling given the instant
    > name resolution on the command line. Before anyone asks there is no
    > firewalling in the way. It is normal BTW to get these unknown errmsgs on
    > the public side of the server, mainly from spammers with no MX records.
    >
    > There is a lot of Googling data out there on this kind of problem. Much
    > of it though is due to MX name resolution so is hard to filter. It would
    > be nice of course to have a postfix DNS records checklist but I am
    > pretty sure I have all of them covered. The following seems a good source;
    >
    > http://bind8nt.meiway.com/itsaDNSmess.cfm
    >
    > Does anyone know exactly what the first smtpd session message is
    > resolving and how? Any another thoughts appreciated.
    >
    > Bob


    Ohh, is there one more like me :-)

    I also _still_ run postfix/cyrus on the old and "EOL" suse9.3 box,
    and have 4 sites :-)

    Now it was many years since I installed it, but the first I did was to turn of
    ipv6. ( postconf |grep inet_protocols )
    If you have "all" , just do postconf -e inet_protocols=ipv4 to change it.

    In my case, I also run named since I have some domains, and are slave for
    others, so I made local zones for my 192.168 networks before even starting
    postfix, so I have never had your problem, my postfix is very fast, at least
    until it start parsing the spam filters.

    I have no answer to your question, but in general, I have no problems yet,
    but must as you also should do, start to upgrade the **** to a modern suse.

    /bb

  3. Re: Postfix smtpd DNS lookup delay

    On Wed, 26 Sep 2007, in the Usenet newsgroup alt.os.linux.suse, in article
    , Bob Bob wrote:

    >I maintain 3 sites that run SuSE 9.3


    Is that still supported? It's rather ancient.

    >I understand the normal DNS setup requirements for postfix. MX records
    >exist and the clients (and server & domain) resolve instantly (fwd and
    >rev) at the command line.


    How, exactly? Is this using some application (such as ping), or is
    this using one of the DNS query tools ('dig', 'dnsquery', 'host', or
    'nslookup')? In the later case, look at the /etc/host.conf and
    /etc/nsswitch.conf files (which DNS query tools ignore, but all
    applications check first).

    [compton ~]$ grep host /etc/host.conf /etc/nsswitch.conf
    /etc/host.confrder hosts,bind
    /etc/nsswitch.conf:hosts: files nis dns
    [compton ~]$

    Otherwise, run a packet sniffer, and see what questions your server is
    asking of which DNS. Recall that the resolver believes the first
    "answer" it receives from a DNS server - even if that answer is the
    equivalent of "I don't know". An NXDOMAIN response means there is no
    answer, so the resolver isn't going to be asking someone else.

    >This kind of implies that the lookup is failing BEFORE it even starts
    >the smtpd conversation.


    Logging - "I want to know who is trying to connect to me".

    >It is all kind of puzzling given the instant name resolution on the
    >command line.


    Above

    >Before anyone asks there is no firewalling in the way.


    Is it asking the "right" name server?

    >It is normal BTW to get these unknown errmsgs on the public side of
    >the server, mainly from spammers with no MX records.


    It's not just spammers who don't have proper DNS configurations. The
    world is full of networks run by idiots who don't think it's required
    to have PTR records. There are entire blocklists run to list such
    networks, never mind a place like rfc-ignorant.org.

    Old guy

  4. Re: Postfix smtpd DNS lookup delay

    Hi Moe

    > Is that still supported? It's rather ancient.


    I did see new 9.3 security patches a few months ago but I haven't
    checked recently. They are setup as CLI only boxes BTW. Very small disk
    usage footprint.

    > How, exactly? Is this using some application (such as ping), or is
    > this using one of the DNS query tools ('dig', 'dnsquery', 'host', or
    > 'nslookup')? In the later case, look at the /etc/host.conf and
    > /etc/nsswitch.conf files (which DNS query tools ignore, but all
    > applications check first).


    Yes the "host" command with -t type lookups. I dont use dig enough to
    remember the switch syntax. hosts.conf is set to "hosts bind" and
    nsswitch "files dns". This was a check I did weeks ago. I did remove
    lwres from the default setup. Keep in mind that normal host and IP
    resolution for everything else is working fine. From the usability
    standpoint the only issue is the smtpd delay.

    > Otherwise, run a packet sniffer, and see what questions your server is
    > asking of which DNS. Recall that the resolver believes the first
    > "answer" it receives from a DNS server - even if that answer is the
    > equivalent of "I don't know". An NXDOMAIN response means there is no
    > answer, so the resolver isn't going to be asking someone else.


    Yeah that was kind of the next step, tcpdump and friends. Never tried
    doing that on the lo interface but I assume its okay. (The DNS and
    postfix server are one and the same box) There is only one DNS in the
    resolve list. The sites aren't big enough to support a secondary.

    > Logging - "I want to know who is trying to connect to me".


    Now thats a thought too, having the DNS log queries. Never tried that
    but I'll have a look. Tnxs.

    > Is it asking the "right" name server?


    See comments above about it working for every other application. Is
    smtpd configurable to look at another separate DNS? (eg like squid does)

    There is only one nameserver in resolv.conf, 127.0.0.1. It uses
    root.hints for the outside world and has fwd/rev zones for 192.168.x and
    127.x. It doesn't use forwarders.

    > It's not just spammers who don't have proper DNS configurations. The
    > world is full of networks run by idiots who don't think it's required
    > to have PTR records. There are entire blocklists run to list such
    > networks, never mind a place like rfc-ignorant.org.


    Yep am well aware of that. I was making a "you know" throw away comment
    instead of expending bandwidth on a lengthy discourse.

    Bob

  5. Re: Postfix smtpd DNS lookup delay

    On Thu, 27 Sep 2007, in the Usenet newsgroup alt.os.linux.suse, in article
    , Bob Bob wrote:

    >Hi Moe


    Hi!

    >> Is that still supported? It's rather ancient.

    >
    >I did see new 9.3 security patches a few months ago but I haven't
    >checked recently.


    According to the SUSE Linux Lifetime page, 9.3 support ended last April
    30th (for that matter, support for 10.0 is _scheduled_ to end next
    month).

    >They are setup as CLI only boxes BTW. Very small disk usage footprint.


    If they're visible from the world, I'd be updating.

    >Yes the "host" command with -t type lookups. I dont use dig enough to
    >remember the switch syntax. hosts.conf is set to "hosts bind" and
    >nsswitch "files dns". This was a check I did weeks ago.


    OK - it still traps people, which is why I mentioned it.

    >> Otherwise, run a packet sniffer,


    >Yeah that was kind of the next step, tcpdump and friends. Never tried
    >doing that on the lo interface but I assume its okay. (The DNS and
    >postfix server are one and the same box)


    /usr/sbin/tcpdump -n -i lo

    >There is only one DNS in the resolve list. The sites aren't big enough
    >to support a secondary.


    man 5 resolver - in theory, if the DNS is on the same box, you don't
    need to list it. I'm not sure what you mean about the sites not being
    big enough to support a secondary. Domain registrars are supposed to
    require two as a minimum. Now it's true that if the server is on the
    same box as the DNS, a secondary isn't going to do the server any good.

    > Logging - "I want to know who is trying to connect to me".
    >
    >Now thats a thought too, having the DNS log queries. Never tried that
    >but I'll have a look. Tnxs.


    Never thought of it either - the logging I was referring to is that done
    by the mail server (if your system is using xinetd instead of inetd, it
    may want to do logging based on the service configuration file - look for
    the 'log_on_*' lines).

    Old guy

  6. Re: Postfix smtpd DNS lookup delay

    Hi Moe

    One of course wonders whether this old guy is older than the other old
    guy!

    > /usr/sbin/tcpdump -n -i lo


    Hope to do it tomorrow!

    > man 5 resolver - in theory, if the DNS is on the same box, you don't
    > need to list it. I'm not sure what you mean about the sites not being
    > big enough to support a secondary. Domain registrars are supposed to
    > require two as a minimum. Now it's true that if the server is on the
    > same box as the DNS, a secondary isn't going to do the server any good.


    These sites are a private business that is only authoritive for the
    private subnet (192.168 etc). They cant be connected to on the public
    side at all. The DNS/postfix box is in fact only on a private subnet,
    masquerading out for pop3 and smtp to the ISP as a relayhost. Only have
    maybe 15 users total on each site so DNS fail over redundancy is a
    function of the users phoning the support guy!

    > Never thought of it either - the logging I was referring to is that done
    > by the mail server (if your system is using xinetd instead of inetd, it
    > may want to do logging based on the service configuration file - look for
    > the 'log_on_*' lines).


    Err am not running an mail system under inetd. Its postfix. In fact I
    have never run a MTA over inetd. Use to run UOW IMAP on it but that was
    yonks ago!

    postfix has some real good facilities or logging. My original post was a
    dump of the normal mail syslog after having set the debug_peer_list to a
    test client address in /etc/postfix/main.cf

    Tnxs for your comments, they are appreciated.

    Cheers Bob

  7. Re: Postfix smtpd DNS lookup delay

    On Thu, 27 Sep 2007, in the Usenet newsgroup alt.os.linux.suse, in article
    <785us4-9br.ln1@p400bob.personal.cox.net>, Bob Bob wrote:

    >One of course wonders whether this old guy is older than the other
    >old guy!


    Old is a function of natural age (I'm over 0x41), mileage and rough
    service. See the owners manual for recommended service intervals (not
    that it matters, as you're probably long out of warranty anyway) ;-)

    >These sites are a private business that is only authoritive for the
    >private subnet (192.168 etc). They cant be connected to on the public
    >side at all. The DNS/postfix box is in fact only on a private subnet,
    >masquerading out for pop3 and smtp to the ISP as a relayhost.


    If it's offering no services to the world, it's less of a risk, but
    if it can connect out, there has to be a route "back in" to complete
    the connection. Small risk, but still a risk.

    >> Never thought of it either - the logging I was referring to is that
    >> done by the mail server (if your system is using xinetd instead of
    >> inetd, it may want to do logging based on the service configuration
    >> file - look for the 'log_on_*' lines).

    >
    >Err am not running an mail system under inetd. Its postfix.


    Poorly worded on my part. Many servers want to (or can be configured
    to) log the IP of remote systems that connect to them. An example of
    this would be seen in [x]inetd. Stand-alone stuff - especially mail
    servers - tend to have this logging on their own, as it's needed for
    the 'Received:' header, never mind any logging that the administrator
    may have required, or any hoops (example - connecting box must have
    a PTR record, or must have matching PTR and A records, not be on any
    blocklist, and must be in a country with an 'r' in the ISO3166 name
    except on Tuesdays, when the magic letter is 's') that might be set
    up as an anti-spam measure.

    Old guy

+ Reply to Thread