Allow only temporary zone updates without making them permanent

[Lefteris Tsintjelis]

On 26/6/2019 20:25, Tony Finch wrote:
> Lefteris Tsintjelis via bind-users <bind-users at lists.isc.org> wrote:
>> On 26/6/2019 17:39, Grant Taylor via bind-users wrote:
>>> Or are you wanting to update the zone contents without actually updating
>>> the zone file on disk?
>>
>> Yes, exactly this. That is the reason I changed the actual zone disk
>> file permissions to root thinking that files would not be modifiable,
>> but bind surprised me there. I did not expect to change the file
>> ownership from root to bind! The problem started with ACME actually as
>> it always messes up my disk zone files and have to always restore them.
>> I would still like to use something like that in small DDNS zones also,
>> serving just a few IPs only. Non disk writable/modifiable zones could
>> perhaps add a small layer of extra security as well.
> 
> If you have a dynamic zone then it's best to work as if the zone file
> belongs to `named`. I configure `masterfile-format raw;` which removes the
> temptation to look at the files directly. Instead I use `dig axfr` or
> `named-compilezone -j`.

I prefer the text format and I always use masterfile-format text. I am
always tempted to check if everything is OK. Probably a waste of time
but I just feel safer if I can see things.

> In most cases I keep the original source of the zone data elsewhere, e.g.
> a file stored in version control or a database, and I sync up the working
> copy of the zone with it source file using https://dotat.at/prog/nsdiff/
> This also means I don't have to care about serial numbers or DNSSEC
> records because `named` takes care of those.

It sounds really interesting to manage large domains. I was looking at
those tools (nsdiff/nsvi) and tried to find more info. I will definitely
check them out in the near future.

> (I have a few less complicated zones where I don't have a separate source
> file and instead use `nsvi` to edit the working copy.)

I think this sounds much better for me. I like to have records organized
the way I want in a zone file. It helps me and gives me a very quick map
of the network. This is actually and the main reason I prefer text.

> You should have secondary servers for your zone, in which case
> ACME-related updates will be copied to the secondary and stored on disk
> there, so suppressing writes on the primary won't make any useful
> difference to how temporary the records are.

Secondaries though are almost always slaves, so writing suppression
doesn't really matter for them. It is the primary that only matters so
if it could suspend writing for just one minute then everything would
complete perfectly OK. The ACME record doesn't have to be permanently
stored anywhere.

> There are other ways to keep temporary dynamic records separate from your
> fixed data, e.g. you can delegate _acme-challenge.<host> to a separate
> dynamic zone, or to reduce the proliferation of zones, make
> _acme-challenge.<hosts> CNAMEs to consolidate them into one separate
> dynamic zone.

Thank you! This is the "proper" way to do it. I have tested the
_acme-challenge only dynamic zone as you described it and it worked
perfectly well and as expected but there is a quite a lot to do for just
one record for one minute in order to work properly.

I am not sure about the CNAMEs. It sounds easier to implement as there
is only one dynamic zone for all hosts but I am not sure how. The
_acme-challenge.<host>, from what I know, is expected to be within the
main domain zone in order for ACME to work properly, so how would it
work in a separate dynamic one? Wouldn't ACME reject it?

Lefteris