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
