On 26 Jun 2014, at 16:19, Longina Przybyszewska <[email protected]> wrote:
>>>>>>>>
>> 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.
>
Hi Longina,
I’ve sent a patch to the sssd-devel list that adds a new option for sssd.conf
which lets you specify the DNS server to use:
https://lists.fedorahosted.org/pipermail/sssd-devel/2014-July/020586.html
Are you OK testing the patch yourself or would you prefer if we help you
prepare some test build? We can do any Fedora/RHEL version and we also have
some (limited) Debian experience..
Thank you very much for the patience while we debugged the issue and prepared a
patch.
> ---
> [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
> [email protected]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> _______________________________________________
> sssd-users mailing list
> [email protected]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
