Re: blockhole'd IP receiving referral?
On 19 Dec 2009, at 16:11, Fr34k wrote: Hello, Chris, I believe you are correct. That is, blackhole applies to the sending of queries in addition to the receiving of queries. Let me explain. I discovered this the hard way. I had a /24 in the blackhole because it contained abusive clients. Within this /24 sat two legitimate authoritative name servers (ANS). Our clients could not get responses from these ANS servers because they were within the /24 blackhole. The solution was to make an exception for these two ANS servers. This is fine in that the blackhole function is doing its job well! However, we have a few /16s among our blackhole networks and to manage an exception list of legitimate ANS servers contained within will be unmanageable. So, how to stop the abuse without impacting legitimate client queries? I think the solution here would be to permit allow-recursion ( mynets;) clients to query and get responses from blackhole ( badnets; } networks in some way. Does such a solution, or equivalent, exist? If so, can someone share? I haven't tested this, but I think this might do what you ask for: Remove the blackhole-statements from the config; instead add these rules to iptables, ipfw or equivalent: * Allow related or established packets to the DNS port * Drop incomming DNS-requests from the blackhole nets This will basically allow replies, but drop requests. Greets, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
strange dig behavior
I've got the following three scenarios The client can query a domain A residing on a recursive name server. The client can query a domain B on an authratative name server. When client queries domain B through the RNS, a Status: refused results. I don't know what is causing the refused. IP tables is off everywhere, and there are no ACL's on routers or firewalls. The only error I'm seeing is the following in the debug log 20-Dec-2009 19:21:09.443 query-errors: debug 3: client 172.16.0.5#41484: query failed (REFUSED) for test.com/IN/A at query.c:3882 I'm running bind 9.6.1 on RH ES 5 64 bit O/S. Any ideas? Thanks!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: strange dig behavior
Pamela Rock wrote: I don't know what is causing the refused. IP tables is off everywhere, and there are no ACL's on routers or firewalls. Has nothing to do with firewalls (or ACLs on routers). The only error I'm seeing is the following in the debug log 20-Dec-2009 19:21:09.443 query-errors: debug 3: client 172.16.0.5#41484: query failed (REFUSED) for test.com/IN/A at query.c:3882 Any chance you can post the config of the recursive server? Thanks, AlanC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: strange dig behavior
In article mailman.18.1261358139.21153.bind-us...@lists.isc.org, Pamela Rock prock...@yahoo.com wrote: I've got the following three scenarios The client can query a domain A residing on a recursive name server. What do you mean by a domain residing on a recursive nameserver? If a domain resides on a server, the server should be authoritative for that domain. The client can query a domain B on an authratative name server. When client queries domain B through the RNS, a Status: refused results. I don't know what is causing the refused. IP tables is off everywhere, and there are no ACL's on routers or firewalls. The only error I'm seeing is the following in the debug log 20-Dec-2009 19:21:09.443 query-errors: debug 3: client 172.16.0.5#41484: query failed (REFUSED) for test.com/IN/A at query.c:3882 I'm running bind 9.6.1 on RH ES 5 64 bit O/S. Any ideas? Thanks!! Is that log on the recursive nameserver or the authoritative nameserver? If it's on the recursive server, is the client in the allow-recursion ACL on the server? If it's on the authoritative server, is the recursive server in the allow-query ACL? -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
