>
Yes, but the local DNS server can just point to the right servers in its configuration, in other words redirect to the AD DC. So SRV records realmd uses would still be valid, but the address of the resolver in resolv.conf wouldn't be usable for dyndns purposes.
Your method with realmd may get around that but unless you get the dns perfect you can forget about joining AD.
If as you say, you wish sssd to do as little as possible, then don't overwrite what dns does anyway by overriding the server which is sent to nsupdate. It is then up to the admin to sort out the dns when it doesn't work.
I agree with this completely. I need to run some tests and re-read the code more carefully later to verify if we're indeed using the server always (which would be a bug) or just as a fallback (which would be OK and could be improved even more with the option Simo suggested).
It seems that it is fallback. If nsupdate can figure out the right fqdn in the update record, it works for realm[..].
Before, for some reason (still not obvious for me, following realmd and auto-created sssd.conf it didn't work), nsupdate send short name, then subsequent dyndns updates fallback to the DC server[..], not DNS server.
--- [nsupdate_msg_create_common] (0x0200): Creating update message for realm [NAT.C.SITE.ORG]. (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- realm NAT.C.SITE.ORG update delete skywalker.nat.c.site.org. in A send update delete skywalker.nat.c.site.org. in AAAA send update add skywalker.nat.c.site.org. 3600 in A 10.80.8.91 send (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_fwd_msg] (0x0400): -- End nsupdate message -- (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2575] (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2575] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [be_nsupdate_done] (0x0200): nsupdate child status: 0
(Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_msg_create_common] (0x0200): Creating update message for realm [NAT.C.SITE.ORG]. (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- Begin nsupdate message -- realm NAT.C.SITE.ORG update add 91.8.80.10.in-addr.arpa. 3600 in PTR skywalker.nat.c.site.org. send (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- End nsupdate message -- (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2591] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2591] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [sdap_process_result] (0x2000): Trace: sh[0x1568d30], connected[1], ops[(nil)], ldap[0x156aac0] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_args] (0x0200): (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [sdap_process_result] (0x2000): nsupdate auth type: GSS-TSIG Trace: ldap_result found nothing! (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [256] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.sdu.dk]]] [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [1432158229]: Dynamic DNS update timed out
.....
(Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [256] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [sdap_dyndns_update_ptr_done] (0x0080): nsupdate failed, retrying with server name (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_msg_create_common] (0x0200): Creating update message for server [nat-vdc0b.nat.c.site.org] and realm [NAT.C.SITE.ORG] .(Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- Begin nsupdate message -- server nat-vdc0b.nat.c.site.org realm NAT.C.SITE.ORG update add 91.8.80.10.in-addr.arpa. 3600 in PTR skywalker.nat.c.site.org. send (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- End nsupdate message -- (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2597] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2597] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_args] (0x0200): nsupdate auth type: GSS-TSIG (Thu Jun 26 10:50:11 2014) [sssd[be[nat.c.site.org]]] [sbus_dispatch] (0x4000): dbus conn: 0x1514a40 (Thu Jun 26 10:50:11 2014) [sssd[be[nat.c.site.org]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Jun 26 10:50:11 2014) [sssd[be[nat.c.site.org]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.site.org]]] [nsupdate_child_timeout] (0x0020): Timeout reached for dynamic DNS update (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158229]: Dynamic DNS update timed out (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.site.org]]] [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [1432158229]: Dynamic DNS update timed out
---
---
Our DNS structure is combination of win DNS and Infoblox DNS (DHCP & split DNS for intern and extern addresser).
Win DNS servers (site-vdc0{g,f}.c.site.org) are responsible for top domain c.site.org, and subdomains {nat,tek..]c.site.org;
Infoblox DNS (ins.site.org) is responsible for all reverse zones plus some more (forward zones, external addresses etc.) - this is the one, which is known for resolver on all clients(my client too;). It turns out that in our case , Infoblox-reverse-DNS additionally, doesn't support Kerberos for updates.(!)
Best Longina
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users