blocking resolving for 10.X.X.X addresses

Steve Foster fosters at uk.psi.com
Tue Oct 29 09:31:21 UTC 2002


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?
>>
>>
>>
>Steve Foster
>Senior Systems Administrator
>PSINet Europe
>Work: +44 (1223) 577322
>Mobile: +44 (7720) 425911
>
>
>
Steve Foster
Senior Systems Administrator
PSINet Europe
Work: +44 (1223) 577322
Mobile: +44 (7720) 425911


More information about the bind-users mailing list