I know Matthew hadn't updated the zones in quite some time but perhaps I
missed his announcement for people to stop using them.

--Mike

From the web site:

------------------------

"Greetings

The listing services that used to be part of BLACKHOLES.US is no longer
alive.

The IP address space that they used for name servers now belongs to
another, unrelated entity.

We would like to use our space without the tens of thousands of DNS
queries per second coming to us.

So it would be MOST USEFUL if you or your email administrator would
REMOVE any reference to blackholes.us from your anti-spam system.

There is no LIST REMOVAL service. The "removal" process is simple, DO
NOT USE the BLACKHOLES.US domain for your filtering or anti-spam system.

All email will be ignored.

All LEGAL threats will be ignored as they are without merit. We are NOT
causing any blocking. YOU or your ISP, Admin, etc are freely choosing to
make queries against our site, without our invitation or approval, for
data that is no longer valid. REMOVE IT and your problems will go away.

Good Email admins should have removed this 2 years ago, when the service
went down. Only LAZY admins are feeling the pain of their laziness.

ALL ACCESS OR ATTEMPTS TO ABUSE ARE BEING CLOSELY WATCHED AND LOGGED.

Anyone running a public DNSBL list service should have the moral
fortitude to plan at the start to donate the domain name along with
the costs of bandwidth and computers to the cause.  When you decide
to stop paying costs of running the DNSBL, you should pull the plug
on the domain name.  Contrary to the lies or expressions of gross
incompetence seen in similar contexts over the years, it is easy
to do that without any additional costs for bandwidth.  Simply
change the DNS glue for the domain name to something bogus.  To
save the bandwidth of the roots, use very long TTLs.

Of course, contrary to related lies or expressions of gross
incompetence, the costs of bandwidth to continue answering queries
to your old DNSBL with NXDOMAIN are trivial.  If you don't know how
to publish long TTL'ed NXDOMAINs or use a firewall or other mechanism
to publish silence, you have no business starting the hobby.

http://www.blackholes.us/ says in part:

] The IP address space that was used for BLACKHOLES.US's name servers
] now belongs to another, unrelated entity.
] We would like to use our space without the tens of thousands of DNS
] queries per second coming to us.

and

] ALL ACCESS OR ATTEMPTS TO ABUSE ARE BEING CLOSELY WATCHED AND LOGGED.

The first bit claims that blackholes.us is still being used to
filter about 1 billion mail messages per day.  That seems unlikely.

If the first bit were true, would the second be be plausible?
Sifting logs of more than 1 billion IP packets per day for evil
that is probably absent and even more likely harmless is not a
trivial task.  Under the circumstances, you'd have to be either
incompetent to detect any evil packets or a raving loon with paranoid
delusions of grandeur to even consider the task instead of just
turning off the domain name.

That web site betrays such gross incompetence for running a DNSBL
that it reflects poorly on anyone who chose to use the DNSBL.  To stop
all traffic toward 216.243.118.0/24 until the domain name registration
expires, one would need only change the NS records for blackholes.us
to specifiy two authoritative servers, such as ns5.BLACKHOLES.US and
ns6.BLACKHOLES.US, and then publish glue A RRs for those two names of
127.0.0.1 and 10.0.0.1.  One NS RR and matching glue would be enough,
but perhaps the registrar has rules about DNS diversity.
For that matter, if the registrar allows, you might simply delete all
glue and perhaps even the NS for BLACKHOLES.US,
after publishing a 127.0.0.1 NS+A for a month.  
(scarlatti.shakha.com has a long TTL of ~1 month.)

http://www.whois.us/

There needs to be a DNSBL reply that says "not in operation"
etc.  But then that would require _all_ systems to understand
that type of reply.

  e.g. 2.0.0.127.dnsbl.example.com -> 127.0.0.1
       1.0.0.127.dnsbl.example.com -> 127.0.0.1

There's no shame in not knowing how to run a DNSBL, but there is plenty
of shame for those who trumpet their wonderful stuper duper spammer
'nad malleting DNSBLs without caring that they lack fundmantal clues.

As I recall, the first person who half a dozen years ago shut down his
DNSBL with consistent 127.0.0.2 answers offered as justification an
implausible story about a DDoS attack on his BRI.   An ISBN basic rate
interface is good for only 56 or 64 Kbit/sec or about 8 KByte/sec or
about 50 DNS/UDP/IP requests/second or 4 million requests/day.  Even
then anyone who didn't have enough bandwidth to handle more than 50
requests/second was incompetent as a public DNSBL operator and so were
and are those who make non-trivial mail systems dependent on such tools.

