BIND: limiting recursion just might make things harder for spammers

[Dmitry Kohmanyuk]

On Sun, Nov 17, 2002 at 04:19:25PM -0800, David Wolfskill wrote:
> I generally prefer to take "mere configuration" steps as "triage"
> for these sorts of things, and let things settle out for a little
> while (often, a day or two) before actually replacing code.  And
> in this case, I was planning to upgrade to a more recent snapshot
> of FreeBSD-STABLE today in any case (which I've done, as of this
> morning), so I figured that limiting recursion would probably be
> adequate for my case.  (Most of the exposure, as I understand it,
> was in the DNSSEC stuff, and I'm not doing that anyhow.)

	Not sure that FreeBSD -stable has latest bind since the 
	8.3.4 release promised last week as a remedy for this problem 
	only appeared on ftp.isc.org on today's night:

ftp> rstatus
211-isrv4.isc.org FTP server status:
     Version wu-2.6.1(5) Tue Jul 10 12:19:10 PDT 2001
...
211 End of status
ftp> pwd
257 "/isc/bind/src/8.3.4" is current directory.
ftp> ls
227 Entering Passive Mode (204,152,184,27,46,22)
150 Opening ASCII mode data connection for /bin/ls.
total 4420
-rw-rw-r--   1 10132    9996         362 Nov 17 05:35 MD5
-rw-rw-r--   1 10132    9996     1608657 Nov 17 05:35 bind-contrib.tar.gz
-rw-rw-r--   1 10132    9996         366 Nov 17 05:35 bind-contrib.tar.gz.asc
-rw-rw-r--   1 10132    9996     1490246 Nov 17 05:35 bind-doc.tar.gz
-rw-rw-r--   1 10132    9996         366 Nov 17 05:35 bind-doc.tar.gz.asc
-rw-rw-r--   1 10132    9996     1413654 Nov 17 05:35 bind-src.tar.gz
-rw-rw-r--   1 10132    9996         366 Nov 17 05:35 bind-src.tar.gz.asc
226 Transfer complete.

> After adding
> 
> 	allow-recursion {
> 		127.0.0.1;
> 		172.16.0.0/15;
> 	};
> 
> to the global "options" stanza for named.conf & telling named to re-read
> that file, I noticed that I was logging quite a few "denied recursion
> for query" messages.  (I use 172.16.0.0/15 for my internal networks, and
> the box that does the externally-visible nameservice has FreeBSD's ipfw
> set up to (among other things) block all traffic involving RFC 1918 nets
> on the external NIC.)
> 
> I rather wondered who would be trying to use my nameserver to get
> information about some domain other than one for which ns.catwhisker.org
> is authoritative, so I did a few WHOIS & DNS queries... and I started
> seeing names I have come to associate with spams that I've seen.  For
> example:
> 
> 63.178.112.154		sdn-ar-005nctarbP264.dialsprint.net
> 167.89.225.99		dsl-sj-167-89-225-99.broadviewnet.net

	you can enable query logging to see which names they are trying to resolve...
	but be careful - logs can fill up pretty quickly so I advice to either set up
	a separate logging channel for this (with size limit and rotation) or just
	do it for few hours.

On related note of BIND security, I found that using some unreachable host in
first field of SOA record helps to eliminate those annoying `denied update' messages
from win2k clients.  (I know it's not a perfect behaviour - but neither is using dynamic
updates by default.)  For example:

ua                  	SOA	updates-denied.kolo.net domain-master.nic.net.ua (
			2002111600	;serial (version)
			28800	;refresh period (8 hours)
			7200	;retry interval (2 hours)
			3024000	;expire time (5 weeks)
			86400	;default ttl (1 day)
			)