#2628 dyndns update fails if DNS server is not DC for domain (sssd-1.11.7)
Closed: Duplicate None Opened 8 years ago by longina.

Hi,
I have been encouraged to make a ticket after presenting the problem on sssd-users mailing list:

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 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 whit 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).
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”.


I would say this is a duplicate of #2495

resolution: => duplicate
sensitive: => 0
status: new => closed

Fields changed

rhbz: => 0

Metadata Update from @longina:
- Issue set to the milestone: SSSD Design

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3669

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata