Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Reverse DNS unknown

138 views
Skip to first unread message

Dave Jones

unread,
Sep 16, 2013, 6:41:24 PM9/16/13
to
The past few weeks or so my Postfix relays have been showing "unknown"
in the logs and headers for some (not all) hosts causing a hit on the
SpamAssassin RDNS_NONE rule. These servers have a local caching DNS
server on them that forward to another pair of caching DNS servers
that run BIND and rbldnsd. I am able to resolve IPs to hostnames from
the command line with dig. This Postfix configuration has been
working fine for 2 1/2 years when I converted from sendmail.

RHEL 6.3 - postfix-2.10.2-1.el6.x86_64

# cat /etc/resolv.conf
nameserver 127.0.0.1
nameserver 96.4.1.26
nameserver 96.4.1.37

# cat /etc/named.conf
options {
directory "/var/named";
forwarders { 96.4.1.26; 96.4.1.37; };
forward only;
};

# dig -x 96.4.3.90 +short
mail02.corp.ena.net.

# dig @localhost -x 96.4.3.90 +short
mail02.corp.ena.net.

# dig @96.4.1.26 -x 96.4.3.90 +short
mail02.corp.ena.net.

Relevant "postconf -n" output:
inet_interfaces = all
inet_protocols = ipv4
smtp_host_lookup = dns, native

I just added "native" above a few days ago to see if that would help
any but no difference. I was running with the default of just "dns"
for the past couple of years.

Received: from mail02.corp.ena.net (unknown [96.4.3.90])
by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
for <reda...@domain.com>; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)

My forward DNS lookup for this host is an internal IP address that
doesn't not match the public but it has been this way for years. I
didn't think the "unknown" above is dependent on FCRDNS.

Thanks in advance,

Dave

Wietse Venema

unread,
Sep 16, 2013, 7:15:32 PM9/16/13
to
Dave Jones:
> The past few weeks or so my Postfix relays have been showing "unknown"
> in the logs and headers for some (not all) hosts causing a hit on the
> SpamAssassin RDNS_NONE rule. These servers have a local caching DNS
> server on them that forward to another pair of caching DNS servers
> that run BIND and rbldnsd. I am able to resolve IPs to hostnames from
> the command line with dig. This Postfix configuration has been
> working fine for 2 1/2 years when I converted from sendmail.

Try turning off chroot operation in master.cf:
http://www.postfix.org/DEBUG_README.html#no_chroot

If that fixes the problem, you had chroot turned on, but with missing
or outdated files under /var/spool/postfix.

> # dig -x 96.4.3.90 +short
> mail02.corp.ena.net.

Postfix does not query DNS as root, so this test is invalid.

Wietse

Noel Jones

unread,
Sep 16, 2013, 8:00:48 PM9/16/13
to
On 9/16/2013 5:41 PM, Dave Jones wrote:
>
> Received: from mail02.corp.ena.net (unknown [96.4.3.90])
> by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
> for <reda...@domain.com>; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)
>
> My forward DNS lookup for this host is an internal IP address that
> doesn't not match the public but it has been this way for years.

You need to do your tests as the postfix user, possibly also
chrooted. Turn off the chroot flag in master.cf for testing.


> I
> didn't think the "unknown" above is dependent on FCRDNS.

but it is. For the conditions postfix will label a host as unknown,
please see
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname

In the Received: header, the first name is the HELO name given, the
second is either the FCRDNS or "unknown". Postfix will also log a
warning explaining why the host is unknown.

I don't know if the "unknown" by itself will trigger the
SpamAssassin RDNS_NONE rule, but that seems a little strict to me.


-- Noel Jones

Dave Jones

unread,
Sep 18, 2013, 9:20:05 AM9/18/13
to
>On 9/16/2013 5:41 PM, Dave Jones wrote:
>>
>> Received: from mail02.corp.ena.net (unknown [96.4.3.90])
>> by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
>> for <reda...@domain.com>; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)
>>
>> My forward DNS lookup for this host is an internal IP address that
>> doesn't not match the public but it has been this way for years.

> You need to do your tests as the postfix user, possibly also
> chrooted. Turn off the chroot flag in master.cf for testing.

I don't have anything chrooted (all n's in that column of the master.cf).
The dig as the postfix user returns the same result.

>> I
>> didn't think the "unknown" above is dependent on FCRDNS.

> but it is. For the conditions postfix will label a host as unknown,
> please see
> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname

I am using reject_unknown_reverse_client_hostname in
smtpd_recipient_restrictions but the server in question is covered by
permit_mynetworks which is before it.

> In the Received: header, the first name is the HELO name given, the
> second is either the FCRDNS or "unknown". Postfix will also log a
> warning explaining why the host is unknown.

I see this in the maillog now that you mention it. It seems more
informational than the cause of the "unknown" since I am using the
"weaker" restriction above.

warning: hostname mail02.corp.ena.net does not resolve to address 96.4.3.90

Based on the reasons at
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname,
it shouldn't be "unknown" with the postfix user being able to resolve
the PTR.

