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> 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.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 > 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