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 1417773 - DNS discovery should fall back to SSSD domain name
Summary: DNS discovery should fall back to SSSD domain name
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.9
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Steeve Goveas
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-30 23:07 UTC by Amith
Modified: 2017-10-23 12:00 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-23 11:58:36 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
SSSD Domain log file. (86.21 KB, text/plain)
2017-02-01 15:26 UTC, Amith 		no flags Details
Show Obsolete (1) View All

Description Amith 2017-01-30 23:07:01 UTC 
This issue was found while trouble-shooting one of the regression failures.
If dns_discovery_domain is not specified and the lookup against the domain portion of the machine's hostname fails then an SRV record query should be performed using the SSSD domain name as the DNS discovery domain.

However in this case dns discovery does not fall back to SSSD domain name, instead SSSD tries to resolve SRV record of machine's hostname (a fake name assigned for testing purpose). This case is a PASS on older RHEL-6.8 version.
 
Domain log shows following:
[sssd[be[lab.eng.pnq.redhat.com]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.kautest.com'
[sssd[be[lab.eng.pnq.redhat.com]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_KERBEROS._udp.kautest.com'
[sssd[be[lab.eng.pnq.redhat.com]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_KERBEROS._tcp.kautest.com'

[sssd[be[lab.eng.pnq.redhat.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'LDAP' as 'not resolved'
[sssd[be[lab.eng.pnq.redhat.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'KERBEROS' as 'not resolved'
[sssd[be[lab.eng.pnq.redhat.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'KERBEROS' as 'neutral'
[sssd[be[lab.eng.pnq.redhat.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'KERBEROS' as 'neutral'
[sssd[be[lab.eng.pnq.redhat.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'LDAP' as 'neutral'
[sssd[be[lab.eng.pnq.redhat.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'LDAP' as 'not resolved'

Version-Release number of selected component (if applicable):
sssd-1.13.3-54.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Setup named.conf on the client machine so it can also act as DNS server. Also, update /etc/resolv.conf with "nameserver 127.0.0.1"

2. Assign a fake hostname to the SSSD client machine, say 
# hostname host1.kautest.com

3. Configure sssd.conf as following:

[sssd]
config_file_version = 2
services = nss, pam
domains = lab.eng.pnq.redhat.com

[nss]

[pam]

[domain/lab.eng.pnq.redhat.com]
debug_level = 0xFFF0
id_provider = ldap
ldap_uri = _srv_
ldap_search_base = dc=example,dc=com
dns_discovery_domain =
auth_provider = krb5
krb5_realm = EXAMPLE.COM
krb5_server = _srv_

4. Restart sssd service and try to run a ldap user authentication.

Actual results:
User authentication fails, as SSSD tries to lookup the fake hostname. In fact, when "dns_discovery_domain" is set to nothing, and hostname is unresolvable then SRV record query should be performed using SSSD domain name (in this case lab.eng.pnq.redhat.com).
Comment 1 Amith 2017-01-30 23:10:13 UTC 
Additional info:
1. Please also refer https://fedorahosted.org/sssd/ticket/754

2. Refer : https://git.fedorahosted.org/cgit/sssd.git/commit/?id=9917b96e31df3fa992d235a050ed1dc0e9939b3d
Comment 2 Jakub Hrozek 2017-01-31 08:44:00 UTC 
Since this is in the DNS discovery area, I would like to ask Pavel to take a look.
Comment 5 Pavel Březina 2017-02-01 10:27:07 UTC 
I will ask you for full domain logs, set 0x3ff0 as debug level. Thanks.

I checked the code and we use "hostname domain" and "sssd domain" in this case, this may be dns timeout issue again.
Comment 7 Amith 2017-02-01 15:26:48 UTC 
Created attachment 1246691 [details]
SSSD Domain log file.
Comment 18 Lukas Slebodnik 2017-02-07 11:04:00 UTC 
Please remove a regression keyword from this BZ. It is not a regression in sssd.
Note You need to log in before you can comment on or make changes to this bug.