> I don't know if the "unknown" by itself will trigger the
> SpamAssassin RDNS_NONE rule, but that seems a little strict to me.

Wietse Venema

unread,
Sep 18, 2013, 9:35:31 AM9/18/13
to
Dave Jones:
> >On 9/16/2013 5:41 PM, Dave Jones wrote:
> >>
> >> Received: from mail02.corp.ena.net (unknown [96.4.3.90])
> >> by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
> >> for <reda...@domain.com>; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)
> >>
> >> My forward DNS lookup for this host is an internal IP address that
> >> doesn't not match the public but it has been this way for years.
>
> > You need to do your tests as the postfix user, possibly also
> > chrooted. Turn off the chroot flag in master.cf for testing.
>
> I don't have anything chrooted (all n's in that column of the master.cf).
> The dig as the postfix user returns the same result.

First, I can't fail to notice that the PTR record for 96.4.3.90
says "mail02.corp.ena.net.", but the A record for "mail02.corp.ena.net."
resolves to 172.27.0.25. Therefore, it is no surprise that Postfix
uses the name "unknown" instead of "mail02.corp.ena.net".

Second, Postfix does not query DNS to determine the SMTP client
hostname. Instead, Postfix uses the system library getnameinfo()
and getaddrinfo() routines. Attached are small programs that
you can run to see what result Postfix would get.

Again, if the address->name result is not consistent with the
name->address result, Postfix will use "unknown" instead.

Wietse
getaddrinfo.c
getnameinfo.c

Dave Jones

unread,
Sep 18, 2013, 10:10:50 AM9/18/13
to
> Dave Jones:
> > >On 9/16/2013 5:41 PM, Dave Jones wrote:
> > >>
> > >> Received: from mail02.corp.ena.net (unknown [96.4.3.90])
> > >>      by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
> > >>      for <reda...@domain.com>; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)
> > >> 
> > >> My forward DNS lookup for this host is an internal IP address that
> > >> doesn't not match the public but it has been this way for years.
> >
> > > You need to do your tests as the postfix user, possibly also
> > > chrooted.  Turn off the chroot flag in master.cf for testing.
> >
> > I don't have anything chrooted (all n's in that column of the master.cf).
> > The dig as the postfix user returns the same result.

> First, I can't fail to notice that the PTR record for 96.4.3.90
> says "mail02.corp.ena.net.", but the A record for "mail02.corp.ena.net."
> resolves to 172.27.0.25. Therefore, it is no surprise that Postfix
> uses the name "unknown" instead of "mail02.corp.ena.net".

I fixed the A record to match the PTR (external NAT) and now it's showing up properly:
Received: from mail02.corp.ena.net (mail02.corp.ena.net [96.4.3.90])
by mr10.mail.ena.net (Postfix) with ESMTP id 5FA9114806F4

So there is no way to get Postfix to just show the PTR value in the headers without validating anything?  It seems like MTAs should show the PTR value to the left of the square brackets even when it doesn't match the HELO to the left of the parenthesis.  If FCRDNS doesn't pass, I would think that could be an additional string in the headers or something.  In this case, the message has already been accepted so the reject_unknown_client_hostname and reject_unknown_reverse_client_hostname logic for determining the "unknown" value shouldn't apply and the PTR value should been shown.  In this case, the PTR was correct in DNS but showed as "unknown" like it didn't exist in DNS.


> Second, Postfix does not query DNS to determine the SMTP client
> hostname. Instead, Postfix uses the system library getnameinfo()
> and getaddrinfo() routines. Attached are small programs that
> you can run to see what result Postfix would get.

> Again, if the address->name result is not consistent with the
> name->address result, Postfix will use "unknown" instead.

Wietse Venema

unread,
Sep 18, 2013, 10:21:23 AM9/18/13
to
Dave Jones:
> Received: from mail02.corp.ena.net (unknown [96.4.3.90])
> by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
> for <reda...@domain.com>; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)

Wietse:
> First, I can't fail to notice that the PTR record for 96.4.3.90
> says "mail02.corp.ena.net.", but the A record for "mail02.corp.ena.net."
> resolves to 172.27.0.25. Therefore, it is no surprise that Postfix
> uses the name "unknown" instead of "mail02.corp.ena.net".

Dave Jones:
> I fixed the A record to match the PTR (external NAT) and now it's showing
> up properly:
> Received: from mail02.corp.ena.net (mail02.corp.ena.net [96.4.3.90])
> by mr10.mail.ena.net (Postfix) with ESMTP id 5FA9114806F4
>
> So there is no way to get Postfix to just show the PTR value in the headers
> without validating anything?

Over my dead body. This name is used for logging and may be used
for access decisions. This is what audit trails and policies rely
on.

Instead, you can put your mail02.corp.ena.net name and address in
/etc/hosts and then the Postfix SMTP daemon will use that (assuming
that your nsswitch.conf host lookups lists files before dns).

Wietse

0 new messages