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.adr...@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.ank...@gmail.com > <mailto:darren.ank...@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.adr...@gmail.com <mailto:sipasseuth.adr...@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@lists.isc.org <mailto:bind-users@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@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users