Allow only temporary zone updates without making them permanent

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
Hi,

Is it possible to apply temporary only update policy and never save or
modify anything to a zone file?

For example:

zone "example.com" {
 type master;
 auto-dnssec maintain;
 inline-signing yes;
 update-policy {
  grant rndc-key temponly _acme-challenge.example.com. txt;
 };
 file "/etc/namedb/master/db.example.com";
};

Thank you,

Lefteris
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Mark Andrews
No.

If https://tools.ietf.org/id/draft-pusateri-dnsop-update-timeout-02.txt ever get
adopted then yes it will be possible to have updates removed automatically.

> On 26 Jun 2019, at 1:25 pm, Lefteris Tsintjelis via bind-users <[hidden email]> wrote:
>
> Hi,
>
> Is it possible to apply temporary only update policy and never save or
> modify anything to a zone file?
>
> For example:
>
> zone "example.com" {
> type master;
> auto-dnssec maintain;
> inline-signing yes;
> update-policy {
>  grant rndc-key temponly _acme-challenge.example.com. txt;
> };
> file "/etc/namedb/master/db.example.com";
> };
>
> Thank you,
>
> Lefteris
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
That could take years, if even adopted! Perhaps something simpler like a
file permission/lock could do the job as well. Would that work though?

When I used certbot with rfc2136 validation through DNS, eventhough I
have the main zone file permission set to root, I find it changed to
that of bind. Seems like bind is capable of changing and modifying
permissions?

On 26/6/2019 6:36, Mark Andrews wrote:

> No.
>
> If https://tools.ietf.org/id/draft-pusateri-dnsop-update-timeout-02.txt ever get
> adopted then yes it will be possible to have updates removed automatically.
>
>> On 26 Jun 2019, at 1:25 pm, Lefteris Tsintjelis via bind-users <[hidden email]> wrote:
>>
>> Hi,
>>
>> Is it possible to apply temporary only update policy and never save or
>> modify anything to a zone file?
>>
>> For example:
>>
>> zone "example.com" {
>> type master;
>> auto-dnssec maintain;
>> inline-signing yes;
>> update-policy {
>>  grant rndc-key temponly _acme-challenge.example.com. txt;
>> };
>> file "/etc/namedb/master/db.example.com";
>> };
>>
>> Thank you,
>>
>> Lefteris
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>
>> bind-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/bind-users
>

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
In reply to this post by Bind-Users forum mailing list
On 6/25/19 9:25 PM, Lefteris Tsintjelis via bind-users wrote:
> Is it possible to apply temporary only update policy and never save or
> modify anything to a zone file?

What would this functionally do?

Or are you wanting to update the zone contents without actually updating
the zone file on disk?

I'm guessing that you want the change to the zone for at least long
enough for the ACME challenge to pass.  And then possibly remove the
necessary record.

Both the act of adding (changing) the requisite resource record, and
then subsequently removing it from the zone are changes to the zone.
Both of which should change (increment) the zone's serial number.  So,
even if you didn't commit the change to the zone's file, the in memory
zone's serial number in memory would now be out of sync with the on disk
zone's serial number.

I'm guessing I'm not understanding your use case.

I feel like a judiciously crafted update policy to allow something to
update it's specific resource record(s) is probably what you want.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
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.

Lefteris
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Tony Finch
Lefteris Tsintjelis via bind-users <[hidden email]> 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`.

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.

(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.)

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.

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.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Irish Sea: Variable mainly northeasterly 4 or 5, occasionally 6 in south and 3
in north. Slight or moderate in south, smooth or slight in north. Fair. Good.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
In reply to this post by Bind-Users forum mailing list
On 6/26/19 10:46 AM, Lefteris Tsintjelis via bind-users wrote:
> 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!

I'm surprised at the ownership change too.

It may be dependent on your OS init scripts, perhaps they are changing them.

The only way that I see that BIND, running as something other than root,
could change them is if the user it's running as has write on the
directory and deletes & recreates new zone files as itself.  But that
would surprise me too.

> The problem started with ACME actually as it always messes up my disk
> zone files and have to always restore them.

Is the ACME client modifying the zone file(s) directly?  Or is it using
dynamic DNS (possibly via nsupdate) to request that BIND update the zone(s)?

> 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.

I'd be surprised if BIND supported a zone that was not persistent
somewhere.  Maybe it can have an in-memory copy of something it gets via
zone transfer.  But I have my doubts about that.

I also question the value of such a zone.  What is the use of it?



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
In reply to this post by Tony Finch
On 26/6/2019 20:25, Tony Finch wrote:

> Lefteris Tsintjelis via bind-users <[hidden email]> 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`.
>
> 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.
>
> (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.)
>
> 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.

