#9257 Introduction of URI records for kerberos breaks location functionality
Closed: fixed a year ago by frenaud. Opened 2 years ago by jrische.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 8): Bug 2104185

Description of problem:
I believe that introduction of URI records for kerberos service discovery breaks location functionality. This is caused by two facts:
- URI records are NOT location aware;
- URI lookups are performed (by default and this is not actively changed by IPA installers) before SRV lookups and take precedence over SRV records (see: https://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html).

Version-Release number of selected component (if applicable):
ipa-client-4.9.8-7.module_el8.6.0+2881+2f24dc92.x86_64
ipa-client-common-4.9.8-7.module_el8.6.0+2881+2f24dc92.noarch
ipa-common-4.9.8-7.module_el8.6.0+2881+2f24dc92.noarch
ipa-healthcheck-0.7-10.module_el8.6.0+2881+2f24dc92.noarch
ipa-healthcheck-core-0.7-10.module_el8.6.0+2881+2f24dc92.noarch
ipa-selinux-4.9.8-7.module_el8.6.0+2881+2f24dc92.noarch
ipa-server-4.9.8-7.module_el8.6.0+2881+2f24dc92.x86_64
ipa-server-common-4.9.8-7.module_el8.6.0+2881+2f24dc92.noarch
ipa-server-dns-4.9.8-7.module_el8.6.0+2881+2f24dc92.noarch
ipa-server-trust-ad-4.9.8-7.module_el8.6.0+2881+2f24dc92.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Perform URI lookup to discover kerberos KDCs:
vesemir:~> dig _kerberos.ipa.jot23.net uri +noall +answer
_kerberos.ipa.jot23.net. 86400  IN      URI     0 100 "krb5srv:m:tcp:xavier.jot23.org."
_kerberos.ipa.jot23.net. 86400  IN      URI     0 100 "krb5srv:m:udp:zoltan.jot23.org."
_kerberos.ipa.jot23.net. 86400  IN      URI     0 100 "krb5srv:m:udp:filippa.jot23.net."
_kerberos.ipa.jot23.net. 86400  IN      URI     0 100 "krb5srv:m:udp:triss.jot23.net."
_kerberos.ipa.jot23.net. 86400  IN      URI     0 100 "krb5srv:m:tcp:triss.jot23.net."
_kerberos.ipa.jot23.net. 86400  IN      URI     0 100 "krb5srv:m:tcp:filippa.jot23.net."
_kerberos.ipa.jot23.net. 86400  IN      URI     0 100 "krb5srv:m:tcp:zoltan.jot23.org."
_kerberos.ipa.jot23.net. 86400  IN      URI     0 100 "krb5srv:m:udp:xavier.jot23.org."
2. Please note equal priority of all records. This is the bug.
3. For comparison perform SRV lookup to dicover kerberos KDCs:
vesemir:~> dig _kerberos._udp.ipa.jot23.net srv +noall +answer
_kerberos._udp.ipa.jot23.net. 86400 IN  CNAME   _kerberos._udp.osowa._locations.ipa.jot23.net.
_kerberos._udp.osowa._locations.ipa.jot23.net. 86400 IN SRV 0 100 88 triss.jot23.net.
_kerberos._udp.osowa._locations.ipa.jot23.net. 86400 IN SRV 50 100 88 xavier.jot23.org.
_kerberos._udp.osowa._locations.ipa.jot23.net. 86400 IN SRV 0 100 88 filippa.jot23.net.
_kerberos._udp.osowa._locations.ipa.jot23.net. 86400 IN SRV 50 100 88 zoltan.jot23.org.
4. Please note differing record priorities. This is how it should looku like for URI records as well.

Actual results:
Location functionality is hindered for URI records.

Expected results:
Location functionality works for URI records.

Additional info:
Please note that SRV records resolve through the CNAME record pointing to appropriate records for location. URI lookup resolves directly. This is (likely) caused by a fact that _kerberos URI records are put alongside _kerberos TXT record and CNAME cannot coexist with other record types. This shouldn't affect _kpasswd URI records but apparently it does.

This can be easily resolved by moving _kerberos TXT records to location aware records and making top level _kerberos also a CNAME there.

Metadata Update from @jrische:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=2104185

2 years ago

Metadata Update from @jrische:
- Issue assigned to jrische

2 years ago

Metadata Update from @jrische:
- Custom field on_review adjusted to https://github.com/freeipa/freeipa/pull/6495

2 years ago

master:

  • 673d2b8 Generate CNAMEs for TXT+URI location krb records

ipa-4-9:

  • a0652f5 Generate CNAMEs for TXT+URI location krb records

ipa-4-10:

  • b0d9099 Generate CNAMEs for TXT+URI location krb records

Metadata Update from @frenaud:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata