Bug 5368 - Dynamic DNS Updates for Provisioning
Summary: Dynamic DNS Updates for Provisioning
Status: RESOLVED WONTFIX
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Andrew Bartlett
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-02 03:13 UTC by David Holder
Modified: 2008-09-10 07:42 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Holder 2008-04-02 03:13:13 UTC
In Windows
the DC adds the DNS resource records to the zone using DDNS. In theory, the
zone can be hosted on any DNS server that supports DDNS. The snag with using
BIND for the DNS server has always been its lack of support for the security
mechanism used by Windows, that is GSS-TSIG. 

Wouldn't it be better to change the provisioning script so that it uses DDNS to
update the zone data?

Issues are:
1) What do you do if the DNS server does not support DDNS?
2) What if you want to use GSS-TSIG to secure the DDNS updates? (solution could
be use to use development version of BIND that does include support for
GSS-TSIG.)
3) Do you allow Samba4 to provision using BIND's TSIG?

I tried to get BIND's DDNS with GSS-TSIG to work with AD last year and couldn't get it to work. However, I heard that others have more success. Also, I understand that Samba have their own GSS-TSIG implementation, is this correct and could this be used to solve this?
Comment 1 Matthias Dieter Wallnöfer 2008-08-02 08:49:04 UTC
Aren't we having some some support of GSS-TSIG? (I looked at the comments in the template "named.conf" file of SAMBA 4)
Comment 2 Andrew Bartlett 2008-09-10 07:42:40 UTC
I don't propose to do DDNS updates during provision. 

Firstly, it would need to be disabled in all our tests, as we have no DNS server configured in the socket_wrapper test environment.  

Secondly, it would require the name server be correctly configured and started, during the provision.  So far we have only forced this for the optional LDAP backend, and even that is less than ideally handled.

As a client I'm happy to just import (or have someone else propose a patch to import) Samba3's DNS update functionality, at some point.   However, this belongs as much in the system network scripts as Samba. 

Your points are valid, but I don't see a useful resolution other than WONTFIX (sorry).