I’m trying to use Cascade with BIND with this configuration:
-Bind master nameserver with unsigned zone. This nameserver allows zone transfer to Cascade via AXFR and sends notifies to the “Notify-listeners server” of Cascade.
-Cascade downloads the unsigned zone from the master nameserver and publishes the signed zone via AXFR.
-Bind slave nameserver try to downloads via AXFR the signed zone from Cascade and then publishes it.
I’m testing this configuration because, as written in the manual, it’s not good expose Cascade publicly on internet since it’s designed to be an hidden signer (and i agree).
So i need to publish the signed zone in a “true” nameserver.
Cascade works very well while signing the zone from a zone in downstream, and it works very well resigning the zone when a notify from the master nameserver arrives.
There is a problem when i need to transfer the signed zone in a nameserver because Cascade can’t be an authoritive nameserver for his signed zone and then the slave nameserver
Can’t download this signed zone via AXFR because doesn’t receive authoritive responses. I can’t load the signed zone manually in an authoritive nameserver because the signed zone is not saved on disk (i can do dig @cascade_ip zone-name AXFR > file path but i have to modify the text).
So i can’t understand the philosofy around the zone transfer from Cascade to “someone” via AXFR, and i will appreciate your answers for this point.
Then, it’s possible to allow the axfr transfer from Cascade to specified IP Addresses only using any options instead using a firewall?
Cascade v.alpha 5 doesn’t publish CDS and CDNSKEY in the signed zone, so i’m asking if there is a manual command in Cascade able to generate (in the parent zone) the DS from a known KSK?
Thanks once again for trying out Cascade and for sharing your observations and questions with the community, and sorry about the delay in responding.
You are using Cascade as intended, but encountered a bug that causes issues when using BIND as a downstream secondary. This issue does not occur when using NSD which our testing thus far used. Thanks to our new integration test framework which includes BIND we will be able to add tests which will catch this kind of issue in future.
So, yes Cascade is intended to be used as a “hidden primary” signer, i.e. that the signed zones that it publishes are consumed by secondary nameservers who themselves act as the authoritative servers for the zone, with nobody outside knowing that the Cascade server exists, hence it being termed “hidden”.
And yes Cascade can publish the zone toward the secondaries via XFR, this is what we do with cascade.nlnetlabs.nl where a hidden Cascade instance runs behind a public NSD instance. The difference with your setup is that you are using BIND rather than NSD. Thank you for reporting this issue, we have verified as you state that BIND refuses to transfer the zone from Cascade because the SOA response it receives has the AA flag unset.
We will issue an initial fix which sets the AA flag on responses, and as part of the ongoing work to improve how zone data is stored and accessed we will develop a proper fix that determines if Cascade is actually authoritative for the response being served and sets the AA flag accordingly.
Regarding CDS and CDNSKEY, these are currently produced by dnst keyset but not yet consumed by Cascade, this is on our TODO list.
I want to share the things i wrote in the email i just sent to you:
I was monitoring the DNS packets from Cascade to the Bind secondary nameserver, and i saw that the AXFR response from Cascade are set with the flag AA=0.
Bind can download the zone via AXFR only if the responses have the flag AA=1 (only authoritive responses).
Looking at the RFC5936, the AXFR response must have the AA=1 if it has RCODE=0 (no error). At the same time, it’s reccomended to the AXFR client (the AXFR query sender) to ignore the value of AA.
So i can imagine that NSD ignores the value of AA and that’s the reason of its good behaviour with Cascade.
Yes, NSD allows the response from an AXFR (and also IXFR) without the AA flag. It could check that, but that is not needed for NSD to accept the response. NSD produces zone transfers, both AXFR and IXFR with the AA flag set, when NSD is used to provide zone transfers to another downstream querier.