On 30/6/2019 20:34, Grant Taylor via bind-users wrote:
> I think you're missing options that are outside of the box. ;-)
Very true! :-) I like to make my life easier
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from
On 6/30/19 11:34 AM, Grant Taylor via bind-users wrote:
I'm quite confident that Dynamic* zones are /NOT/ /required/ to support
automation of ACME client operation using DNS for authentication /
authorization.
That being said, I do think that Dynamic* zones are probably one of the
/easier/ wa
On 6/30/19 3:38 AM, Lefteris Tsintjelis via bind-users wrote:
If you do it manually yes; if you do it automatically from a cron job,
everything is timed.
How does using a cron job change things?
Let's Encrypt (or other ACME providers) behaves the same way for manual
client operation as they d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sun, 2019-06-30 at 12:38 +0300, Lefteris Tsintjelis via bind-users
wrote:
> Again, no it is not required but only if you do it manually. The idea
> here is to automate everything and, unless I am missing something,
> there is no other way to do th
On 30/6/2019 0:29, Grant Taylor via bind-users wrote:
> On 6/29/19 2:13 PM, Lefteris Tsintjelis via bind-users wrote:
>> Standard DNS mechanisms and poll would not work. Everything must be
>> done within 1 minute so notify MUST be used and therefor zone serial
>> must be increased and of course all
On 6/29/19 2:13 PM, Lefteris Tsintjelis via bind-users wrote:
Standard DNS mechanisms and poll would not work. Everything must
be done within 1 minute so notify MUST be used and therefor zone
serial must be increased and of course all secondaries MUST be online
and respond to the notify properl
On 29/6/2019 21:55, Grant Taylor via bind-users wrote:
> On 6/29/19 12:30 PM, Lefteris Tsintjelis via bind-users wrote:
>> 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
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 yo
On 26/6/2019 20:25, Tony Finch wrote:
> 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
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?
Yes.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Southwesterly 5 to 7. Moderate, occasionally rough at
fi
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 A
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?
>
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 wo
On 26/6/2019 21:57, Tony Finch wrote:
> Lefteris Tsintjelis via bind-users 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 s
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
Lefteris Tsintjelis via bind-users 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 co
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
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 su
Grant Taylor via bind-users 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
On 26/6/2019 20:25, Tony Finch wrote:
> 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
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!
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
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
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?
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. S
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
> wrote:
>
> Hi,
>
> Is it possible to apply temporary only update
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/name
27 matches
Mail list logo
