The statement that a BIND secondary only uses one file is incorrect. A
secondary will write IXFR data to a journal file, a jnl file.
But as has been stated earlier in the thread, a secondary is not involved
in anyway in signing a zone. One way to possibly make more sense of this is
to consider
This is all I have in my zone on secondary:
zone "mylocal" {
type secondary;
file "/etc/bind/mylocal.saved";
primaries {
192.168.40.142;
};
};
My primary is a little more complicated:
zone "mylocal" {
type primary;
file "/etc/bind/mylocal";
notify yes;
allow-update {
On 16 Dec 2022, at 15:59, adrien sipasseuth wrote:
> - on the slaves: files .db
>
> I don't understand why there is no .db.signed file on my slave
> knowing that a dig from a slave does return RRSIG.
The secondary (slave) only needs one file to hold whatever zone
data the primary provides when
Hi,
I deleted my zone file .db on my slaves and I forced a transfer from
the master.
Now it seems to work, I do have the RRSIG associated with my RRset A when I
do a dig from my slave.
When I test my dig from my internal network I actually don't have the ad
flag. But from the google resolver
I have a simple “mylocal” zone setup with a primary and secondary server.
my primary has this .jnl file:
mylocal.jnl
My secondary has this similar .jnl file:
mylocal.saved.jnl
which I believe was distributed via zone transfer. You find no such similar
files on your secondary?
If you
dig
Hi,
Ok, I got confused, no need for the keys on the slavs actually.
On the other hand, my slaves should generate the .signed, .signed.jnl and
.jbk files of my zones, no? currently it is not my case, should I copy them
from the master?
moreover, when I test a "dig A" I don't have the associated
>
>
> the keys are generated on the master but not on the slaves.
> so I don't understand how the slaves can read their zone file which ends in
> ".signed" because they don't have the keys ? (but it's work with dig, i see
> DS with the right ZSK)
>
> Regards
>
> Adrien
>
Because the zone
Hi,
It seems to work! Thank you!
To summarize:
On the master side I have the following configuration:
dnssec-policy "test" {
keys {
ksk lifetime P3D algorithm rsasha256 2048;
zsk lifetime P2D algorithm rsasha256 1024;
};
};
zone "**" {
type
Hi,
No.
You don't need DNSSEC maintenance on your secondary zones if you already
have set it on your primary zones. So
zone "***" {
type secondary;
primaries { ***; };
file "***.db";
};
is enough.
Best regards,
Matthijs.
On 12/9/22 09:58, adrien sipasseuth wrote:
Hi
Hi Matthijs,
thank you, so just to confirm something like this should work :
Master :
dnssec-policy "test" {
keys {
ksk lifetime P3D algorithm rsasha256 2048;
zsk lifetime P2D algorithm rsasha256 1024;
};
};
zone "**" {
type master;
file
Hi Adrien,
You should **not** copy the dnssec-policy configuration to your
secondaries. They transfer in the signed zone from the primary server.
Best regards,
Matthijs
On 12/9/22 09:24, adrien sipasseuth wrote:
Hello,
Lokking for some guidance, sorry if i use the wrong way to contact
Hello,
Lokking for some guidance, sorry if i use the wrong way to contact community
user support.
I would like to set up DNSSEC using KASP.
I have an architecture with a master and several slaves.
Here is my policy and zone configuration:
dnssec-policy "test" {
keys {
ksk
12 matches
Mail list logo
