Re: lame-servers: error (FORMERR) resolving [something]

[Daniele]

What tests should I do?
If I query directly an external name-server (one of the root ones or
8.8.8.8 for example) I receive the correct response.
For this reason I'm inclined to think that the router doesn't block packets
to/from port 53.
Why should it block packets generated by BIND9?


2013/1/12 Lyle Giese 

>  On 01/11/13 03:05, Daniele wrote:
>
> Port 53 is open, I can also telnet it from another box in the same network.
> Now I think the problem can be on the packets size, because I'm trying
> every solution but nothing works.
>
>
> 2013/1/9 Lyle Giese 
>
>>   On 01/09/13 08:39, Daniele wrote:
>>
>>  2013/1/9 Phil Mayers 
>>
>>> On 09/01/13 13:53, Daniele wrote:
>>>
 This is the scenario.

 I installed BIND9 via `apt-get` on a newly installed UBUNTU 12.04,
 virtualized on VirtualBox.
 The network works properly because if I indicate a different server from
 my own BIND9 (the first line of '/etc/resolv.conf' is, for example,
 `nameserver 8.8.8.8`) the lookups and any action on the Internet
 succeed.


>>>  No, this assumption is not valid.
>>
>>
>>  I meant that I can reach the Internet and, vice versa, the Internet can
>> reach my terminal.
>>
>>
>>   ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> bind-users mailing 
>> listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users
>>
>>  Recursive queries that named does for a client are different than your
>> machine as a dns client reaching out to Google's recursive service.
>>
>> You need to have UDP & TCP port 53 open to your recursive server(the one
>> running named) first of all.  And if any network element within your
>> network limits the size of UDP packets, you will have problems with EDNS0
>> queries.
>>
>> On this box running named, try this:
>>
>> dig +trace www.msn.com
>>
>> dig +trace imperial.ac.uk
>>
>> After dig gets a copy of the root servers from the local named, it will
>> do the same type of queries that a recursive name server does.
>>
>> Lyle Giese
>> LCR Computer Services, Inc.
>>
>>
>>   Saying port 53 is open because you can telnet to it from a local
> computer is a very limited test.
>
> 1) Telnet only use TCP, UDP is the primary/first communication channel DNS
> uses.
>
> 2) The router between this computer and the Internet is not at fault?  You
> have done no tests to prove that one way or the other.
>
> Do a couple of dig +trace runs and see what that shows.  And try some any
> queries to a dnssec enable domain.
>
>
> Lyle Giese
> LCR Computer Services, Inc.
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: lame-servers: error (FORMERR) resolving [something]

[Shane Kerr]

Daniele,

It may be a simple case of your firewall not allowing any DNS queries
that do not request recursion. Difficult to know.

You may want to try:

dig +trace www.isc.org

This will follow the referrals from the root, and you can verify that
this works.

The next step may be to try:

dig +trace +dnssec www.isc.org

This will ask for DNSSEC, which will mean enabling EDNS0 and getting
bigger response packets, both of which can cause problems with broken
middleboxes (although BIND 9 should work even in those cases).

Cheers,

--
Shane

On Monday, 2013-01-14 10:44:44 +0100, 
Daniele  wrote:
> What tests should I do?
> If I query directly an external name-server (one of the root ones or
> 8.8.8.8 for example) I receive the correct response.
> For this reason I'm inclined to think that the router doesn't block
> packets to/from port 53.
> Why should it block packets generated by BIND9?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

How to Limit DNS Request per ip source ?

[Gaurav Kansal]

Dear All,

 

I want to limit the dns request per ip source through iptables.

 

I tried the following commands, but unfortunately didn't succeed. 

 

-A RH-Firewall-1-INPUT -m udp -p udp --dport 53 -m state --state NEW -m
recent --set --name DNSQF --rsource

-A RH-Firewall-1-INPUT -m udp -p udp --dport 53 -m state --state NEW -m
recent --update --seconds 60 --hitcount 5 --name DNSQF --rsource -j DROP

 

 

If anyone is using iptables for limiting DNS Query per IP, then pl. help me
out.

 

 

Thanks and Regards,

Gaurav Kansal

Mob - 9910118448

 

Happy New Year 2013.

IPv4 is Over,

Are your ready for new Network.

 

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How to Limit DNS Request per ip source ?

[Stephane Bortzmeyer]

