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
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Sounds like and RFE. Please file a ticket.
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@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.
On Tue, Feb 24, 2015 at 06:02:39PM +0100, Jakub Hrozek wrote:
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@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.
btw if you end up creating the ticket, can you cc: pspacek@redhat.com ? He's our DNS expert and would likely have an idea on how to improve SSSD DNS updates.
Thank you!
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Longina Przybyszewska