Sites and DNS

[Kev Latimer]

On 28/03/2012 02:42, Amitay Isaacs wrote:
> 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>
>>>   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.
>> 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.
>
> 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

-- 
Kev**