Bug 1594142

Summary:	SRV lookup doesn't correctly sort results
Product:	Red Hat Enterprise Linux 7	Reporter:	Petr Vobornik <pvoborni>
Component:	ipa	Assignee:	IPA Maintainers <ipa-maint>
Status:	CLOSED ERRATA	QA Contact:	ipa-qe <ipa-qe>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	7.4	CC:	batkisso, frenaud, ndehadra, pasik, pvoborni, rcritten, sumenon, tscherf
Target Milestone:	rc	Keywords:	ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ipa-4.6.4-2.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1623673 (view as bug list)		Environment:
Last Closed:	2018-10-30 10:58:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1623673

Description Petr Vobornik 2018-06-22 08:58:30 UTC

Cloned from upstream: https://pagure.io/freeipa/issue/7475

On multiple occasions, IPA code doesn't correctly sort SRV records.

## ipadns_search_srv

The entries are sorted by priority. However that is not sufficient. RFC requires that a client randomly distributes load between servers with same priority. This can be easily archived by using ``(answer.priority, random.random())`` as sort key. In theory we also have to obey the weight, but in practice IPA doesn't use weight.

The code should also remove duplicated names from the result.

## get_url_list

https://pagure.io/freeipa/blob/master/f/ipalib/rpc.py#_889

The SRV records are not sorted at all. The ``set()`` operation even discards the sort order from the resolver.

## other

There are more places that need additional attention.

IPA's SRV code has made some questionable decisions, too. For example it assumes that ``_ldap._tcp`` maps to port 389.

Comment 2 Petr Vobornik 2018-06-22 08:58:42 UTC

Upstream ticket:
https://pagure.io/freeipa/issue/7475

Comment 3 Petr Vobornik 2018-06-22 09:00:01 UTC

master:
    f90e137 Sort and shuffle SRV record by priority and weight
ipa-4-6:
    5a83e31 Sort and shuffle SRV record by priority and weight
ipa-4-5:
    76fb775 Sort and shuffle SRV record by priority and weight

Comment 12 Sudhir Menon 2018-08-29 13:26:55 UTC

Fix is seen. Verified on Red Hat Enterprise Linux Server release 7.6 Beta (Maipo)
using

ipa-server-4.6.4-6.el7.x86_64
sssd-1.16.2-12.el7.x86_64
package samba is not installed
pki-server-10.5.9-6.el7.noarch
selinux-policy-3.13.1-220.el7.noarch
389-ds-base-1.3.8.4-11.el7.x86_64

=== Tested the below scenarios ===

Environment:
1 IPA-Master setup with integrated DNS
2 IPA-Replicas with integrated DNS
2 IPA-Clients with resolv.conf having the entries as below.

search <domain-name>
nameserver <master-ip>
nameserver <replica-ip>
nameserver <replica1-ip>

===Scenarios Tested===

Scenario1: Replica1 machine is having higher priority 

[root@master ~]# ipa dnsrecord-find
SRV record: 2 100 389 master.apollo.test
SRV record: 2 50 389 replica.apollo.test
SRV record: 1 100 389 replica1.apollo.test

Actual Results: Client enrollment happens with replica1, due to higher priority and weight


Scenario2: Master and replicas are having same priority and same weight

[root@master ~]# ipa dnsrecord-find
SRV record: 1 100 389 master.apollo.test
SRV record: 1 100 389 replica.apollo.test
SRV record: 1 100 389 replica1.apollo.test

Actual Result: Master and replicas are having same priority and same weight
the clients can get enrolled to any of master/replica/replica1 with same probability 

[root@client ~]# ipa-client-install 
DNS Domain: apollo.test
IPA Server: replica.apollo.test

[root@client2 ~]# ipa-client-install 
DNS Domain: apollo.test
IPA Server: replica1.apollo.test

Scneario3: Enroll second ipa-client for the below priority and weight
[root@master ~]# ipa dnsrecord-find
  SRV record: 1 100 389 master.apollo.test
  SRV record: 1 50 389 replica.apollo.test
  SRV record: 2 100 389 replica.apollo.test

Actual Result: Second client also gets enrolled to master
the clients can get enrolled with either master or replica, but chances are 2x that master gets picked.

Scenario4: Priority is same and weight is different
[root@master ~]# ipa dnsrecord-find
  SRV record: 1 100 389 master.apollo.test
  SRV record: 1 50 389 replica.apollo.test
  SRV record: 1 200 389 replica1.apollo.test

Actual Result: Client gets enrolled to replica1 due to its weight and since priority is same.

Comment 14 Florence Blanc-Renaud 2018-10-18 09:50:46 UTC

*** Bug 1518792 has been marked as a duplicate of this bug. ***

Comment 16 errata-xmlrpc 2018-10-30 10:58:44 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-2018:3187