[KASP] setup KASP in master / slave architecture

[adrien sipasseuth]

Hi,

I deleted my zone file <zone>.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 (https://dns.google/) I have the flag.

To summarize:
- on my master : declaration of my policy and I use it in my zone
configuration
- on the slaves : configuration of my zone, standard without mentioning
dnssec-policy

What I observe:
- on the master: files <zone>.db, <zone>.db.jbk,
<zone>.db.signed,<zone>.db.signed.jnl and my keys
- on the slaves: files <zone>.db

I don't understand why there is no <zone>.db.signed file on my slave
knowing that a dig from a slave does return RRSIG.

zone  "**************" {
    type slave;
        masters {  ************** ; };
    file "/ **************/ ************** / ************** .db";
};

Should I specify the <zone>.db or the <zone>.db.signed ? On the master
or/and ths slaves ?

Regards,

Adrien

Le jeu. 15 déc. 2022 à 19:10, Darren Ankney <darren.ankney at gmail.com> a
écrit :

> 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 @<some IP> <somehost>.<somedomain>. A +dnssec +multiline
>
>
> where <some IP> is the IP of your recursive server and
> <somehost>.<somedomain>. is something in the domain you are trying to
> verify the DNSSEC is working.
>
>
> Does your flags line look something like this?
>
>
> ;; flags: qr rd ra ad;
>
>
> Per the manual:
>
>
> The important detail in this output is the presence of the ad flag in the
> header. This signifies that BIND has retrieved all related DNSSEC
> information related to the target of the query (ftp.isc.org) and that the
> answer received has passed the validation process described in How Are
> Answers Verified?. We can have confidence in the authenticity and integrity
> of the answer, that ftp.isc.org really points to the IP address
> 149.20.1.49, and that it was not a spoofed answer from a clever attacker.
>
>
>
>
> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#using-dig-to-verify
>
> My “flags” line does not show the “ad” flag as this is just a set of
> private servers on a local lan. I can’t submit the DNSSEC details upstream
> as described here:
>
>
> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#uploading-information-to-the-parent-zone
>
>
> On Dec 15, 2022, at 12:05 PM, adrien sipasseuth <
> sipasseuth.adrien at gmail.com> wrote:
>
> 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 RRSIG when I
> do my "dig A" on a slave while on the master I do.
>
> Regards,
> Adrien
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221216/190f9a2e/attachment.htm>