[KASP] setup KASP in master / slave architecture

[Darren Ankney]

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 <mailto: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 <http://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 <http://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 <mailto: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 <mailto: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/d83aaa3d/attachment-0001.htm>