Sites and DNS

[Amitay Isaacs]

On Wed, Mar 28, 2012 at 1:43 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>
>>  wrote:
>>>
>>> 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.
>>> sites,
>>> dc, gc etc.) were handled through directly manipulating the directory
>>> (RPC?)
>>> 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
>> working.
>
> Well isn't that odd... it's running exactly as it should.  I've just done my
> rename and samba_dnsupdate adds the site names perfectly in DNS.  I wonder
> if I've inadvertently broken my earlier one, I had been doing a lot of
> messing trying to get ISC DHCP playing nicely with secure updates (which I
> eventually succeeded with, with a slightly modified version of Sergey's
> script from http://pastebin.com/cNeVQdh3) for my non-AD clients.
>
> All I can do is backtrack here then, apologies to Amitay :-/
>
>>
>>> I've applied your workaround and samba_dnsupdate completes cleanly and
>>> sites
>>> are showing in DNS.  Renamed Default-First-Site-Name is showing, as well
>>> as
>>> Default-First-Site-Name itself, which was a surprise but I assume this
>>> will
>>> clear over time through whatever built-in scavenging is present.
>>
>> samba_dnsupdate script only adds missing entries or corrects wrong
>> entries. It does not at this stage remove any entries. So as you have
>> observed, the old names with Default-First-Site-Name would remain.
>> Currently there is no way to remove them.
>
> Okay, makes sense.  Nothing wrong with a little housekeeping anyway!  How
> often does samba_dnsupdate run and what's the criteria?  Should I be
> cron'ing it or do the samba binaries invoke it when needed?

The default value is 600 seconds. But there is a configuration option
to change this value.
dnsupdate:name interval

Amitay.