On Tue, Feb 24, 2015 at 10:55:13AM -0500, Dmitri Pal wrote:
> 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
> >(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
> >Our Active directory is a forrest named local.example.com
> >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
> >Active Directory computer objects (accounts) are located in sub-domains
> >ex. nfsserverA.a.local.example.com
> >Just for your information: Active Directory user objects (accounts) are
> >located in all Active Directory domains – including top domain
> >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
> >from our internal network).
> >PS: I have seen the comments in
> >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.
I would hope that the ticket Petr Spacek proposed earlier, for instance
Would improve situation, since most work will be done by nsupdate and
sssd will no longer try to be smart.
btw if you end up creating the ticket, can you cc: pspacek(a)redhat.com ?
He's our DNS expert and would likely have an idea on how to improve SSSD