blocking resolving for 10.X.X.X addresses
Steve Foster
Hi,
we have found customers trying to resolv 10.X.X.X addresses ( or any other
private addresses), i want to block these so they just get a "refused" or
hostname etc.. not found...
is there any easy way within bind to do this...
many thanks
Steve
Steve Foster
Senior Systems Administrator
PSINet Europe
Work: +44 (1223) 577322
Mobile: +44 (7720) 425911
Jim Reid
Steve> we have found customers trying to resolv 10.X.X.X addresses
Steve> ( or any other private addresses), i want to block these so
Steve> they just get a "refused" or hostname etc.. not found...
Configure your name server to be authoritative for the reverse zones
for these private address ranges. And leave the zones empty, ideally
with a very large TTL for negative caching.
Mark_A...@isc.org
Also apply source address filters if you don't all ready
have them on the customer facing routers. If they are
leaking queries for RFC 1918 reverse lookups what else are
they leaking. Preferably those filters should only allow
out traffic from the address ranges they are assigned though
if they are multi-homed there may be other addresses.
This not only stops leaked traffic. It also stops forged
traffic.
Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.A...@isc.org
Simon Waters
Steve Foster wrote:
>
> we have found customers trying to resolv 10.X.X.X addresses ( or any other
> private addresses), i want to block these so they just get a "refused" or
> hostname etc.. not found...
I think more background is required.
Paul and friends have a project (http://as112.net/) that is
suppose to take care of this, and indeed is I do a "dig -x
10.1.1.1" I get NXDOMAIN, thats to the prisoner at IANA, and the
answer will presumably be negatively cached.
So what precisely is it about the current set up that has become
an issue?
Or is there something else we should know?
Paul Vixie
> > we have found customers trying to resolv 10.X.X.X addresses ( or any other
> > private addresses), i want to block these so they just get a "refused" or
> > hostname etc.. not found...
>
> suppose to take care of this, and indeed is I do a "dig -x
> 10.1.1.1" I get NXDOMAIN, thats to the prisoner at IANA, and the
> answer will presumably be negatively cached.
>
> So what precisely is it about the current set up that has become
> an issue? Or is there something else we should know?
only that the reason we put up AS112 was to keep these queries off of
the root servers, and even so 90% of the queries coming to the root
servers are crud. sinking these queries locally is desirable. if
you come to the public AS112 servers then it shows a local config
error. a HOWTO on this subject would probably be well received.
--
Paul Vixie
Steve Foster
Hi there,
basically our customers have our resolver listed to resolve from, however
some obviously want to resolve private addresses locally, which is fair
enough, simple client change, however if for some reason the private
address isn't resolvable locally, then their request will hit our
resolvers, which are trying to doa lookup on the net before eventually
timing out...this can take up to 2 mins...i just basically want to either
dump these requests or give a null result back to the client from our
resolvers..
any thoughts
Steve
At 00:14 26/10/02 +0100, Simon Waters wrote:
>
>Steve Foster wrote:
>>
>> we have found customers trying to resolv 10.X.X.X addresses ( or any other
>> private addresses), i want to block these so they just get a "refused" or
>> hostname etc.. not found...
>
>I think more background is required.
>
>Paul and friends have a project (http://as112.net/) that is
>suppose to take care of this, and indeed is I do a "dig -x
>10.1.1.1" I get NXDOMAIN, thats to the prisoner at IANA, and the
>answer will presumably be negatively cached.
>
>So what precisely is it about the current set up that has become
>an issue?
>Or is there something else we should know?
>
>
>
Gerald Waugh
On Mon, 28 Oct 2002, Steve Foster wrote:
>
> Hi there,
>
>
> basically our customers have our resolver listed to resolve from, however
> some obviously want to resolve private addresses locally, which is fair
> enough, simple client change, however if for some reason the private
> address isn't resolvable locally, then their request will hit our
> resolvers, which are trying to doa lookup on the net before eventually
> timing out...this can take up to 2 mins...i just basically want to either
> dump these requests or give a null result back to the client from our
> resolvers..
How about using ipchains/iptables and block access to port 53 for those ip
addresses.
Gerald
Joseph S D Yao
On Mon, Oct 28, 2002 at 12:54:02PM +0000, Steve Foster wrote:
> basically our customers have our resolver listed to resolve from, however
> some obviously want to resolve private addresses locally, which is fair
> enough, simple client change, however if for some reason the private
> address isn't resolvable locally, then their request will hit our
> resolvers, which are trying to doa lookup on the net before eventually
> timing out...this can take up to 2 mins...i just basically want to either
> dump these requests or give a null result back to the client from our
> resolvers..
If you want others to resolve 10.* addresses in other ways, the
following should be in a "view" seen only by those sites.
In named.conf:
zone "10.in-addr.arpa" {
type master;
file "zone.10";
};
In zone.10:
$TTL 16d
@ SOA ns.myhost.domain.example. hostm...@domain.example. (
... )
NS myhost.domain.example.
NS ...
* PTR not-a-legal-address-per-myhost.domain.example.
--
Joe Yao js...@center.osis.gov - Joseph S. D. Yao
OSIS Center Systems Support EMT-B
-----------------------------------------------------------------------
This message is not an official statement of OSIS Center policies.
Steve Foster
All,
i think this is sorted now, it appears the the problem was caused by
connectivity issues to the Iana blackhole servers, which for the last week
we couldn't query....checking it today and it all seems fine.
; <<>> DiG 9.2.1 <<>> a -x 10.1.1.1
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49941
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;1.1.1.10.in-addr.arpa. IN A
;; AUTHORITY SECTION:
10.in-addr.arpa. 10703 IN SOA prisoner.iana.org.
hostmaster.root-servers.org. 2002040800 1800 900 604800 604800
;; Query time: 30 msec
;; SERVER: 154.15.245.2#53(154.15.245.2)
;; WHEN: Tue Oct 29 09:36:30 2002
;; MSG SIZE rcvd: 116
Thanks for everyones input anyway
Steve
At 12:54 28/10/02 +0000, Steve Foster wrote:
>
>Hi there,
>
>
>basically our customers have our resolver listed to resolve from, however
>some obviously want to resolve private addresses locally, which is fair
>enough, simple client change, however if for some reason the private
>address isn't resolvable locally, then their request will hit our
>resolvers, which are trying to doa lookup on the net before eventually
>timing out...this can take up to 2 mins...i just basically want to either
>dump these requests or give a null result back to the client from our
>resolvers..
>
>any thoughts
>
>Steve
>
>
>At 00:14 26/10/02 +0100, Simon Waters wrote:
>>
>>Steve Foster wrote:
>>>
>>> we have found customers trying to resolv 10.X.X.X addresses ( or any other
>>> private addresses), i want to block these so they just get a "refused" or
>>> hostname etc.. not found...
>>
>>I think more background is required.
>>
>>Paul and friends have a project (http://as112.net/) that is
>>suppose to take care of this, and indeed is I do a "dig -x
>>10.1.1.1" I get NXDOMAIN, thats to the prisoner at IANA, and the
>>answer will presumably be negatively cached.
>>
>>So what precisely is it about the current set up that has become
>>an issue?
>>Or is there something else we should know?
>>
>>
>>