[KASP] setup KASP in master / slave architecture

[Darren Ankney]

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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221215/4f2c898f/attachment-0001.htm>