1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

tcp-env Still Doing Reverse DNS Lookups with -Rt0

Discussion in 'Plesk for Linux - 8.x and Older' started by stupidnic, Sep 4, 2007.

  1. stupidnic

    stupidnic Guest

    0
     
    I have been having a problem with a particular client all day. It seems their ISP's name servers have stopped handing out responses for the IP address. So I went ahead and added the -Rt0 to the inetd.conf (this is a Debian server) and restarted inetd.conf.

    This didn't fix the problem so I thought I had some sort of problem with the mail server itself. I went round and round and I have finally determined that even though tcp-env is passed the -Rt0 switch (I have also tried just -R) it still does the reverse DNS lookup.

    Here is a stack trace of inetd spawning off tcp-env and its subsequent calls to the resolv.conf and DNS calls out to the DNS server.

    Code:
    [pid  2334] execve("/var/qmail/bin/tcp-env", ["tcp-env", "-Rt0", "/var/qmail/bin/relaylock", "/var/qmail/bin/qmail-smtpd", "/var/qmail/bin/smtp_auth", "/var/qmail/bin/true", "/var/qmail/bin/cmd5checkpw", "/var/qmail/bin/true"], [/* 16 vars */]) = 0
    
    As you can see -Rt0 is being passed as an option to tcp-env.

    Later in the same process we can see tcp-env parsing the resolv.conf:

    Code:
    [pid  2334] open("/etc/resolv.conf", O_RDONLY) = 3
    [pid  2334] fstat64(3, {st_mode=S_IFREG|0644, st_size=69, ...}) = 0
    [pid  2334] mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d2a000
    [pid  2334] read(3, "search domain.net\nnameserve"..., 131072) = 69
    [pid  2334] read(3, "", 131072)         = 0
    [pid  2334] close(3)                    = 0
    
    and then making the call out to the remote DNS server:

    Code:
    [pid  2334] socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
    [pid  2334] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.2.3.4")}, 28) = 0
    [pid  2334] send(3, "\202\253\1\0\0\1\0\0\0\0\0\0\00237\00281\003210\003207"..., 44, 0) = 44
    [pid  2334] gettimeofday({1188954458, 39940}, NULL) = 0
    [pid  2334] poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
    [pid  2334] recvfrom(3, "\202\253\201\200\0\1\0\1\0\0\0\0\00237\00281\003210\003"..., 513, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.2.3.4")}, [16]) = 82
    [pid  2334] close(3)
    
    This has been driving me crazy. I have even gone so far as to start picking through the tcp-env.c file in the qmail+plesk source code, but it looks correct (even if my C skills are a tad rusty).

    I see the same thing on a CentOS 5 based Plesk install of 8.2... I am at a loss why it is doing this when it is specifically told not to.
     
  2. stupidnic

    stupidnic Guest

    0
     
    I always hate replying to my own threads... but here I am doing it anyways...

    Basically I misunderstood the purpose of the -R command line switches. Their purpose is not to skip reverse DNS lookups, but are instead supposed to skip Ident lookups (which is should do anyways).

    So basically, if you are having trouble sending email to a qmail based server, then most likely there is something wrong with the servers responsible for handing out reverse DNS for the connecting IP address.

    Our particular problem is causing a sort of deadlock in the qmail-smtpd process. The qmail-smtpd process eventually spawns the ESMTP response to the remote client, but far too late for the client and they just sit there waiting for each other.
     
  3. ramirors

    ramirors Guest

    0
     
    problem sending mail

    I have problems with sending in outlook, i check ports, check isp, all....and still havin problems...in log a saw a lot of "xinetd[xxxx] warning: can't get client address: Connection " starting the same day of the fail...

    i did telnet and OK...

    Any clue?? (CentOS, plesk 8.2.1)...

    Thanks
     
  4. hardbrasil

    hardbrasil Regular Pleskian

    30
    30%
    Joined:
    Jun 22, 2007
    Messages:
    331
    Likes Received:
    10
    i have the same problem. Some Portals block all emails from my qmail server.
    At now whem i send an email this Portals (to test) they not come back anymore.

    i dont konow what to do!
     
  5. Hi,

    I seem to be having the same problem, but when testing with command line networking tools, reverse DNS seems to be functioning properly (unless I'm misunderstanding what reverse DNS is or how to do it, which is very possible).

    For example:

    ~# host 82.98.131.91
    Name: hl75.dinaserver.com
    Address: 82.98.131.91

    ----
    ~# nslookup 82.98.131.91
    Server: 204.11.247.196
    Address: 204.11.247.196#53

    Non-authoritative answer:
    91.131.98.82.in-addr.arpa name = hl75.dinaserver.com.

    Authoritative answers can be found from:
    131.98.82.in-addr.arpa nameserver = ns7.dinahosting.com.
    131.98.82.in-addr.arpa nameserver = ns8.dinahosting.com.
    ns7.dinahosting.com internet address = 82.98.128.130
    ns8.dinahosting.com internet address = 82.98.128.194

    ----
    ~# dig -x 82.98.131.91

    ; <<>> DiG 9.4.3-P3 <<>> -x 82.98.131.91
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30150
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;91.131.98.82.in-addr.arpa. IN PTR

    ;; ANSWER SECTION:
    91.131.98.82.in-addr.arpa. 139 IN PTR hl75.dinaserver.com.

    ;; Query time: 72 msec
    ;; SERVER: 80.58.0.33#53(80.58.0.33)
    ;; WHEN: Fri Jan 22 12:55:17 2010
    ;; MSG SIZE rcvd: 76

    And yet I am unable to receive email from a domain hosted on this server. The connection times out after exactly 30 seconds and I'm not seeing much in my server logs, except the line:

    Jan 22 05:55:43 myservername relaylock: /var/qmail/bin/relaylock: mail from 82.98.131.91:46454 (hl75.dinaserver.com)


    Any ideas?

    Ted Stresen-Reuter
     
Loading...