HELP: Decomissioning a DNS anti-spam list

[Jim Reid]

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

    >>  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.

    Ronald> Forever?

No. For at least as long as the service exists and people want to use
it. Plus a reasonable time afterwards to allow for graceful failure
for those who haven't yet realised the service has gone away. As an
analogy, consider how VHS tapes and players are still around even
though the video market has overwhelmingly switched to DVD.

    Ronald> In short, do you ever even think about what you are saying
    Ronald> and/or the implications thereof?  

Of course. I generally give more thought to a posting than it seems
you ever did to your anti-spam blacklist service.

    Ronald> Do you realize how ridiculous what you just said is?

It's only ridiculous to you. People can draw their own conclusions
about that.

    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> My name server understood them just fine.

No it didn't. Your name server may have loaded a zone containing the
above RR. It is syntactically valid after all. But that doesn't mean
the name server understood it. Or that the semantics of a wildcard NS
record are understood. If you believe they are, please enlighten me.

    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.

    Ronald> Well, I am even more convinced now than I was when I asked
    Ronald> that question that it is.

If you don't like the DNS, feel free to stop using it. And stop
posting absurd assertions that are untrue. [If the DNS was as
ill-conceived as you claim, the internet could not exist as it does
today because it wouldn't have had a scalable, distributed and robust
lookup system.] Or if you want to be constructive, propose an
extension to the DNS protocol and take it through IETF.

    Ronald> There is no established mechanism or protocol in DNS to
    Ronald> say ``This (sub-) domain no longer exists.  Go away now,
    Ronald> and don't ever ask me for any more information about it,
    Ronald> ever.'' You may not view that as problem, but I do.

I view your lack of understanding about how DNS works and how to
provide DNS infrastructure as problems.

Just think about what you've said above. Suppose this facility did
exist. This would make it effectively impossible for new domains to be
added. ie Before you registered monkeys.com the world's name servers
would have been told that this domain didn't exist and to never query
for it again. So nobody that looked up monkeys.com before you
registered it would ever see your domain name. Likewise, clients would
be unable to resolve the new gTLDs ICANN has created in the last 2
years. Or... And that's before we get into solving the problem of
maintaining potentially infinite amounts of state information forever
on the name servers. Or preventing this hypothetical facility being
misused for nasty DoS attacks.

Your suggestion is predicated on the assumption that the DNS name
space is static. That's absurd. This is why DNS data has a TTL value.
Caching can save DNS traffic and resolving times. But the cached data
has to expire in case the original data changes. It can't live forever
unless the internet agrees to never rename or renumber anything.

Suppose this "don't ask me for this name ever again" feature existed
and you used it to sort your self-inflicted operational problem. So
far, so good. Later on you decide to re-introduce your anti-spam
blacklists. [Let's assume you have a change of heart or somebody
provides funding.] But now, nobody's name servers could lookup
relays.monkeys.com or whatever because you'd already told them to
never, ever lookup that domain name again.

    >> 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.

    Ronald> That's all true, and yes, there's no real way to totally
    Ronald> expunge all mentions of a given (sub-)domain name from the
    Ronald> whole Internet.  However given that THAT problem exists,
    Ronald> and is unavoidable, the real problem is that the DNS has
    Ronald> no way... clean or otherwise... of decomissioning domains
    Ronald> and/or sub-domains (or zones or sub-zones) in a way that
    Ronald> mini- mizes further queries against those domains or
    Ronald> zones.

So what? Although caching helps, the DNS has no mechanism to minimise
queries for names that do exist either. It's only a lookup protocol. If
you want rate limiting, do that in your routers. That's the best place
for this to be done IMO, not in an application protocol. To repeat
what I said earlier:

    You can't do anything to stop the rest of the internet making
    queries for these domain names.

If you'd done things properly from the outset, you would not have got
yourself into your current predicament. You'd have used a different
domain name for the anti-spam stuff (not subdomains of your personal
domain), put that on different name servers and made sure that they
had enough bandwidth to cope with large query rates that an anti-spam
blacklist would be expected to get. You did none of these things. So
you made three elementary mistakes and then blame the DNS protocol for
the problems you've created for yourself? Sheesh! This is a bit like
deliberately driving a car into a wall and then blaming the car's
designers for including a steering wheel.