Note that 10K requests/second at the typical DNS request size of about
120 bytes is 12 Mbyte/sec or 100 Mbit/sec or 1000 GBytes/day or 30,000
GBytes/month.  Did blackholes.us ever seen that much traffic?

Again, what's wrong with NXDOMAIN?  Not only for 1.2.3.4.dnsbl.example.com
but dnsbl.example.com and probably example.com?  That fails with clean
"not listed here" answers and can be done with practically no bandwidth.

That is not what the DNSBL operator has in mind.  What he wants is a
quick shutdown of an operation he no longer likes.  He hopes that
sending a 100% false positive ratio will cause so much trouble for
his valued clients that they will quickly disconnect.

The convenient thing about this is that it works whether the DNSBL
admin:

- deliberately lists 127.0.0.1 as a warning
- deliberately lists 0.0.0.0/0 as a "Get off my F'n DNS!"
- lets his domain go dead and its picked up by a domainer.

You want the admin to deconfigure the DNSBL if it goes offline, not
just keep querying it and getting useless results.

If you don't get them to deconfigure the DNSBL, then the DNSBL operator
_has_ to keep paying for the domain in perpetuity.

If you can't get them to stop querying the DNSBL and take steps (such
as described by the BCP mentioned below) the whole domain often
becomes unuseable.

Furthermore, a DNSBL domain that goes dead and the domain given up is
almost certain to be picked up by a domainer, who'll immediately stick
in a wildcard A pointing at his "this domain for sale" site.  Which means
that all of those sendmail implementations you referred to (that don't
bother checking the A records for specific values) will be blocking
the world.

Which is why you need to get admins to stop querying it.  Without
listing the world.

There's a more complete decommissioning process in

http://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists-05

That combines the elements of the 127.0.0.1/2 returns and provides
a way by which you can eventually get most people to deconfigure
the DNSBL without disrupting any email.  See sections 3.3 and 3.4.

I'm not happy with making the domain "registered indefinitely" a
"SHOULD", but in the face of DNSBLs domains going away completely,
there is no other way to make 100% certain it's won't start blocking
the world one day...

Yes, I know that both Levine's DNSBL RFC and my DNSBL BCP are expired
drafts.

The RFC hit IETF last call, but the Dean Anderson wannabees turned
the discussion into a horrible mess that the RFC sheepherders decided to step
back from.  Even tho the RFC is just documenting an existing protocol
and nothing more.  We did make some progress with some of the fence
sitters, but it wasn't enough.  It was decided to not try with the BCP
given the reaction to the RFC.  I think we're going to try "publishing"
some other way.  But I haven't heard anything recently on the idea.
--
Chris Lewis,

So pulling the plug on the domain is _not_ the answer.  It's just
abdicating the question whilst strewing landmines for the unwary.

We're seeing something like 2-3 million unique IPs per day out of
a rolling total of perhaps 10-15 million per week, where the average
number of hits from each bot-detected IP is on the order of 10
per week.  A week TTL on NXDOMAIN just reduces DNSBL queries of that
particular IP by a factor of 10 over a zero TTL (and that's assuming
that your dns cache will cache that many entries!).  If the DNSBL is seeing
10,000 queries per second, at most they've reduced the queries
by a factor of 10.  Which isn't enough in some cases, like some home
user picks up this cute new domain name for hosting his hobby web
site on his ADSL link without realizing what's out there waiting
to stomp him flat.
--
Chris Lewis,

1.  Change the relevant protocol to require resolvers to count the
number of times a server was unresponsive and if the count ever reaches
some threshold to stop sending inquiries to that server.  Log file
reviews (admins do review log files, right?) should be sufficient to
find cases where a server was marke dead in error.

2.  Some kind soul start up a server that knows when a black list server
is active and change the protocol to always check the new server (every
time? once a day?) to see what black list servers are active.

I'm guessing that the "Network Neutrality" thing will 4render the point
moot.
--
Requiescas in pace o email              Two identifying characteristics
                                              of System Administrators:
Ex turpi causa non oritur actio        Infallibility, and the ability to
                                              learn from their mistakes.
Eppure si rinfresca

A better broken flag might be NODATA or something that results in
SRVRFAIL such as a timeout or glue that points to 127.0.0.1, an RFC
1918 address, or a IANA test network.  See RFC 2308, perhaps at
http://www.ietf.org/rfc/rfc2308.txt?number=2308

Or do the obvious and standard, and don't put the DNSBL at the top
level.  If the DNSBL is of the form 4.3.2.1.dnsbl.example.com, then you
need only break dnsbl.example.com, while continuing to use example.com.
Even if you bought example.com only to use for DNSBLs, if you probably
have names like www.example.com to answer questions, smtp.example.com
for delisting requests, ns*.example.com, etc. besides dnsbl.example.com.

