PR #564 adds support for using TSIG with Cascade.
One known issue that was noted on that PR was:
Incoming DNS messages that are TSIG signed will be rejected if the key used to sign the message is not registered with Cascade.
Added keys are relevant for all zones because once a key is added to the global Cascade store, any incoming DNS message (whether from upstream, e.g. NOTIFY, or from downstream, e.g. AXFR or SOA) will be handled by the TsigMiddlewareSvc which, even if a zone is not configured to use TSIG, will still reject the incoming message if that message uses a TSIG key which is not in the global Cascade TSIG store.
This could be worked around by adding a custom middleware service layer impl between TsigMiddlewareSvc and NotifyMiddlewareSvc that does the "correct key" and "correct no key" checks.
@bal-e noted a concern with this:
The description may be accurate, but the behavior sounds far from ideal. It sounds like the TSIG middleware service activates once the TSIG key store is non-empty; but this means TSIG config for one zone affects others, which is IMO quite surprising. Cascade should only allow TSIG keys that are relevant for the zone being queried; it's okay to document the real implemented behavior, but I think this description should also mention the direction we want to move to. We should create a GH issue for reaching the desired TSIG behavior and we could then link to it here.
And a possible next step:
Perhaps we could just add a check for this in the new ZoneService type. It has access to all the right information.
This won't work because the TSIG middleware layer will reject the message without the ZoneService ever receiving it.
PR #564 adds support for using TSIG with Cascade.
One known issue that was noted on that PR was:
@bal-e noted a concern with this:
And a possible next step:
This won't work because the TSIG middleware layer will reject the message without the ZoneService ever receiving it.