Yes, I have done just about most of them already for large zones so I am
not worried about loosing anything. But besides the messy ACME update
file zone results, it was the idea of the unauthorized file ownership
change that kind of started to worry me there as well.

> 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.

This is exactly what I try to do in and keep dynamic things completely
separate from fixed. That is an excellent idea and takes care of the
dynamic ACME problem!

Thank you

Lefteris
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Tony Finch
In reply to this post by Bind-Users forum mailing list
Grant Taylor via bind-users <[hidden email]> wrote:
>
> The only way that I see that BIND, running as something other than root, could
> change them is if the user it's running as has write on the directory and
> deletes & recreates new zone files as itself.  But that would surprise me too.

`named` requires write access to the directory containing dynamic zones,
because it needs to be able to create files there. It will rewrite the
zone file from scratch when it merges in the journal, which is what would
cause the change of ownership.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
sovereignty rests with the people and authority
in a democracy derives from the people
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
On 26/6/2019 21:13, Tony Finch wrote:
> It will rewrite the
> zone file from scratch when it merges in the journal, which is what would
> cause the change of ownership.

That makes perfect sense, but I was still shocked when I first saw it
specially to a file owned by root. This is the part that surprised me
and worried me the most! I was under the impression that after start up,
named would switch to the user configured to do so and it will no longer
be able to access or change other files but its' own.

Lefteris
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
In reply to this post by Bind-Users forum mailing list
On 26/6/2019 20:25, Grant Taylor via bind-users wrote:

> On 6/26/19 10:46 AM, Lefteris Tsintjelis via bind-users wrote:
>> 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!
>
> I'm surprised at the ownership change too.
>
> It may be dependent on your OS init scripts, perhaps they are changing
> them.
>
> The only way that I see that BIND, running as something other than root,
> could change them is if the user it's running as has write on the
> directory and deletes & recreates new zone files as itself.  But that
> would surprise me too.
>
>> The problem started with ACME actually as it always messes up my disk
>> zone files and have to always restore them.
>
> Is the ACME client modifying the zone file(s) directly?  Or is it using
> dynamic DNS (possibly via nsupdate) to request that BIND update the
> zone(s)?

ACME is through net and not directly. I have checked and tripled checked
that a few times, as well as the init/startup scripts. It is not ACME,
it is named that modifies the file and it happens right after the
dynamic ACME update.

Lefteris
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Tony Finch
In reply to this post by Bind-Users forum mailing list
Lefteris Tsintjelis via bind-users <[hidden email]> wrote:
>
> That makes perfect sense, but I was still shocked when I first saw it
> specially to a file owned by root. This is the part that surprised me
> and worried me the most! I was under the impression that after start up,
> named would switch to the user configured to do so and it will no longer
> be able to access or change other files but its' own.

You are right about what named does, but you are also encountering
a classic UNIX gotcha, legitimately perplexing.

See here, and click through the notes related answers to other questions:
https://unix.stackexchange.com/questions/75395/why-am-i-able-to-delete-file-which-belongs-to-root-under-a-non-root-user

Also have a look at the description of the sticky bit in the chmod man page.
It makes directory permissions work more like you might expect.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
a just distribution of the rewards of success
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Chuck Anderson
In reply to this post by Bind-Users forum mailing list
On Wed, Jun 26, 2019 at 07:46:20PM +0300, Lefteris Tsintjelis via bind-users 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 Linux:

chattr +i filename

If FreeBSD:

chflags schg filename
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
In reply to this post by Tony Finch
On 26/6/2019 21:57, Tony Finch wrote:

