On Wed, 2014-06-25 at 12:37 +0000, Longina Przybyszewska wrote:
But adding A entry somehow works, maybe LDAP server redirects to
the DNS server.
It does not happen for subsequent dyndns trials. All fail .
All your posts were helpful, even you seemed to be annoyed about my obstinacy ;) , thanks
Thanks , for you noticed what is really my problem .
Well, you've succeeded in attracting the dev's attention. I'm sorry it
took so long to get to the bottom of this. I did not know that m$ had a
means of hosting dns on anything other than a dc. Here on on samba, we
can't, hence my assumptions. I _still_ think that the best way as to
what dns to use is to look at control panel on a windows box. So there.
Now I'm being obstinate lol!
[mailto:firstname.lastname@example.org] On Behalf Of steve
Sent: 25. juni 2014 14:16
Subject: Re: [SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04[NOT-SOLVED]
On Wed, 2014-06-25 at 11:54 +0000, Longina Przybyszewska wrote:
> > How SSSD resolves domainname for machine for supplying to nsupdate record?
> 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
> nameserver 10.220.2.5
> search c.sdu.dk
> .(Wed Jun 25 12:09:18 2014) [sssd[be[nat.c.sdu.dk]]]
> [be_nsupdate_create_ptr_msg] (0x0400): -- Begin nsupdate message --
> server nat-vdc0b.nat.c.sdu.dk realm NAT.C.SDU.DK 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 --
> host nat-vdc0b.nat.c.sdu.dk
> 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)
Maybe we should send this to the dev list? Although I think they sometimes look here
sssd-users mailing list
sssd-users mailing list