From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1055b16f0708141428n23de86eckcfa60ae71cd9f60a@mail.gmail.com>
Date: Tue, 14 Aug 2007 17:28:52 -0400
From: "Artem Letko" <aletko@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] lsub.org
In-Reply-To: <b0c2991e320756486761b60282c548e5@coraid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <69fa321f47f8cfccff49107b70a28520@plan9.bell-labs.com>
	<b0c2991e320756486761b60282c548e5@coraid.com>
Topicbox-Message-UUID: a919164c-ead2-11e9-9d60-3106f5b1d025

something like that.

see http://www.ietf.org/ids.by.wg/dnsop.html

in particular http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt

-art

On 8/14/07, erik quanstrom <quanstro@coraid.com> wrote:
> on the dns front, i've found that some spam senders are
> arranging things so that the guys doing reverse-lookup
> validataion will get 192.168 or 10. addresses.  for some reason
> arin doesn't return an address for a query on 10.in-addr.arpa
> or 168.192.in-addr.arpa, so dns will loop from the top and never
> time out.
>
> this doesn't fix the problem, but it will stop these kinds of queries in
> their tracks.  add to /lib/ndb/$myrecursiveserver:
>
> #
> # spam defense.  unfortunately, arin doesn't give negative
> # rcodes for these non-routable addresses.  we'll do it for
> # them
> #
> dom=168.192.in-addr.arpa soa=
>         refresh=3600 ttl=3600
>         ns=ns1.MY.DOM
>         ns=ns2.MY.DOM
>
> dom=10.in-addr.arpa soa=
>         refresh=3600 ttl=3600
>         ns=ns1.MY.DOM
>         ns=ns2.MY.DOM
>
> - erik
>