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 

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 

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?



Petr^2 Spacek

Freeipa-users mailing list

Reply via email to