The OOM killer is a fickle mistress. BIND is getting targeted because it's considered to be the best target by the OOM killer's logic. It's explained well in the code comment on the linked page, but it bears pasting:
* 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)
But that only tells you why it targeted BIND. The solution probably isn't "get it to target something else", since anything else that's sucking up a lot of memory is probably also important. The solution is more likely to be "don't trigger the OOM killer".
Can you increase the memory or swap space available to this system, or decrease the memory used by other processes? What else is running on this system? Is BIND configured as authoritative, or recursive (which would allow you to limit its cache memory usage)?