~nickbp/kapiti#20: 
Include human-readable filter info in NXDOMAIN response metadata

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.

Status
RESOLVED FIXED
Submitter
~nickbp
Assigned to
No-one
Submitted
5 months ago
Updated
5 months ago
Labels
Next

~nickbp referenced this from #32 5 months ago

~nickbp referenced this from #17 5 months ago

~nickbp REPORTED FIXED 5 months ago

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.

Register here or Log in to comment, or comment via email.