O assassino da OOM é uma amante inconstante. O BIND está sendo segmentado porque é considerado o melhor alvo pela lógica do assassino da OOM. Está bem explicado no comentário do código na página vinculada, mas é preciso colar:
/*
* oom_badness - calculate a numeric value for how bad this task has been
* @p: task struct of which task we should calculate
* @p: current uptime in seconds
*
* The formula used is relatively simple and documented inline in the
* function. The main rationale is that we want to select a good task
* to kill when we run out of memory.
*
* Good in this context means that:
* 1) we lose the minimum amount of work done
* 2) we recover a large amount of memory
* 3) we don't kill anything innocent of eating tons of memory
* 4) we want to kill the minimum amount of processes (one)
* 5) we try to kill the process the user expects us to kill, this
* algorithm has been meticulously tuned to meet the principle
* of least surprise ... (be careful when you change it)
*/
Mas isso apenas informa por que ele segmentou o BIND. A solução provavelmente não é "conseguir para alvejar outra coisa", já que qualquer outra coisa que esteja sugando muita memória provavelmente também é importante. É mais provável que a solução seja "não acione o killer da OOM".
Você pode aumentar a memória ou o espaço de troca disponível para este sistema ou diminuir a memória usada por outros processos? O que mais está sendo executado neste sistema? O BIND é configurado como autoritativo ou recursivo (o que permitiria limitar o uso da memória cache)?