> > > > > >
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users