Bug 1723950 - postfix sends different DNS queries for non FQDN relayhost in comparison to RHEL-7
Summary: postfix sends different DNS queries for non FQDN relayhost in comparison to R...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: postfix
Version: 8.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 8.0
Assignee: Jaroslav Škarvada
QA Contact: Patrik Moško
Katerina Nemcova
URL:
Whiteboard:
Depends On:
Blocks: 1755139
TreeView+ depends on / blocked
 
Reported: 2019-06-25 20:28 UTC by Jaroslav Škarvada
Modified: 2020-04-28 16:47 UTC (History)
6 users (show)

Fixed In Version: postfix-3.3.1-12
Doc Type: Bug Fix
Doc Text:
.The `postfix` DNS resolver code now uses `res_search` instead of `res_query` Following its previous update in `postfix`, the DNS resolver code used the `res_query` function instead of the `res_search` function. As a consequence, the DNS resolver did not search host names in the current and parent domains with the following `postfix` configuration: ---- # postconf -e "smtp_host_lookup = dns" # postconf -e "smtp_dns_resolver_options = res_defnames, res_dnsrch" ---- For example, for: ---- # postconf -e "relayhost = [smtp]" ---- and the domain name in the _example.com_ format, the DNS resolver did not use the smtp._example.com_ SMTP server for relaying. With this update, the DNS resolver code has been changed to use `res_search` instead of `res_query`, and it now searches the host names in the current and parent domains correctly.
Clone Of:
Environment:
Last Closed: 2020-04-28 16:47:16 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)
Upstream fix (553 bytes, patch)
2019-12-16 09:08 UTC, Jaroslav Škarvada
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4647781 None None None 2019-12-16 15:56:13 UTC
Red Hat Product Errata RHBA-2020:1816 None None None 2020-04-28 16:47:20 UTC

Description Jaroslav Škarvada 2019-06-25 20:28:45 UTC
Description of problem:
Postfix sends different DNS queries for non FQDN relayhost in comparison to RHEL-7.

Version-Release number of selected component (if applicable):
postfix-3.3.1-8.el8.x86_64

How reproducible:
Always

Steps to Reproduce:
1. postconf -e relayhost = '[smtp]'
2. postconf -e postconf -e smtp_host_lookup=dns
3. postconf -e smtp_dns_resolver_options = res_defnames, res_dnsrch
4. send mail

Actual results:
Jun 25 09:36:26 host-01 postfix/smtp[7249]: 72F196EAA2: to=<user@example.com>, relay=none, delay=9006, delays=9006/0.04/0.02/0, dsn=4.3.5, status=deferred (Host or domain name not found. Name service error for name=smtp type=AAAA: Host not found)

Expected results:
No error

Additional info:
On RHEL-7 it adds the domainname to the query, on RHEL-8 it doesn't, so just hostnames cannot be used for relayhost without workaround. As a workaround the following can be used:
postconf -e postconf -e smtp_host_lookup=dns

It maybe glibc bug.

Comment 6 Jaroslav Škarvada 2019-12-09 20:57:41 UTC
It seems the resolver code has been rewritten in postfix-3.1.x and it now uses res_query instead of the res_search. From the manual page (the text was shortened):

> The res_search() functions make a query and waits for the response like res_query(), but in addition it implements the default and search rules controlled by RES_DEFNAMES and RES_DNSRCH.
>
> RES_DNSRCH If set, res_search() will search for hostnames in the current domain and in parent domains.
> RES_DEFNAMES If set, res_search() will append the default domain name to single component names—that is, those that do not contain a dot.

So that's why the RES_DEFNAMES and RES_DNSRCH flags are ignored now and domainname is not appended to the query. I asked upstream about purpose of this change.

Comment 7 Jaroslav Škarvada 2019-12-10 00:24:32 UTC
Reply from upstream:

> # postconf -e "relayhost = [smtp]"
> # postconf -e smtp_host_lookup=dns
> # postconf -e "smtp_dns_resolver_options = res_defnames, res_dnsrch"

Those particular settings break the correctness of MX resolution and are not
recommended:

    http://www.postfix.org/postconf.5.html#smtp_dns_resolver_options

Instead, use "dns, native" if you want those features for gateway
literals.

> Is this intended? I wasn't able to find any related incompatibility
> notice in the documentation

I don't think it was specifically intended, the change to use res_query was
made for other reasons, so this change may be inadvertent, but it is perhaps
time after 8+ years to drop the Postfix 2.8 support crutches.

Comment 8 Jaroslav Škarvada 2019-12-10 00:33:06 UTC
According to the comment 7 I don't think it's worth to support the behavior of old postfix in RHEL-8 (we started with the postfix-3.3.x in RHEL-8 which already had this new behavior thus there was no regression) and divert from the upstream.

Comment 11 Jaroslav Škarvada 2019-12-10 10:22:01 UTC
To sum it up:
- the change in behavior is side effect of resolver improvements
- upstream doesn't recommend usage of the configuration from comment 0 (usage of res_defnames and res_dnsrch resolver flags), for details see linked upstream documentation in comment 7
- the requested behaviour can be still enabled with the "smtp_host_lookup = dns, native" configuration
- it's not regression in RHEL-8, because postfix in RHEL-8 always worked this way
- I do not recommend patching the resolver to work differently from the upstream implementation just to mimic RHEL-7 behavior

Comment 14 Jaroslav Škarvada 2019-12-15 20:09:56 UTC
Upstream finally acked it as a bug. The fix is as I wrote earlier - to replace the res_query by the res_search. The fix will be included in some future postfix release.

Comment 15 Jaroslav Škarvada 2019-12-16 09:08:45 UTC
Created attachment 1645520 [details]
Upstream fix

Comment 23 errata-xmlrpc 2020-04-28 16:47:16 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1816


Note You need to log in before you can comment on or make changes to this bug.