On 2017-01-16, Damian McGuckin <dami...@esi.com.au> wrote: > On Mon, 16 Jan 2017, Stuart Henderson wrote: > >> On 2017/01/16 15:37, Damian McGuckin wrote: >>> On Mon, 16 Jan 2017, Stuart Henderson wrote: >>> >>>> In normal operations NSD _does_ run on port 53. >>> >>> Yes. But if you want both NSD and UNBOUND running on the same box, things >>> need to change. >> >> Not necessarily, because they can run on different addresses. For >> example you could have unbound bound to an internal address and NSD >> listening to an external one. > > I am not an NSD/UNBOUND expert, but > > If you run NSD on the external link (pppoe0) and that external link does > not come up, as when the external (ADSL) phone link is down, anything that > NSD is handling for the internal machines in the network is unavailable. > So it needs to run off an internal interface.
In that case, unbound bound to an internal address, and NSD not bound to a specific address, or bound to external and 127.0.0.1. >>> I thought the whole idea of using NSD/UNBOUND is to avoid installing >>> 'isc_bind'. >> >> Well, the tools you're using for this are part of BIND... > > Yes, under sufferance. I looked at 'drill' but it looked like too much > work. Long term, might be a great idea as Craig Skinner suggests ... > > Could NLnetLab's libldns & drill totally replace all this? If drill was added to base it would most likely be pledge(2)'d as well. >>> I still cannot see what risk there is on qujerying a DNS on a >>> non-standard port. Enlighten me please? >> >> None, if that's what you are expecting to do. >> >> Plenty, if the code has been subverted to make an unexpected network >> connection. > > 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. 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,
