In order to provide better filtering info, Kapiti could redirect filtered domains back to Kapiti itself, which would then run a stub web server that returns a nice "this has been filtered" page to all requests. Meanwhile the same web server would route requests for e.g. <listen IP> or dashboard.kapiti.io to the internal dashboard.

Via this block page, the user could see what filter caused the request to be blocked (in addition to reading DNS responses as covered by #20), and Kapiti could keep metrics on how many HTTP connections are being made to blocked domains. Kapiti could be configured with other TCP/UDP ports to listen on, so that it could track other protocols - but this would be an advanced feature since it risks issues with other legitimate services on the same machine that want to listen on those ports.

This would make sense as an optional feature, where the alternative would be the current NXDOMAIN behavior.