Is there a way protect AXFR and IXFR queries to require TSIG?

[pusateri]

Thanks for adding TSIG support. This is very cool.

Current TSIG middleware docs say:

Signed requests that fail signature verification will be rejected.
Unsigned requests and correctly signed requests will pass through this middleware unchanged.

Is there a way to require Signed requests only?

[ximon18]

Yes.

As an example the XfrMiddlewareSvc middleware can optionally do this via the XfrDataProvider impl, by checking in that impl if the Option<Key> is None and then refusing the XFR.

No existing provided impl of XfrDataProvider does this because it's a local policy decision and so you should implement XfrDataProvider yourself, the existing impls do not restrict access at all.

I have a proof-of-concept impl that does restrict access that was never released, there's still a version of it in Git history, I'll try and find it.

There isn’t an out-of-the-box simple Middleware Service impl that does just checking for a key, but your actual application Service impl could also do it in the same way by examining the Option<Key> received via RequestMeta (but this is only relevant in the case that you are not using the provided XfrMiddlewareSvc).

[ximon18]

See:

domain/src/zonemaintenance/maintainer.rs

Line 2152 in b61d08f

impl<KS, CF> XfrDataProvider<Option<Key>> for ZoneMaintainer<KS, CF>

It might be a bit overwhelming as there's a lot going on in that code. It was never properly finished or reviewed but was tested locally with an NSD both acting as a primary and also in a separate test acting as a secondary, so it's not beautiful but it works.

[ximon18]

Hi @pusateri,

The attached patch against the main branch of domain shows how to do this by modifying examples/serve-zone.rs.

I hope that helps.

Ximon

refuse_unsigned_xfr.txt

---

Update: Note that you can also check that only the expected TSIG keys are used, not just that some TSIG key was used.

[pusateri]

Fantastic. This works for me. Thanks!

[ximon18]

Great!

@pusateri: Do you think the documentation needs improving (for this scenario) and if so do you have any suggestions as to what to change or add?

Ximon

[pusateri]

No, updating the example code should be sufficient.