[SSSD-users] DDNS update problem with SSSD (1.11.7)

Jakub Hrozek jhrozek at redhat.com
Tue Feb 24 17:02:39 UTC 2015


On Tue, Feb 24, 2015 at 10:55:13AM -0500, Dmitri Pal wrote:
> On 02/24/2015 10:10 AM, Longina Przybyszewska wrote:
> >
> >Hi,
> >
> >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
> >10.0.0.0/8 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”.
> >
> >Best,
> >
> >Longina
> >
> >
> >
> >_______________________________________________
> >sssd-users mailing list
> >sssd-users at lists.fedorahosted.org
> >https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> 
> Sounds like and RFE. Please file a ticket.

I would hope that the ticket Petr Spacek proposed earlier, for instance
this one:
    https://fedorahosted.org/sssd/ticket/2540

Would improve situation, since most work will be done by nsupdate and
sssd will no longer try to be smart.


More information about the sssd-users mailing list