> Lefteris Tsintjelis via bind-users <[hidden email]> wrote:
>>
>> That makes perfect sense, but I was still shocked when I first saw it
>> specially to a file owned by root. This is the part that surprised me
>> and worried me the most! I was under the impression that after start up,
>> named would switch to the user configured to do so and it will no longer
>> be able to access or change other files but its' own.
>
> You are right about what named does, but you are also encountering
> a classic UNIX gotcha, legitimately perplexing.
>
> See here, and click through the notes related answers to other questions:
> https://unix.stackexchange.com/questions/75395/why-am-i-able-to-delete-file-which-belongs-to-root-under-a-non-root-user
>
> Also have a look at the description of the sticky bit in the chmod man page.
> It makes directory permissions work more like you might expect.

If I set it though, and named no longer has access to modify and rewrite
other files but its own, will it break things? What will happen in case
of a dynamic update like ACME in this case? Will the update go through?

Lefteris
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
On 6/26/19 1:17 PM, Lefteris Tsintjelis via bind-users wrote:
> If I set it though, and named no longer has access to modify and rewrite
> other files but its own, will it break things? What will happen in case
> of a dynamic update like ACME in this case? Will the update go through?

I think that would be HIGHLY dependent on /how/ named updates files.

Does it try to move (rename) existing files and create /new/ files?  Or
does it rewrite contents of /exiting/ files.

I don't know these particulars.  I've never had a problem allowing named
to have write access to the directory and do what it wants with the
files therein.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
In reply to this post by Chuck Anderson
On 26/6/2019 22:04, Anderson, Charles R wrote:

> On Wed, Jun 26, 2019 at 07:46:20PM +0300, Lefteris Tsintjelis via bind-users 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 Linux:
>
> chattr +i filename
>
> If FreeBSD:
>
> chflags schg filename

Or chmod +t <directory> I had totally forgotten about that one.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
In reply to this post by Bind-Users forum mailing list
On 26/6/2019 22:56, Grant Taylor via bind-users wrote:

> On 6/26/19 1:17 PM, Lefteris Tsintjelis via bind-users wrote:
>> If I set it though, and named no longer has access to modify and
>> rewrite other files but its own, will it break things? What will
>> happen in case of a dynamic update like ACME in this case? Will the
>> update go through?
>
> I think that would be HIGHLY dependent on /how/ named updates files.
>
> Does it try to move (rename) existing files and create /new/ files?  Or
> does it rewrite contents of /exiting/ files.
>
> I don't know these particulars.  I've never had a problem allowing named
> to have write access to the directory and do what it wants with the
> files therein.

Just to satisfy my curiosity, I will have to do more experimenting but I
believe the best way to deal with this and to avoid possible trouble is
to create an independent zone, just as Tony previously described.

Thank you all

Lefteris
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Tony Finch
In reply to this post by Bind-Users forum mailing list
Lefteris Tsintjelis via bind-users <[hidden email]> wrote:
>
> If I set it though, and named no longer has access to modify and rewrite
> other files but its own, will it break things?

Yes.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Southeast Iceland: Southwesterly 5 to 7. Moderate, occasionally rough at
first. Fog patches, rain later. Moderate, occasionally very poor.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
In reply to this post by Tony Finch
On 26/6/2019 20:25, Tony Finch wrote:

> Lefteris Tsintjelis via bind-users <[hidden email]> 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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Allow only temporary zone updates without making them permanent

Bind-Users forum mailing list
On 6/29/19 12:30 PM, Lefteris Tsintjelis via bind-users wrote:
> 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.

I'll argue that it doesn't matter (much) why you want text zones.  You
want them, therefore you should have them as long as it's an option.

> 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.

Hypothetical scenario:  Secondary (slave) does not receive a notify,
waits and polls the Primary (master) per standards DNS mechanisms.

If the secondary (slave) has a sufficiently old serial (say it's been
offline for maintenance), it will see the new serial and do a zone
transfer, including the temporary ACME records.

Timing and other conditions might make this unlikely to happen, but I
think that it is a possibility.

> 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.

This is why some people say "pick the lesser of the evils".  ;-)

> 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?

The _acme-challenge.<host> record name is expected to be within the main
domain zone.  But there is nothing that prevents that record from being
a CNAME to another zone.

_acme-challenge.www.example.org is a CNAME to www.example.org.dynamic.local
_acme-challenge.www.example.net is a CNAME to www.example.net.dynamic.local
_acme-challenge.www.example.com is a CNAME to www.example.com.dynamic.local

So the only dynamic zone is dynamic.local.  Yet ACME clients can query
their expected names, follow the CNAME, and get the data they need.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
12