5 years of a "sorry but this DNSBL is dead" web page on www.example.com
would make you look more competent to prospective employers or customers.
Anything like the stuff on http://www.blackholes.us/ is a red flag to
anyone who considering dealing with you.

The "DNSBL still alive" signalling in secion 3.3 is useless for
anyone who might use it, because anyone competent enough to care
to use it would already be doing regular checks of the effectiveness
of the DNSBL and so would notice any reasonable shutdown, whether
because it stopped listing anything and so became a waste of bandwidth
or because it is shut down, such as by section 3.4.

That particular ID is too much ill consider officious fussiness and
not enough non-trivial substance.  Section 3.3 is emblematic.
That "this DNSBL should be considered non-functional" signal (love
the bureaucratic wording) is irrelevant except for poor mail system
operators who won't use it.  More than that, the name DNSBL signalling
is not a good choice, precisely because _DNSBL_.test is an invalid
DNS name.  If I ran a name DNSBL, I'd probably list *.test as well
as *.dnsbl.example.com itself, *.arpa, 127.0.0.1, and 1.0.0.127
probabl by 512 records and wildcards like *.127.dnsbl.example.com.

The last paragraph of section 3.3 is wrong, because  Spamhaus has
too long been publishing answers that in practice have "opposing
or widely different meanings."

If your SOA, NS, and referal A RRs for dnsbl.example.com have TTLs
of 30 days, the your DNS server for example.com should see only one
query per month per DNSBL client.  If 10 million mail systems are
using your DNSBL, your DNS server will see only about one query
ever 4 seconds.  A more plausible number of client mail systems of
100K gives about 1 query per minute.

This is the new owner of IP space that blackholes.us used to occupy.
For some reason, Tucows refuses to stop listing this address space as
belonging to blackholes.us.  The new owner of the IP space wants the
5000 queries/second to stop.

In a sense, he's being ddos'ed by Tucows.  If he could get Tucows
to drop the bogus dns listing, he'd be satisfied.  But they won't,
so he's doing what he can to light fires under the admins who should
have stopped using blockholes.us months ago, but didn't.

It's not an ideal solution, but I'd be curious to know if someone
has a better idea.

The new owner of the IP space is not the new owner of blackholes.us,
and is frustrated that he can't get the plug pulled.

Some of the statements that have been made have given me doubts.
5000 queries/second is almost as implausible as 10,000 queries/second.
5000 queries/sec * 120 bytes/query = 640,000 Byte/sec = 5 Mbit/sec.
It also implies that half a billion mail messages/day are being checked.
So you believe 5000 queries/second?  I don't, and not just at least
until recently http://www.blackholes.us/ was claiming twice as much.

Notice first that by using using a wildcard of 127.0.0.2 on blackholes.us,
they are increasing the damage themselves.  Simply answering NXDOMAIN
for a parent name would leave only about 1 query/hour/DNSBL client/DNSBL
zone, because each DNSBL client would stop asking for the lifetime of
cached NXDOMAIN entry for the parent domain.  But this is how they're
shooting their feet:

    1.1.2.3.4.blackholes.us. 28800  IN      A       127.0.0.2

    ;; AUTHORITY SECTION:
    blackholes.us.          3355    IN      NS      NS5.blackholes.us.
    blackholes.us.          3355    IN      NS      SCARLATTI.SHAKHA.COM.

    ;; ADDITIONAL SECTION:
    NS5.blackholes.us.      3355    IN      A       216.243.118.35
    SCARLATTI.SHAKHA.COM.   161907  IN      A       216.243.118.34

Judging from http://web.archive.org/web/20021127022153/http://blackholes.us/
the blacklists were under subdomains such as argentina.blackholes.us
That implies that whoever now owns 216.243.118.34 and 216.243.118.35
could do any of the following instead of the 127.0.0.2 wildcard they
are currently using to shoot themselves:

  - contact Tucows from the official IP addresses of blackholes.us and make
     the necessary changes.  The new owners of the IP addresses might
     not have the passwords needed modify the registration, but they
     could put up an SMTP server (mail receiver) on smtp.blackholes.us
     and go through the lost password dance.

  - contact Tucows with threatening legal noises, complaining about
     "being ddos'ed by Tucows"

  - use wildcards to publish SOA, NS, and referal A RRs to send DNSBL clients
     to 127.0.0.1 for argentina.blackholes.us etc.

  - use wildcards to publish NODATA records with very long TTLs (not just
     8 hours or 28800 seconds) NODATA records for argentina.blackholes.us
     and the other parent domains

  - ensure that argentina.blackholes.us and similar answer NXDOMAIN
     and that the TTL in the SOA is large

  - get creative with DNAME to refer queries to Spamhaus, APEWS, or some other
     DNSBL

