On 4.8.2016 11:58, Longina Przybyszewska wrote:
Thanks for your answer and for the great software !
Maybe it worked before, because discovering get randomly answer from primary DNS server
at first.
I wonder how Windows machines can figure out dyndns updates with the same servers..
Is Wins Primary/secondary DNS configured manually - also, no need for discovering?
I think that Windows machines use the same method. Maybe they retry often
enough so the update gets through from time to time?
tcpdump or wireshark are your friends :-)
Petr^2 Spacek
>
> Best,
> Longina
>
>> -----Oprindelig meddelelse-----
>> Fra: Petr Spacek [mailto:pspacek@redhat.com]
>> Sendt: 4. august 2016 11:08
>> Til: sssd-users(a)lists.fedorahosted.org
>> Emne: [SSSD-users] Re: dyndns updates in sssd-13.4
>>
>> 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.