[Samba] Bind flat file support

[John Gardeniers]

Hi Andrew,

On 09/09/15 19:26, Andrew Bartlett wrote:
> On Tue, 2015-09-08 at 08:02 +1000, John Gardeniers wrote:
>> Is there any chance that support for Bind flat files will return?
> Not really.  I expect it to be less supported as time goes on.
Given that it's "no longer supported", support can hardly reduce further.

>> existing scripts many people use. I know that samba-tool can be used
>> in
>> scripts but due to its inadequate error checking it's incredibly easy
>> to
>> break the DNS.
> I'm sorry to hear that.  Patches to improve it are most welcome - what
> error checking is inadequate?
Just as an example, try using samba-tool to create an "@" record. It's 
perfectly valid in Bind but each time I try it, with either internal or 
Bind DLZ, the whole system breaks. The RSAT DNS tool fails to display 
any zones and lookups fail completely.

As for a patch, I would if I could but I struggle to make sense out of 
python code, let alone write it half decently.

>> There are very good reasons why nearly every admin I know prefers
>> flat
>> file. Ultimately, there is nothing easier than editing in text mode
>> and
>> on the extremely rare occasion that an error does creep in it's ultra
>> easy to remedy.
> The flat file backend cannot enforce AD ACLs on the modification of
> DNS, which in turn makes multi-DC deployment a hack, at best.
I must be missing something. DNS is a name <-> IP address lookup system. 
ACLs are OS/file system level. I can see no connection between them. If 
security of the AD area is the issue, surely allowing only authorised 
and secure updates on the AD child zone should be sufficient.

> It also cannot replicate the DNS information in the directory, where
> the DNS RPC server modifies it, and where Windows AD servers, which we
> strive to interoperate with, store their data.
I haven't used a Windows DC since Server 2003, so I can't comment on 
recent versions, but that version at least fully supported Bind 
secondaries, so what has changed to cause an interoperability problem? 
After all, if it's a legitimate DNS record Bind will happily replicate it.

> That is why we developed the DLZ plugin, and then the internal DNS
> server.
And if either of those ever near full functionality I'm sure this topic 
will disappear. Until then people need/want to be able to migrate the 
systems they are currently using and that cannot easily, or even at all, 
be done with the current state of DLZ. In our own environment we're 
looking at using internal DNS purely for the AD related stuff and put 
our real DNS on a separate server (using a different domain). To date I 
haven't even been able to get child domains to work properly with DLZ. I 
know the AD child domain works but not others. I can create them just 
fine but lookups invariably fail. DNS just shouldn't be that hard.

If not flat file support, what about one or more of the Bind natively 
supported database backends? Anyone who can get DLZ code to work (and 
they really do have my respect) should find those to be ultra easy.

regards,
John