Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
.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.
DescriptionJaroslav Š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>, 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 6Jaroslav Š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 7Jaroslav Š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 8Jaroslav Š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 11Jaroslav Š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 14Jaroslav Š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 15Jaroslav Škarvada
2019-12-16 09:08:45 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
Comment 25Red Hat Bugzilla
2023-09-18 00:16:36 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days