Sites and DNS
amitay at gmail.com
Tue Mar 27 19:42:33 MDT 2012
On Wed, Mar 28, 2012 at 2:15 AM, Kev Latimer <klatimer at tolent.co.uk> wrote:
> On 27/03/2012 12:02, Amitay Isaacs wrote:
>> On Tue, Mar 27, 2012 at 9:17 PM, Kev Latimer<klatimer at tolent.co.uk>
>>> On 27/03/2012 10:42, Kai Blin wrote:
>>> On 2012-03-27 11:04, Kev Latimer wrote:
>>> Hi Kev,
>>> Okay, reprovisioned, debug level set to 2 in smb.conf, made sure it's
>>> all working okay, renamed default site, stopped Samba, cleared log.samba
>>> to remove any guff (mainly my XP test machine trying so desperately to
>>> find it's AV update source!), started up again and manually ran
>>> samba_dnsupdate. Resulting log file for the few seconds it took to give
>>> the FORMERR again is nearly 800k, which is over the pastbin max so I've
>>> gzipped and uploaded it to my personal webspace here:
>>> http://www.kevnet.org.uk/samba4/log.samba.gz (probably not strictly good
>>> netiquette but hope that's okay).
>>> Great, got it. So what's happening is this:
>>> samba_dnsupdate tries to negotiate a TKEY exchange for a
>>> cryptographically signed update, but the internal server doesn't
>>> understand that record type yet (in master, working on this stuff right
>>> now). Because the server thinks the record type is invalid, it returns
>>> FORMERR. This should hopefully be fixed soon, but in the meantime, try
>>> the following workaround:
>>> In smb.conf, set
>>> nsupdate command = nsupdate
>>> allow dns updates = True
>>> That will allow unsigned dns updates to you zone, so it's not the most
>>> secure option, but it should work.
>>> Makes sense. I was aware it didn't support signed updates yet but I
>>> think I
>>> assumed that DNS records that exposed elements of the directory (ie.
>>> dc, gc etc.) were handled through directly manipulating the directory
>>> with DNS just exposing the result. I think I'd discounted signing as an
>>> issue in this case I was seeing the same result with BIND9_DLZ.
>> Do you have the named log where dynamic updates did not work?
>> You can start named manually and redirect the logs to a file.
>> /usr/sbin/named -u named -f -g | tee log.named
>> And try running samba_dnsupdate. The log should tell us why it's not
> Need to backtrack on myself now, as I've just spotted the error while I
> added my second DC and subsequently, site. Only Default-First-Site-Name and
> the renamed site are showing in DNS, my new and any subsequent sites are not
> although they show in MMC Sites and Services. samba_dnsupdate returns no
> errors and the the log redirect above yields no clues. Seems to start up
> just fine and I can resolve SRV records against _ldap._tcp.mydomain.com.
> It's BIND 9.8.1-P1 taken from Debian testing and built against stable if
> that makes any difference.
> Nothing in log.samba either. Anywhere else I can look? Does
> samba_dnsupdate have an interactive/foreground mode?
> This is BIND9 DLZ, _not_ the internal DNS server. Haven't tried adding
> another site with internal yet...
To make this easier to debug, please run samba_dnsupdate on a DC in a
different site. You can get more information from samba_dnsupdate by
running it with '--verbose --allnames' options. We need to make sure
that this updates the names in the correctly.
More information about the samba-technical