On Wed, 2014-06-25 at 11:54 +0000, Longina Przybyszewska wrote:
> How SSSD resolves domainname for machine for supplying to
sssd doesn't do anything. nsupdate sends the dns update calls to whatever you have
put in /etc/resolv.conf
This is not true in my case:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
.(Wed Jun 25 12:09:18 2014) [sssd[be[nat.c.sdu.dk]]] [be_nsupdate_create_ptr_msg]
(0x0400): -- Begin nsupdate message --
update delete 254.4.144.10.in-addr.arpa. in PTR
update add 254.4.144.10.in-addr.arpa. 3600 in PTR eta.nat.c.sdu.dk.
(Wed Jun 25 12:09:18 2014) [sssd[be[nat.c.sdu.dk]]] [be_nsupdate_create_ptr_msg]
(0x0400): -- End nsupdate message --
nat-vdc0b.nat.c.sdu.dk has address 10.144.5.18
Host nat-vdc0b.xxx.xxx.xxx is LDAP/AD _not_ DNSserver.
Mmm. Not nice. So, sssd sends the nsupdate data to the ldap server and
ignores what you have in /etc/resolv.conf
Surely, that's a bug.
ad_server = 10.220.2.5
I'm sorry I misled you. Our AD is samba4. We have no choice of DNS or
AD, kerberos or ldap. Our krb5, ldap SRVs all point at the box which
_has_ to also serve dns for that domain. Samba4 _has_ to have the dns
server on the DC so we are not seeing your case. sssd will pick up the
ldap SRV and assume that that is also the DNS. In real AD it seems that
this doesn't always have to be the case: a windows DC does not have to
also be the (a) DNS server.
Maybe we should send this to the dev list? Although I think they
sometimes look here too.