On 02/24/2015 10:10 AM, Longina Przybyszewska wrote:



We have a problem with the way SSSD tries to find out where to send DDNS updates. The problem is that SSSD doesn’t use DNS to find the authoritative name server for a given zone, but assume that it must be the Active Directory Domain Controller to which it is connected.


In our case this is not correct in any way.


Our DNS setup is like this:


DNS-PTR.example.com is Authoritative for all our DNS PTR/reverse records (xxx.in-addr.arpa) and for the forward zone example.com with the exception of local.example.com (and subdomains), which is delegated to localserver1.local.example.com.

(This is purely internal – external we have another DNS service let’s call it DNS-external.example.com, but it doesn’t matter in this example/problem).


Our Active directory is a forrest named local.example.com with subdomains a.local.example.com, b.local.example.com, etc. each Active directory subdomain has it’s own domain controllers let’s say localserverA.a.local.example.com, localserverB.b.local.example.com, etc.


Active Directory computer objects (accounts) are located in sub-domains ex. nfsserverA.a.local.example.com, nfsclientB.b.local.example.com, etc.

Just for your information: Active Directory user objects (accounts) are located in all Active Directory domains – including top domain local.example.com.


The problem:


When nfsserverA.a.local.example.com is trying to update it’s DNS record it’s sending the update to the Active Directory Domain Controller localserverA.a.local.example.com, which is only running Active Directory Services (Domain Controller, Global Catalog, etc.) and not a DNS service, because it assumes that the Active Directory Domain Controller also is running DNS service.


If SSSD had done a DNS lookup for the DNS Name Server record for a.local.example.com it’s told that the DNS Name Server is localserver1.local.example.com. And if it’s looking for the responsible DNS name server for the reverse zone  x.y.10.in-addr.arpa. (we are running divided into /24 subnets as our internal IP subnets) it’s told to that the responsible server is DNS-PTR.example.com (only accessible from our internal network).


PS: I have seen the comments in https://lists.fedorahosted.org/pipermail/sssd-users/2014-June/001878.html talking about creating an option in sssd.conf called something like fallback_dns_master, but I find that very inflexible and not the right way to go … because, if we move the DNS service form one server to another we’ll have to change a lot of local client configuration. Another argument is that we actually have multiple servers authoritative for local.example.com and I suppose that it’s only possible to configure one server in the suggested attribute “fallback_dns_master”.






sssd-users mailing list

Sounds like and RFE. Please file a ticket.

Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.