Provide a means for a user to manually diagnose a response from the server.
An earlier version of this ticket described a dedicated API, but a better solution would be to just embed the info (filter name + linenum) in the DNS response itself. In practice just using dig is probably more intuitive for anyone trying to diagnose a DNS server, whereas a separate API is going to be annoying for me to document and provide reference clients, and for users to discover when they're just trying to see why a domain doesn't work.
For example maybe we could stuff it in the SOA resource? Or add an Additional TXT resource with the info? Need to check what the RFCs say is allowable in an NXDOMAIN response.
Going with including an Additional TXT resource. For example:
$ dig @127.0.0.1 -p 5353 test-blocked.kapiti.io ; <<>> DiG 9.16.15 <<>> @127.0.0.1 -p 5353 test-blocked.kapiti.io ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49683 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 4c0bdcd19d757980 (echoed) ;; QUESTION SECTION: ;test-blocked.kapiti.io. IN A ;; AUTHORITY SECTION: test-blocked.kapiti.io. 300 IN SOA test-blocked.kapiti.io. kapiti.test-blocked.kapiti.io. 42069 300 3600 259200 300 ;; ADDITIONAL SECTION: test-blocked.kapiti.io. 300 IN TXT "hardcoded" # or could be e.g. "http://example.com/filter.txt:1234"Need to test this with a couple clients and make sure that they aren't unhappy about the extra TXT record. If there are issues then this might just be a WONTDO.