[KASP] setup KASP in master / slave architecture

Sat Dec 17 04:35:27 UTC 2022

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 how DNSSEC is designed so caching server also can provide all
of the records needed to validate. It definitely has no special knowledge
of the keys, singing policies, no zone files, etc.

On Fri, Dec 16, 2022 at 12:51 PM Darren Ankney <darren.ankney at gmail.com>
wrote:

> 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 {
>
>     key kea_bind_DDNS_SEC;
>
>   };
>
>   allow-transfer {
>
>     key "192.168.40.142-192.168.40.182-zone-transfer";
>
>   };
>
>   dnssec-policy default;
>
> };
>
> I just removed the zone and .jnl files from secondary and restarted. The
> actual zone: mylocal.saved showed up immediately.  About an hour
> later mylocal.saved.jnl appeared.
>
> On Dec 16, 2022, at 10:59 AM, adrien sipasseuth <
> sipasseuth.adrien at gmail.com> wrote:
>
> 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
>>
> --
> 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
>
>
> --
> 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/be8a0f13/attachment.htm>