Coping with inappropriate recursive queries to a nameserver

Mon Apr 21 22:17:24 PDT 2003

I'll grant that my home network isn't a "large" installation, but I
would expect that this issue would arise in them, and wonder what --
if anything -- can be done about it.

By virtue of lucky timing, I got a static IP address when I signed up
for DSL.  And since I have that address, I operate various servers that
are "visible" there, including the master (externally-visible) name-
server for catwhisker.org.

Since that ameserver needs to be able to be queried from the "outside
world," I also provide slave nameservice for a handful of other zones.

So far, so good.

However, I have no desire to provide information about zone for which my
nameserver is not authoritative (i.e., recursive queries), except for
hosts on one of my internal networks.

Accordingly, in the "options" stanza for named.conf, I have:

        allow-recursion {
                127.0.0.1;
                172.16.0.0/15;
        };

in order to enforce that.  (I have the 172.16.0.0/15 space split in
half, with 172.16/16 for the "trusted" network and 172.17/16 for a
"guest" network.  The latter is where the wireless access points go, for
example.)

And as a result of this, I see (during my daily review of the logs)
messages such as:

Apr 18 13:38:34 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for mail129.mail.bellsouth.net IN
Apr 18 13:38:44 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 69.58.152.205.in-addr.arpa IN
Apr 18 13:39:56 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 69.58.152.205.blackholes.mail-abuse.org IN
Apr 18 13:40:11 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 69.58.152.205.dialups.mail-abuse.org IN
Apr 18 13:40:16 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 69.58.152.205.blackholes.mail-abuse.org IN
Apr 18 13:40:24 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 69.58.152.205.relays.mail-abuse.org IN
Apr 18 13:40:31 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 69.58.152.205.dialups.mail-abuse.org IN
Apr 18 13:40:36 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 69.58.152.205.proxies.relays.monkeys.com IN
Apr 18 13:40:43 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 69.58.152.205.relays.mail-abuse.org IN
Apr 18 13:40:49 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 69.58.152.205.list.dsbl.org IN
Apr 18 13:41:01 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 69.58.152.205.relays.osirusoft.com IN
Apr 18 13:41:11 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for 38.238.200.80.in-addr.arpa IN
Apr 18 13:41:14 janus named[70668]: denied recursion for query from [65.179.65.233].32829 for jrcsdevelopment.com.dsn.rfc-ignorant.org IN

Now, on the one hand, it is somewhat gratifying that the configuration
is thus varified as doing what I want; on the other, the novelty has
worn off quite soome time ago, and I would prefer to encourage whoever
misconfigured the machine that was using the IP address 65.179.65.233 in
that interval to fix things, both to quit cluttering my log and to
improve any performance the machine in question might exhibit.

A "whois" query against the IP address shows that it's part of the
SPRINT-IPDIAL-2BLK netblock, allocated to Sprint, at 12502 Sunrise
Valley Dr., Reston, VA.  I tried writing to the listed contacts
(ip-req at sprint.net and NOC at sprint.net), but got nothing except the auto-
reply (as expected).

I've considered doing something such as just black-holing the IP
address(es) in question at my firewall (at least temporarily), but
I'm writing in the hope that one of my colleagues will have a
reasonably-effective approach that isn't quite so crude.

Thoughts?

I'll summarize private responses in about a week (or when I get a Truly
Elegant approach, whichever comes first).

Thanks,
david
-- 
David H. Wolfskill				david at catwhisker.org
Based on what I have seen to date, the use of Microsoft products is not
consistent with reliability.  I recommend FreeBSD for reliable systems.