The new owner of the IP space seems to have made an appearance,
but the owner of blackholes.us appears AWOL.

The DNSBL BCP proposal suggests pointing the NSes at 192.0.2.0/24
(IANA TEST-NET).  The goal is to have the IPs aim at space that
can never answer, preferably doesn't hit the Internet, and hopefully
should take some time not getting there.  The competition was loopback
(127.0.0.0/8), but the DNS people I consulted thought that TEST-NET
would likely be better in some unusual cases.

What's "better" ends up depending on edge-case idiosyncrasies of
individual DNS packages, networking infrastructure equipment and
OS internals.   Eg: apparently some OSes do weird things with
127/8 traffic (other than the 127 IPs we usually see).

The DNSBL BCP's proposal "works" when the DNSBL queries are rooted
at least one level below the domain (eg: dnsbl.example.com, not
example.com).  blackholes.us isn't that way, and this would work
better:

    0.blackholes.us. 604800 IN NS u1.blackholes.us.
    1.blackholes.us. 604800 IN NS u1.blackholes.us.
    2.blackholes.us. 604800 IN NS u1.blackholes.us.
    ...
    254.blackholes.us. 604800 IN NS u1.blackholes.us.
    255.blackholes.us. 604800 IN NS u1.blackholes.us.
     u1.blackholes.us. 604800 IN A 192.0.2.1

You could eliminate some of the prefixes that are rarely (if ever)
queried for (eg: 224-239).

you could add more u1.blackholes.us A records in the rest of
192.0.2.0/24, but this wouldn't necessarily work to slow down
the cache.

dsbl.org has shut down this way.  Try doing a dig on "list.dsbl.org",
notice the timeout.  Then, to find out why, run a dig +trace, and notice
the last NS name evolved - stop-using-dsbl.dsbl.org, then do a dig
on the A records for that...

There's a few others that have shut down that way and seems to work
fairly well.

The owner of the IP range is trying to seize control of the blackholes.us
zone to get it pointed elsewhere.  But that really is just deferring
the problem, the registrar is somewhat reluctant and the reseller is
AWOL.  I've been told that they intend to try something like the above
shortly.
--
Chris Lewis,

Instead, to figure out 4.3.2.1.dnsbl.example.com, the local resolver
first asks the root for SOA, NS, and A resource records for com.  Using
those 3 RRs, the resolver asks a server for com about example.com about
SOA, NS, and A RRs for example.com, and so on until it can finally ask
a server for 3.2.1.dnsbl.example.com about 4.  Many of those questions
starting with com are usually answered not by sending packets through
the Internet but from the local cache that contains previous answers
to the same questions.

Consider what happens when an intermediate level such dnsbl.example.com
is not defined because of a typo, registration expiration, or any other
reason.  The first time the resolver tries to get SOA, NS, and A RRs
for dnsbl.example.com, it will send a request to a server for example.com,
get NXDOMAIN, store the negative result in its cache, and announce that
4.3.2.1.dnsbl.example.com is also not defined (NXDOMAIN).  It obvious cannot
and does not send any additional packets anywhere before that announcment.

If the application then asks for 8.7.6.5.dnsbl.example.com, the cached
answers for com, example.com, and dnsbl.example.com will be used.
However, since that saved answer for dnsbl.example.com is NXDOMAIN, the
result for 8.7.6.5.dnsbl.example.com will also be NXDOMAIN and against
without any sending packets any additional packets anywhere.

That instant, no-traffic result happens when any undefined level his
hit a second time before its negative cache entry expires.  If
3.2.1.dnsbl.example.com is the first undefined name, then a query for
5.3.2.1.dnsbl.example.com after a query for 4.3.2.1.dnsbl.example.com
will take no network traffic.  If example.com is not defined, then all
queries for anything at or below example.com will take no traffic.

That way, they'll not have to be so aggressively antisocial with the
bogus answers they're currently providing.

Richard

--
To reply via email, make sure you don't enter the whirlpool on river left.

The usual countermeasure for a dDoS to a target that won't move (or where
the agents won't retarget) is to have upstreams null route (or filter out
with ACLs if they have extra beefy sup cards) the inbound dDoS traffic
before it ever hits the customer bandwidth.  BTDTGTTS.

Richard

--
To reply via email, make sure you don't enter the whirlpool on river left.

I cannot believe that a registrar would tolerate incorrect NS data in
their registrations, especially when it is pointing to some else's space.

But of course the ownership of the 216.243.118.34/35 addresses is not
registered in whois.  Only the block they were allocated from is
registered to the ISP.  That usually means trouble.