HELP: Decomissioning a DNS anti-spam list

[Jim Reid]

>>>>> "Ronald" == Ronald F Guilmette <rfg at monkeys.com> writes:

    Ronald> As some of you may know, up until last September, I ran a
    Ronald> couple of DNS-based anti-spam lists.

    Ronald> The problem is that no matter what I do, I cannot seem to
    Ronald> stop the ongoing torrent of queries against the zones,

Indeed. It's kind of difficult to make the rest of the internet do
what you want. :-)

    Ronald> I have _very little_ bandwidth at my disposal, and now I
    Ronald> need to reclaim that bandwidth for other purposes.  But
    Ronald> these ongoing queries are sucking up more than half of the
    Ronald> meager bandwidth that I have.

Tough. You made your bed. Now you have to lie in it. If you start a
some service, it's your responsibility/problem to provide sufficient
resources to support the demand for that service. This can mean keeping
stuff alive long after the service is no longer in use: for instance
whenever a company changes its name.

    Ronald> Now I am trying the following NS record:

    Ronald> *.relays.monkeys.com. IN NS localhost.monkeys.com.

This won't work. I doubt if anyone understands what a wildcard NS
record means.

    Ronald> So can anybody help me with this?  There has GOT to be
    Ronald> some way of de- commissioning a zone such that further
    Ronald> queries against the zone will not be a huge burden on _my_
    Ronald> bandwidth.  I just need somebody to tell me what it is.

Either get more bandwidth or bring in someone who has got enough
bandwidth to host your DNS zones.

    Ronald> Or is this impossible?  Is the design of the DNS protocol
    Ronald> so ill-conceived as to make this kind of decomissioning
    Ronald> impossible?

The DNS is not ill-conceived. However your understanding of the DNS
seems to be ill-conceived, especially how to go about switching off an
unwanted domain name. 

You can't do anything to stop the rest of the internet making queries
for these domain names. You just have to live with this. What you
could do is just delete everything under relays.monkey.com (or whatever),
including that name. This will mean any queries for these names will
get an NXDOMAIN response. If the servers that made those queries
implement negative caching -- "remember this name doesn't exist for a
while" -- this should shut them up. They'll maybe only query your
servers once every few hours instead of every few seconds. That will
reduce the amount of DNS traffic you get. But it won't make those
unwanted queries go away. You're pretty much stuck with those until
the rest of the internet stops trying to use your now dead anti-spam
blacklists. This is something you should have thought about before you
started to offer that service.

You could "delegate" relays.monkeys.com to localhost.monkeys.com. ie:

	relays.monkeys.com.	2592000 IN NS localhost.monkeys.com.
	localhost.monkeys.com.	2592000 IN A  127.0.0.1

This would make your name servers return a referral to the loopback
interface. A long TTL would be good too. So servers looking up
something.relays.monkeys.com would get a referral to the loopback
interface and be made to remember that for a long time. They'd then
try to resolve something.relays.monkeys.com by querying themselves.
Obviously this would fail and the resolution would then terminate
locally. And those servers would only be querying the monkeys.com once
every TTL-value (30 days in the RRs above) rather than once every few
seconds. 

Another option would be to get the delegation for monkeys.com changed.
You could point this at non-existent name servers. This would also
mean that monkeys.com would disappear from the internet. Only you can
decide whether that is less painful than having unwanted queries for
monkeys.com hitting your name servers and guzzling your bandwidth. If
the bandwidth problem is as bad as you claim, monkeys.com may already
be close to disappearing from the internet anyway.

You've painfully learned an important lesson. Domain names last
forever. They live in places like search engine databases, browser
bookmarks, address books, stationery, software configurations and so
on long after the names are supposed to have died.

BTW the problem you've now got is one of the reasons why most big
internet operations separate the domain names and infrastructure used
for service delivery to customers from the stuff that's needed by
employees for routine operations. If Something Bad like a DoS attack
happens to one, the other can continue untroubled.