[Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Petr Spacek]

On 7.12.2016 14:57, Brian Candler wrote:
> On 07/12/2016 08:58, freeIPA users list wrote:
>> 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.
> Or if you think there's a chance you might want to add another Kerberized
> environment later (e.g. "ad.lautus.net")
> 
>>
>>> should continue to be hosted by DNS servers elsewhere that delegate say,
>>> ipa.lautus.net to FreeIPA.
> The question of whether you host ipa.lautus.net DNS (or indeed lautus.net DNS)
> in FreeIPA is a different issue.
> 
> If you're happy with your existing DNS infrastructure, then you can either
> delegate ipa.lautus.net to your FreeIPA servers (with NS records); or run
> FreeIPA without DNS, and simply import the ipa.lautus.net SRV records directly
> into the lautus.net domain.
> 
> Having FreeIPA host the ipa.lautus.net domain means these SRV records are
> populated automatically, but it's not really that hard to add them to an
> existing DNS service.
> 
> OTOH, if you *don't* already have a good authoritative internal DNS service
> with a UI that you like, then you might want to use FreeIPA for this anyway.
> You can easily create extra zones in FreeIPA.
> 
> I would be a bit wary about putting FreeIPA servers out on the public Internet
> though. For one thing, the default config is an open resolver (which you can
> tighten easily enough). I also have a deep distrust of Java, but maybe that's
> just me.

Speaking of DNS, it is just BIND. Configure it accordingly and you should be find.

Please note that FreeIPA DNS is not intended as general-purpose DNS:
http://www.freeipa.org/page/DNS#Initial_Considerations

It is tailored for FreeIPA use-cases and might lack special features.


>>> 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.
> The Kerberos realm always has a corresponding DNS domain, so realm
> IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net".
> 
> But with FreeIPA you can still manage hosts called foo.lautus.net or
> bar.int.lautus.net. At worst you'd have some extra [domain_realm] mappings in
> krb5.conf

Yes. Ideally you will be able to add _kerberos TXT records to relevant DNS
domains so explicit mapping will not be necessary.

I will have a look how we can clarify the guide to make this less confusing...

> 
> (Aside: Active Directory is much more fussy, and basically doesn't work if the
> hosts don't have hostnames within the same DNS domain as their kerberos realm
> - and indeed have reverse DNS as well as forward)
> 
>>
>>> 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.
> But you can override that.
> 
>>
>>
>>> 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.
> Interesting. What does "ipa dnszone-find --pkey-only" show?
> 
> It seems like it's created an authoritative zone both for the server's own
> domain (lautus.net if the server is xxx.lautus.net) as well as the realm's
> domain (ipa.lautus.net)
> 
> I don't know why it's doing that. Now I've checked with another system here:
> the hostname is "ipa-1.int.example.com" and the realm is "ipa.example.com",
> and you're right, it is authoritative for both:
> 
>   Zone name: int.example.com.
>   Zone name: ipa.example.com.
> 
> This isn't what I wanted. The int.example.com domain is hosted externally and
> I didn't want to override it. Right now it's hiding all names in
> int.example.com that it doesn't know about.
> 
> I would expect that it's possible to remove this zone, but I'd need to test
> that doesn't stop other hosts called xxx.int.example.com from joining.

Removing the zone should work just fine in IPA 4.4 and newer. In older
versions you can delete the zone but it might get re-created when one of
installers is re-run. (Then feel free to delete it again :-)

IPA 4.4 will detect that the zone already exists somewhere else and do not
create it.


>> 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.
> Aside: technically that's not a glue record. A glue record is an A or AAAA
> record when the NS record points to a host within the subdomain which is being
> delegated. It is to solve the chicken-and-egg situation of how to contact a
> nameserver for a domain before you've contacted a nameserver for the domain.
> 
> In your case, if you already have working DNS for lautus.net, then you don't
> want FreeIPA to be authoritative for lautus.net as well.

Right. Decide who should be authoritative and amend configuration accordingly.

-- 
Petr^2 Spacek