On 3.8.2016 10:18, Longina Przybyszewska wrote:
Hi,
I attach logs from 2 machines, joined into the same AD realm ADM.DOMAIN , are on the same
subnet, almost identically configured:
adm-lnx438.adm.domain (A record not updated; dyndns_update = true;ptr_update = false)
lnx-adm555.adm.domain (A record updated, PTR record not updated; dyndns_update = true;
ptr_update = true; dyndns_server = xxx-vdc0f.domain )
xxx-vdc0f.domain - Primary DNS
xxx-vdc0g.domain - Secondary DNS
DNS -ins.site - Dns server and in-addr.arpa domain server
Windows machine on the same network, can recognize Dns servers and correctly makes dyndns
updates:
Output from ' ipconfig /all' :
Ins.site -DNS server
xxx-vdc0f.domain - Wins Primary DNS
xxx-vdc0g.domain - Wins Secondary DNS
It seems that adm-lnx438.adm.domain tries to make dyndns updates on secondary DNS and
can't figure out about primary DNS.
Best,
Longina
> -----Original Message-----
> From: Petr Spacek [mailto:pspacek@redhat.com]
> Sent: 27. juli 2016 16:11
> To: sssd-users(a)lists.fedorahosted.org
> Subject: [SSSD-users] Re: dyndns updates in sssd-13.4
>
> On 27.7.2016 14:54, Longina Przybyszewska wrote:
>> Hi ,
>> After upgrade to sssd-13.4, dyndns updates don't work in AD cross
>> realm environment
>>
>> Our DNS server is :
>> -not on the identity server (exactly, not on the default DC for the
>> domain) -DNS server and reverse DNS server are different machines
>>
>> It worked in previous release (also, DNS updates only) Now, for fixing
>> this I need to use the option 'dyndns_server' for explicitly point to
the
> server.
>>
>> It is not possible for dyndns_ptr updates, since sssd obviously assumes
> that there is one DNS for both A and PTR records.
>>
>> Do you plan 'dyndns_ptr_server' option as well in future realeseS?
>
> Please see
>
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_DNS_Updates
> and check debug logs.
>
> I'm very interested to see logs mentioned in the wiki page, that will help us
> to understand the problem.
>
> Thank you!
a) Regarding update to adm-lnx438.adm.domain.:
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29399
;; flags: qr rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;adm-lnx438.adm.domain. IN SOA
;; AUTHORITY SECTION:
domain. 900 IN SOA xxx-vdc0g.domain. hostmaster.site. 5127805
900 600 86400 900
Found zone name: domain
The master is: xxx-vdc0g.domain
The DNS SOA record claims that xxx-vdc0g.domain is the primary master. If it
is not true then you need to update the SOA record so DNS clients can find the
correct server.
This needs to be fixed on server side.
b) Regarding update to 249.1.80.10.in-addr.arpa.:
1.80.10.in-addr.arpa. 60 IN SOA ins.site. dns.site. 3282 10800
3600 2419200 900
Found zone name: 1.80.10.in-addr.arpa
The master is: ins.site
start_gssrequest
tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code
may provide more information, Minor = Server not found in Kerberos database.
This indicates that DNS server ins.site is not properly configured to accept
Kerberos-authenticated DNS updates.
This needs to be fixed on server side.
I hope it helps.
--
Petr Spacek @ Red Hat