Curing the BIND pain

Thu Mar 27 09:32:34 UTC 2003

Let's assume that BIND has a way to know when it is dangerously out of 
date. The mechanism used would be up to ISC and I'll admit that it would 
probably involve some sort of DNS records in an ISC-run domain because 
that's the only way that has a high likelihood of working  given the 
number of firewalls and caching nameservers that may be between a given 
BIND box and ISC. Seems to me that ISC has always maintained that there 
are two version numbers, one 4.x and one 8.x, that are always the oldest 
ones you can run and still be secure against known exploits. So the info 
stored in the ISC DNS server really doesn't need to be more than those two 
version numbers.

OK, now assume that we have a BIND server which has detected that it is 
out of date and at risk of attack. What should it do?

Well, first of all, what would a human being do if if realised that it was 
at risk of attack and they had no means of contacting their friends or the 
police. A child might cry out and an adult might yell for help in case 
someone was near enough to hear. BIND is in a similar situation. It 
doesn't know if there is anyone looking after it but it is hurting, so 
let's make it cry out.

I suggest that an appropriate technique would be for the BIND server to 
originate traffic on it's local subnet that would look suspicious and 
possibly trigger intrusion alarms. Send out some packets to the broadcast 
address. Do some portscanning of all addresses on the subnet. Find any 
open port 80 and retrieve a URL containing 
BIND/server/at/10.7.7.1/has/security/vulnerability, find any open port 25 
and send email to postmaster containing the same message, etc.

Not enough traffic to be a DoS but enough to show up in various logs in 
case someone is looking at some of them.

Even then, this is still a string and sealing wax solution. It's 
situations like this that demonstrate just how primitive our supposedly 
high technology really is. 

--Michael Dillon