On Mon, Jan 14, 2013 at 06:36:44PM +0530,
 Gaurav Kansal  wrote 
 a message of 156 lines which said:

> I tried the following commands, but unfortunately didn't succeed. 

Why do you want to limit? If it is against a DoS attack, I warn you
that most Netfilter modules (for instance, "state") require allocating
a state on the firewall and a clever attack can fill the memory of the
machine.

> If anyone is using iptables for limiting DNS Query per IP, 

If you have a DNS server used for reflection+amplification attacks
*and* it is a Linux machine *and* you have Netfilter >= 1.4 *and* you
cannot or does not want to install the patches for BIND or NSD to do
rate-limiting (they may provide a better result) *and* the attack is
over IPv4 *and* the attacker uses only a few domain names, you could
be interested in the technique we use. Disclaimer: it works for us, it
will not work for ever, it works now.

The idea is to use the Netfilter u32 module to recognize the attack,
then to rate-limit it with the Netfilter hashlimit module.

First, get the iptables rules generation script
.

Then, look at the traffic so see the pattern: what query type
(typically ANY), what query domain name, etc. In the examples, we'll
assume QTYPE=ANY, QNAME=example.net.

Then, generate the Netfilter rule:

iptables -A INPUT -p udp --dport 53 -m u32 \
 --u32 $(python generate-netfilter-u32-dns-rule.py --qname example.net 
--qtype ANY) -j RATELIMITER

The RATELIMITER chain can be:

iptables -A RATELIMITER -m hashlimit \
   --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
   --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP

or you can replace -j RATELIMITER by -j DROP of you want to be
radical.

There are more options in the generate-netfilter-u32-dns-rule.py
script, such as --bufsize=NNN if the attacker uses a fixed EDNS buffer
size (some do).

There are several ways for the attacker to work around this technique
(some obvious and some not so obvious). But my point is that it works
*today*, with *actual* attacks. So, it definitely helps but keep your
eyes open, have alternative solutions in place and do not put all your
eggs in one basket

More details (only in French) at

and 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How to Limit DNS Request per ip source ?

[Beavis]

Just put an ACL filter on your bind config for recursive queries. this
will make your dns less susceptible to flash-crowd type attacks. Cisco
has a short document about this.

http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

just check out the bind-centric info. discard the rest.


regards,
-B

On Mon, Jan 14, 2013 at 1:06 PM, Gaurav Kansal  wrote:
> Dear All,
>
>
>
> I want to limit the dns request per ip source through iptables.
>
>
>
> I tried the following commands, but unfortunately didn’t succeed.
>
>
>
> -A RH-Firewall-1-INPUT -m udp -p udp --dport 53 -m state --state NEW -m
> recent --set --name DNSQF --rsource
>
> -A RH-Firewall-1-INPUT -m udp -p udp --dport 53 -m state --state NEW -m
> recent --update --seconds 60 --hitcount 5 --name DNSQF --rsource -j DROP
>
>
>
>
>
> If anyone is using iptables for limiting DNS Query per IP, then pl. help me
> out.
>
>
>
>
>
> Thanks and Regards,
>
> Gaurav Kansal
>
> Mob – 9910118448
>
>
>
> Happy New Year 2013.
>
> IPv4 is Over,
>
> Are your ready for new Network.
>
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Disclaimer:
http://goldmark.org/jeff/stupid-disclaimers/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: lame-servers: error (FORMERR) resolving [something]

[Leonard Mills]

Packet dumps at your edge would likely be helpful to your diagnosis.

At your firewall (or other edge appliance) you are seeing successful UDP from a 
high port on your system (DNS client) to port 53 on the server and a reply in 
the opposite direction.  You are not seeing success from an external client 
high port to 53 to on your server.

The two operations are absolutely disjoint when you deal with firewall tuples.

Hope this helps,

Len





>
> From: Daniele 
>To: bind-users@lists.isc.org 
>Sent: Monday, January 14, 2013 1:44 AM
>Subject: Re: lame-servers: error (FORMERR) resolving [something]
> 
>
>What tests should I do?
>If I query directly an external name-server (one of the root ones or 8.8.8.8 
>for example) I receive the correct response.
>For this reason I'm inclined to think that the router doesn't block packets 
>to/from port 53.
>Why should it block packets generated by BIND9?___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users