#6579 ipa-server-install not creating ipa-ca DNS record when using different --domain
Closed: Invalid None Opened 7 years ago by candlerb.

Test environment: CentOS 7.3 lxd container (freeipa 4.4.0), hostname "ipatest.foo.example.com", which is resolvable locally in /etc/hosts.

Installing a different domain as the IPA primary domain:

ipa-server-install --domain bar.example.com --realm BAR.EXAMPLE.COM --setup-dns

I get this warning:

ipa         : ERROR    unable to resolve host name ipatest.foo.example.com. to IP address, ipa-ca DNS record will be incomplete

and indeed, the ipa-ca.bar.example.com A record is not in the DNS:

# ipa dnsrecord-find bar.example.com ipa-ca
----------------------------
Number of entries returned 0
----------------------------

However the server hostname was (and still is) resolvable in /etc/hosts:

# getent hosts ipatest.foo.example.com
100.64.2.3      ipatest.foo.example.com ipatest

So I think it would be more friendly if the installer were to use gethostent() or similar, rather than only DNS, to resolve the name here. Then it would be able to create

ipa-ca.bar.example.com A 100.64.2.3

as expected.

Alternatively: during the installer run I had to specify the server's IP address anyway:

Enter the IP address to use, or press Enter to finish.
Please provide the IP address to be used for this host name: 100.64.2.3
Please provide the IP address to be used for this host name:

So it could just use that address for the ipa-ca DNS A record, rather than trying to resolve the host's own name.


Hello,

IPA heavily uses SRV records for better integration with clients, in case that IPA server is not resolvable by DNS you are facing bigger issues than the ipa-ca record is no upgraded. Correctly configured DNS is essential for FreeIPA.

For ipa-ca record we uses DNS as we assume that authoritative data are in DNS, to prevent that various servers may create various ipa-ca records based on /etc/hosts.

I propose WONFIX for this ticket.

You can create A/AAAA records of server in DNS system and then call ipa dns-update-system-records to recreate ipa-ca record.

mbasti, isn't it chicken-egg? Here IPA is installed with DNS, so it will eventually server as the DNS server which will provide the records missing records. And it can create it given that the info was provided at install time.

According the ticket description, ipa server doesn't belong to ipa domain, so IPA is not managing that hostname, so IPA cannot add records to zone that doesn't own.

According the ticket description, ipa server doesn't belong to ipa domain

correct

so IPA is not managing that hostname

IPA server is not managing the domain which contains the system hostname; but it is managing the IPA domain.

so IPA cannot add records to zone that doesn't own.

It cannot add its own hostname. But the ipa-ca hostname is in the IPA domain, and it ought to be able to add that.

The reason it can't add the ipa-ca A record is because it says it can't resolve it's own hostname to find its own IP address. But in fact it has two ways that it could do so:

  1. the installer explicitly prompts for the server's IP address anyway (or you can use the --ip-address flag to ipa-server-install)
  2. via /etc/hosts (gethostent etc)

Replying to [comment:5 candlerb]:

The reason it can't add the ipa-ca A record is because it says it can't resolve it's own hostname to find its own IP address. But in fact it has two ways that it could do so:

  1. the installer explicitly prompts for the server's IP address anyway (or you can use the --ip-address flag to ipa-server-install)
  2. via /etc/hosts (gethostent etc)

IPA is a replicated solution, how would you like to achieve multiple replicas and keep it working with dns-update-system-recods command?

  1. always specify pairs (replica name: ip-address) to dns-update-system-records?
  2. what to do when /etc/hosts is different/outdated on various replicas, then each replica generates different records

To query only DNS was used on purpose to avoid inconsistencies, because in DNS you should have
valid data which are used by clients.

I'm not sure how is your IPA supposed to work if you don't have IPA servers A/AAAA records in your DNS as clients uses SRV records. I don't think that having synchronized /etc/hosts on all clients is the way.

Also in the IdM Guide to have resolvable A/AAAA records is listed as prerequisite: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs

You can add ipa-ca records manually, it will not be overwritten while resolution of IPA hostnames fails.

what to do when /etc/hosts is different/outdated on various replicas

I'd only expect /etc/hosts on each host to have its own hostname/IP.

But I take your point that dns-update-system-records (amongst many other things) will depend on IPA server names being resolvable.

Also in the IdM Guide to have resolvable A/AAAA records is listed as prerequisite:

For bootstrapping purposes, ipa-server-install prompts you for the IP address (or the --ip-address option); and absolutely this works fine when the IPA domain is the domain containing the server hostname.

But ipa-server-install still prompts you for the IP address, even if it's not going to be authoritative for the domain containing the hostname.

How about this for a solution:

  • if the IPA server hostname is not under the IPA domain - or if --setup-dns is not provided - don't prompt for the IP address. Instead try to resolve it in the DNS (early)
  • if the resolution fails, abort the installation

That would be perfectly good solution for me - better than ploughing ahead blindly and then failing to generate the ipa-ca record. And basically it just enforces your prerequisite ("IPA servers must have resolvable A/AAAA records")

Sorry for the delay, most of the team was busy with developer conference in Brno so triage result were not reflected from the time before.

Per triage, aborting installation if resolution fails is not the direction the project is moving, actually some DNS check are loosen so that installation will work in more environments.

Metadata Update from @candlerb:
- Issue assigned to someone
- Issue set to the milestone: 0.0 NEEDS_TRIAGE

7 years ago

Login to comment on this ticket.

Metadata