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.
Bug 1444354 - nsupdate: Queries for TKEY are sent to wrong server when using GSSAPI
Summary: nsupdate: Queries for TKEY are sent to wrong server when using GSSAPI
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bind
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Petr Menšík
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On: 1236087
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-21 08:34 UTC by Martin Bašti
Modified: 2017-04-21 14:02 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1236087
Environment:
Last Closed: 2017-04-21 14:02:05 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Martin Bašti 2017-04-21 08:34:35 UTC 
Please backport this commit to RHEL as it affects SSSD and ipa-client ability to updates DNS records via nsupdate

Thank you.

+++ This bug was initially created as a clone of Bug #1236087 +++

Description of problem:
If using GSSAPI, then queries for TKEY are always sent to the servers specified in the /etc/resolv.conf instead to the master server for the zone. If the server is specified explicitly as 'server' option, Queries are sent to the correct server.

The problem is that the code in GSSAPI specific paths was not modified to cope with changes done in upstream ticket RT#37925.

Version-Release number of selected component (if applicable):
version 9.10.2b1 and later so versions in F22+

How reproducible:
always

--- Additional comment from Tomas Hozza on 2015-06-26 16:52:23 CEST ---

[ISC-Bugs #39893] nsupdate: Queries for TKEY are sent to wrong server when using GSSAPI

--- Additional comment from Mike McCune on 2016-03-29 01:40:50 CEST ---

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

--- Additional comment from Jan Kurik on 2016-07-26 07:08:39 CEST ---

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

--- Additional comment from Martin Bašti on 2016-11-04 14:19:42 CET ---

This bug causes issues with ipa-client-install if authoritative server is not directly in resolv.conf


Is there any guess when this can be fixed upstream?

Thanks

--- Additional comment from Tomas Hozza on 2016-11-04 14:23:56 CET ---

(In reply to Martin Bašti from comment #4)
> This bug causes issues with ipa-client-install if authoritative server is
> not directly in resolv.conf
> 
> 
> Is there any guess when this can be fixed upstream?
> 
> Thanks

I will ping upstream, but no guess from me when this will be merged.

--- Additional comment from Fedora Admin XMLRPC Client on 2016-12-01 15:21:18 CET ---

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

--- Additional comment from Martin Bašti on 2017-03-01 10:15:20 CET ---

Any updates from upstream? People using ipa-client are hitting this

--- Additional comment from Tomas Hozza on 2017-03-01 13:25:47 CET ---

(In reply to Martin Bašti from comment #7)
> Any updates from upstream? People using ipa-client are hitting this

No, upstream didn't respond so far. I pinged upstream again...

--- Additional comment from Tomas Hozza on 2017-04-21 10:25:38 CEST ---

Good news everyone :)

Upstream has merged the change.

4588.	[bug]		nsupdate could send queries for TKEY to the wrong
			server when using GSSAPI. Thanks to Tomas Hozza.
			[RT #39893]


9.12, 9.11.2, 9.10.6, 9.9.10

Upstream commit 66b71679b78ad6cf2c4e5c8c1216b602e0fe1e9b

--- Additional comment from Martin Bašti on 2017-04-21 10:31:50 CEST ---

\o/

Thank you!
Comment 2 Petr Menšík 2017-04-21 13:39:59 UTC 
Relevant commit for RHEL 7 is change 4588 [1]
The patch is really small, however it does not apply to RHEL 7 BIND 9.9.4. And difference does not seem really small. There are not master_servers in current version, changed by 3736 [2] and 4020 [3], modified by since 9.9.6. Is that bug even present in RHEL 7?

Can you provide steps to trigger this bug?

[1] https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=2a4e8c753ebb98ead29f901164793d9b61cd0175
[2] https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=1a58baf293ab7af594b0bd1cd80a005c57770e9c
[3] https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=ba65e27124f530a0fa4493e924c3c66fec7cf101
Comment 4 Petr Menšík 2017-04-21 14:02:05 UTC 
As [2] is in fact referenced RT#37925. Because it is not part of rhel-7 bind, I am closing it as not affected. If that is wrong, please reopen the bug.
Note You need to log in before you can comment on or make changes to this bug.