On ke, 07 joulu 2016, List dedicated to discussions about use, configuration 
and deployment of the IPA server. wrote:
I know the Quick Start Guide and Deployment Recommendations cover this in
depth, but there are still some ambiguities.

I'm trying to figure out if a company like us, lautus.net should use a DNS
subdomain like ipa.lautus.net for the IPA domain, or not.
It is really depending on your deployment details.

If you already have some other Kerberized environment in place and you
are not going to replace it by FreeIPA, then you need to make sure that
new FreeIPA deployment would not conflict with the existing one.

This is the rule dictated by the way how Kerberos realms are organized
and particularly so for Active Directory deployments as that one has
even more serious limitations towards what can be part of the Active
Directory domain/forest structure.

On the one hand 2.3.1 of the Linux Domain Identity, Authentication, and
Policy Guide says "The integrated DNS server provided by IdM is not
designed to be used as a general-purpose DNS server. It only supports
features related to IdM deployment and maintenance". OK, so lautus.net
should continue to be hosted by DNS servers elsewhere that delegate say,
ipa.lautus.net to FreeIPA.
You definitely can use IPA DNS server for the purpose of hosting your
primary DNS servers if all features provided by IPA DNS server cover
your needs. As I said, it really depends on your specific deployment
considerations. The guide is trying to hint that all things that ISC
BIND supports aren't necessarily will be working in the IPA version --
like a split-horizon feature -- so it is not a general-purpose DNS
server in that sense.

But on the other hand the same doc is full of examples where a Kerberos
realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm
should be the same as the ipa DNS domain, just uppercased. So example 2.2.
implies that example.com is running their DNS domain on FreeIPA, for
everything, not just for IPA SRV and TXT entries.
It assumes for the most of configurations that you are setting up
FreeIPA as the only Kerberos environment, thus talking about
EXAMPLE.COM.

And when ipa-client-install is run on somehost.lautus.net, it also defaults
to LAUTUS.NET for Kerberos domain, as if the default expectation is that
your toplevel company DNS name would be your kerberos domain.
Yes, as with *any* decent Kerberos implementation.

And when I install a trial IPA server on host ipa-server-1.lautus.net using
"ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  in the
Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS
ipa-server-1.lautus.net". In other words the IPA server defaults to
thinking it owns the domain above ipa.lautus.net too. Which goes against
2.3.1 above.
Yes and no. What you see with "@ NS ..." is a glue record -- you are
supposed to have a glue record for IPA domain in the upstream domain,
this is how domain delegation works in DNS world.

The docs say I should manually add SRV records to a parent DNS domain like
lautus.net if IPA does not manage that with integrated DNS. But then what's
the point of the integrated DNS, if the docs say the integrated DNS is not
supposed to be used as a general-purpose DNS server? In that case,
everybody is always gonna need to manually add SRV records every time they
add a IPA replication peer anyway, unless they run their company DNS on the
integrated DNS server, which the docs seem to discourage?
See above.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
  • ... List dedicated to discussions about use, configuration and deployment of the IPA server.
    • ... freeIPA users list
      • ... Pieter Nagel
        • ... Jacob Evans
      • ... Brian Candler
        • ... Petr Spacek
        • ... Pieter Nagel
          • ... Alexander Bokovoy
            • ... Pieter Nagel
              • ... Petr Spacek
                • ... Brian Candler
                • ... Martin Basti

Reply via email to