On 2017-01-16, Damian McGuckin <dami...@esi.com.au> wrote: > Sorry, lots of good ideas got thrown up while I was asleep. > >>> Which code, the 'dig' side or the daemon sucking on the port? I probably >>> need to discuss this over a beer because there must e something I am >>> missing. > > On Mon, 16 Jan 2017, Stuart Henderson wrote: >> The dig side. Pledge restricts what a process is able to do (killing the >> process if something other than this is attempted), so any bugs in dig >> causing it to do something other than the expected would trigger this. >> Since DNS packet parsing is rather complex and is by definition working >> on untrusted network input, > > Understood. That still does not negate my need for a utility to suck on > any port and 'grok' DNS-speak. Whether it is dig or anything else, I do > not care. But a tool which enables you to test/debug a program on a > non-standard port, whether it be for DNS, or whatever, is a key part of > our toolkit.
Yes, I'm not arguing with that. Just trying to show why it's how it is for the version of dig(1) in base, and giving an alternative.
