Sites and DNS

Kev Latimer klatimer at
Wed Mar 28 02:09:52 MDT 2012

On 28/03/2012 08:06, Kev Latimer wrote:
> On 28/03/2012 02:42, Amitay Isaacs wrote:
>> On Wed, Mar 28, 2012 at 2:15 AM, Kev Latimer<klatimer at>  
>> wrote:
>>> On 27/03/2012 12:02, Amitay Isaacs wrote:
>>>> On Tue, Mar 27, 2012 at 9:17 PM, Kev Latimer<klatimer at>
>>>>   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:
>>>>> (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.
>>> 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 
>>>   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.
>> Amitay.
> Run samba_dnsupdate with the options you've specified from my new DC 
> in the second site - seems to run fine, no errors.  The BIND logs 
> running on the first DC also shows everything working as it should, 
> showing the name of the signer as the second DC and allowing updates 
> with transactions committing fine.  No problems with the mechanism there.
> The problem seems to be that I can't see any mention of the new sites 
> in these updates; the only site I see is the reamed first site.  I 
> don't see any Default-First-Site-Name, so it has at least stopped 
> updating on that, but no mention of the new site.  In fact, it adds 
> the new server as a DC in the renamed first site despite it being in 
> the new second site in the MMC.
> I'll add a third DC now in a third site (this time I'll see if it 
> picks up that it shoudl automatically go in the third site based on 
> it's subnet) and see what happens.
> Cheers,
> Kev
Okay, so that was interesting.  Creating the site in the Sites and 
Services MMC, and defining and linking the subnet to the new site 
*BEFORE* adding the new DC to the domain yields the correct DNS 
structure.  The DC was added to the correct site automatically when it 
joined and a run of samba_dnsupdate shows the new site under _sites in 
each of the expected DNS namespaces.  It didn't show until after the run 
of samba_update but I expect that would have sorted things out within 
the 600 seconds you mentioned.  The second site site still doesn't show 
in DNS, however, so it would seem that moving a server into a site is 
where it's falling down, almost like it doesn't know it's supposed to be 
in the site?

At least I do have a workaround now, that is, to make sure the sites are 
created prior to joining the DC.


More information about the samba-technical mailing list