Subject: DNS abuse handling/complaining strategies

From: Markus Stumpf <[email-masked]>
Date: Tue, 10 Dec 2002 12:31:36 +0100

Sorry if this is not fully on topic, but I couldn't find any documents
or a IMHO better place to ask.

We have the problem that your nameservers sometimes get flooded by queries
a) misconfigured DNS delgations
b) through broken resolver libraries

Currently this happens through
    0.138.20.68.in-addr.arpa.  2H IN NS  ns3.dns.space.net.
    0.138.20.68.in-addr.arpa.  2H IN NS  ns1.ameritech.net.
    0.138.20.68.in-addr.arpa.  2H IN NS  ns2.ameritech.net.
    0.138.20.68.in-addr.arpa.  2H IN NS  ns.space.net.

I don't know why Ameritech thinks two of our DNS server should be
AUTH for that netblock.

I have mailed the usual places (SOA contact, [email-masked]) more
than one time within the last 14 days but all I got back were robot answers.

We see a few thousands of queries per day. As the queries come from all over
the world we cannot simply block/filter them.

What would be the best strategy to get the problem fixed, i.e. misconfigured
delegation and non-responsive contacts?
- Add the zone and setup PTRs like we.are.clueless.ignorants.<isp-domain>
- Write the RIR (i.e. ARIN) and ask them to remove the delegation for
  20.68.in-addr.arpa? Would/should the RIR take (such) actions?

What are others doing?

Thanks,

	\Maex

P.S. Ameritech is not the only one causing this kinda problems. But the
     others usually react if one gets obtrusive enough.

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Peter Koch <[email-masked]>
Date: Tue, 10 Dec 2002 13:56:40 +0100

Hi,

>     0.138.20.68.in-addr.arpa.  2H IN NS  ns.space.net.

that domain is currently delegated "perfectly lame", i.e. none of the
servers is authoritative for it. In such cases, we set up a zone in
"self defense", giving clear contact info in the SOA RR and an additional
TXT RR. You may also wish to add a wildcard PTR (pointing to an existent
name) with a high TTL. Usually this should reduce the query flood.

-Peter

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 10 Dec 2002 14:22:36 +0100

> or a IMHO better place to ask.

NANOG or similar would probably suit you better. 

> What would be the best strategy to get the problem fixed, i.e.
> misconfigured delegation and non-responsive contacts?

Write the RIR. That is a good start. 

Other than that? AXFR the zone and start answering it. Then bill Ameritech
for secondary service. That ought to get wheels turning. 

If they do not let you AXFR, just do this:

#!/bin/ksh

#
# $Id: force-reverse-axfr.sh,v 1.1 2002/05/21 13:29:00 mansaxel Exp $
#
# Call with the zone name (eg "125.36.192.in-addr.arpa") as argv(1)
# Needs DiG v9. 
# 
ZONE=$1
D=0

echo "; for zone $ZONE"
# Do zone APEX. 
dig $ZONE SOA | grep ^$ZONE
# do bulk.
while [ $D -lt 256 ]  ; do 
        dig $D.$ZONE PTR| grep ^$D.$ZONE
        D=$(($D+1))
done 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.