Internal zones seem to prevent IDnsAuthoritativeRequestHandler apps from functioning correctly

[ruifung]

I've finally got around to trying to figure out why my LANCache app using IDnsAuthoritativeRequestHandler (that was previously suggested instead of IDnsRequestBlockingHandler) would not work for me and after some experiments, I've found it.

It seems that when there's a ROOT zone defined in the server, be it a secondary root zone or a root conditional forwarding zone with @ forwarding to this-server, it seems like the IDnsAuthoritativeRequestHandler is skipped entirely. This will likely also apply to any kind of zone that overlaps with the functionality of an IDnsAuthoritativeRequestHandler.

This is in direct contradiction to the stated behaviour in IDnsAuthoritativeRequestHandler.cs where it states that the apps are queried before the internal zone database.

I've tested this using the following setup:

1. A fresh T-DNS instance
2. Installed my LANCache-TDNS app, configuration set to Authoritative mode.
3. Test query for lancache.steampowered.com, results successful, the configured cache server is returned.
4. Set up a root conditional forwarder zone with @ FWD to this-server OR a secondary root zone
5. Test query for lancache.steampowered.com, results unsuccessful, it seems to return the upstream results.

Did some quick additional testing, it seems like this does indeed also affect the 'NX Domain' app too, definitely seems like it affects all IDnsAuthoritativeRequestHandler apps.

[ShreyasZare]

Thanks for reporting this issue. Will get it checked and fixed soon in the upcoming update.