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(a)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:
Would improve situation, since most work will be done by nsupdate and
sssd will no longer try to be smart.