[Freeipa-users] tough one on DNS

[Petr Spacek]

Hello,

I wonder if your problems with SSL are really caused by problems with reverse 
name resolution ... I think that SSL libraries usually don't care about PTR 
records. Which SSL libraries do you use? Do you use server's IP address in 
certificate subject field?


Regarding the DNS:
First of all, I would recommend to replace conditional forwarder on Windows 
side by normal DNS delegation from Windows to FreeIPA: Create NS+A record on 
Windows side, do not configure any forwarding from Windows to FreeIPA.

Conditional forwarding usually creates more problems than it solves.


Regarding the reverse zone:
As you said, the correct approach is to have only one authoritative source for 
reverse zone - i.e. serve reverse zone only from Windows OR FreeIPA.

Do I understand correctly that you want to allow Windows & non-Windows clients 
to update own records in the same reverse zone?

It could be a tricky ... What are your security requirements?
Do you require Kerberos authentication for each update?
Do you have a FreeIPA-Windows trust in place?

Obviously, the simplest thing is to not require update signing :-)

Now seriously: BIND9 could allow you to specify that authenticated clients 
from REALM1 and REALM2 can do any update to PTR records in particular reverse 
zone, but it could be tricky to configure. (See match type 'wildcard' 
mentioned at 
ftp://ftp.isc.org/isc/bind9/9.9.3-P1/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies.)

If you need more granular control over each update then match type 'external' 
with your own ACL-daemon could be the way to go.

I have no idea how DNS updates from trusted realms are processed on Windows 
side, it is possible that you can configure Windows to trust updates from 
FreeIPA realm (if there is a trust between Windows and FreeIPA).


Please let us know if you need any further assistance.

Petr^2 Spacek


On 9.8.2013 15:29, Armstrong, Kenneth Lawrence wrote:
> Hi all.
>
> We have IdM set up in a test environment as a subdomain of our Windows domain (so, linux.example.com) with integrated DNS on the IdM server and forwarders going to the AD servers on example.com.   We have on the Windows DNS server the IdM server set up as a conditional forwarder for linux.example.com and an A record in its DNS for the IdM server.
>
> However, on example.com, we have other subdomains that need to be able to communicate with the linux.example.com domain, such as tier1.example.com, tier2.example.com, etc.
>
> What we are trying to figure out is the whole PTR reverse zone bit, mainly due to the fact that the linux.example.com and the example.com reside on the same subnets (and unfortunately, this is a very large network and we can't change that).
>
> For instance, say we have a system at test1.tier2.example.com that needs to make an SSL connection to another system on testA.linux.example.com.  The SSL handshake will fail since the PTR record will resolve to a different domain than what the client is expecting, again due to the fact that the reverse zone is on the same subnet.  The reverse zone on the Windows DNS server would only contain PTR records for all of the domains except linux.example.com, and the IdM server would only contain PTR records for just the linux.example.com systems.
>
> So, obviously, we would not want the IdM server to have a reverse zone, and have it rely on the reverse zone on the Windows DNS server.  Other than manually entering PTR records for all Linux systems under linux.example.com to the reverse zone file on the Windows DNS server, is there another way that we can properly accomplish this?  Would replicating the reverse zone file from the Windows server to the IdM server take care of that?
>
> Thanks.
>
> -Kenny


-- 
Petr^2 Spacek