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?
Best, Longina
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!
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@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!
-- Petr Spacek @ Red Hat _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd- users@lists.fedorahosted.org
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@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.
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?
Best, Longina
-----Oprindelig meddelelse----- Fra: Petr Spacek [mailto:pspacek@redhat.com] Sendt: 4. august 2016 11:08 Til: sssd-users@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@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 _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd- users@lists.fedorahosted.org
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@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@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.
sssd-users@lists.fedorahosted.org
-
Longina Przybyszewska -
Petr Spacek