[Dnsmasq-discuss] DNSMasq and DNS reflection attacks

René van Dorst opensource at vdorst.com
Fri Oct 25 07:52:12 BST 2013

I am testing my current setup with dnsmasq as an authorized server and a 3 slave dns server.
I am using a standard domain register with slave dns support. ( www.nxs.nl )
Only the slave dns servers has access from the internet to dnsmasq, the rest is blocked by the firewall.
This setup adds a extra DNS server but reduces the risk that dnsmasq is exposed to the internet for everybody.

The current problem with this setup you can't added out of the zone IP addressen IPv4 nor IPv6.
I am not sure but I don't know if dnsmasq created PTR record on the slave server. 
My dns provider nor my ISP does support this. Which is for 99% the case and also no problem.

I also have a Sixxs IPv6 tunnel which allows me to setup a reverse dns server.
I want to use this range for my fix servers.

I did send Simon a email with my ideas and though about it.
I think we will see some changes in the upcoming releases.


René van Dorst

/dev/rob0 <rob0 at gmx.co.uk> , 25-10-2013 0:06:
On Thu, Oct 24, 2013 at 05:28:29PM +0100, Simon Kelley wrote: 
> On 24/10/13 17:03, Brian Rak wrote: 
> >We've recently undertaken a project to clean up our network, and  
> >lock down all the open DNS resolvers. As you may know, these are  
> >very frequently used for DDOS attacks:  
> >http://openresolverproject.org/ ,  
> >http://www.team-cymru.org/Services/Resolvers/ . 
> > 
> >I haven't been able to find any sort of configuration option that  
> >would prevent DNSMasq from being abused like this, and I've had to  
> >resort to iptables rules instead. Is there a configuration option  
> >that that would disable responding to DNS queries from certain  
> >interfaces? The other option that seems handy would be one to only  
> >reply to DNS queries from hosts that have a configured DHCP lease. 
> > 
> >Are there any features of DNSMasq that would prevent it from being 
> >abused to conduct attacks? 
> This is an important topic, and quite difficult to understand, so  
> I'm going to take this opportunity to try and put a definitive  
> statement on the record. 
Good stuff here, as usual, but questions still exist. 
Yes, I think of dnsmasq in its original mission mostly: as a DNS  
forwarder and provider of internal DNS for [DHCP usually] LAN hosts.  
That seems to be the gist of your response here: to keep dnsmasq safe  
from Internet attackers, don't expose dnsmasq to the Internet. 
However, in the coming age of IPv6 and [we hope] the decline of NAT,  
users will be more likely to want to expose dnsmasq to the Internet  
as an authoritative nameserver. I can see the potential need for  
serving both ip6.arpa zones and a zone such as "dh6.example.com" (the  
--domain in dnsmasq terms.) 
I have reviewed the "AUTHORITATIVE CONFIGURATION" section as well as  
all the --auth-* settings in the manual, and I still have two  
1. Is there a way to designate interfaces which ONLY respond to  
queries for our authoritative names? (--auth-server looks like it  
might do this, but it does not quite say so.) If I'm acting as NS  
host for dh6.example.com and <whatever>.ip6.arpa, I need to respond  
to those queries to anyone, but I don't want to let them look up  
google.com nor lists.thekelleys.org.uk. For that matter, they  
shouldn't even be able to get any names from /etc/hosts UNLESS those  
names are in my zone. 
2. Is there a way to limit the response rate on these queries on the  
external IP address[es]? 
A third concern, which isn't quite relevant to this thread, but I  
might as well mention anyway: 
3. what about DNSSEC signing, will dnsmasq ever be able to serve  
signed data? 
I'm a big fan of dnsmasq, BTW; it has made the jobs of SMB/SOHO  
network administrators much easier. The features I mention would  
improve safety while exposed to the Internet, but I am not sure  
they're worth the added size and code complexity. 
It could well be best that dnsmasq should stick to its original  
mission. Those who want advanced features could use it as a hidden  
master for BIND (or other nameservers.) That part can work safely,  
and the slave server could do inline signing. 
PS to Simon, a note on your manual: you should stick to example names  
for zones, not "our.zone.com" or "secondary.myisp.com". Note that  
both zone.com and myisp.com exist (the former being owned by  
Microsoft.) I'd consider perhaps s/com/example/ for those. Reference:  
RFC 6761. 
Also in three places you make reference to "ipv6.arpa", which in  
other placess is correctly called "ip6.arpa". 
Another very minor nitpick: under --interface you mention "IP alias  
interfaces (eg "eth1:0")". Those aren't interfaces at all; only the  
brokenness of Linux ifconfig(8) displays them as such. Please  
consider changing "interfaces" there to "labels". Help stamp out  
ignorance ... and even Linux net-tools itself! :) 
> First the simple stuff. 
> Dnsmasq has --interface --except-interface and --listen-address 
> configuration options that disable response to DNS queries from 
> certain interfaces. The first thing that has to be done is to use 
> these. Mostly it's the only thing that needs to done. 
> Now, the complicated stuff. 
> Under certain circumstances, --interface=<interface> degrades to  
> mean the same as --listen-address=<address on interface>. For  
> instance if eth0 has address and dnsmasq is configured  
> with --interface=eth0, then dnsmasq will reply to any query which  
> is sent to, no matter what interface it actually  
> arrives at. The circumstance under which happens is when the  
> --bind-interfaces flag is used. 
> Now, in the above example, this isn't a problem, since a botnet  
> can't direct traffic to an RFC-1918 address. If, on the other hand,  
> the address of an internal interface (ie one configured to accept  
> DNS queries) is globally routable, then queries which arrive via  
> another interface (ie one linked to the internet) with the  
> destination address of the internal interface _will_ be replied to,  
> and a DNS reflection attack is possible. 
> This has mainly been seen in libvirt and OpenStack installations  
> which use dnsmasq, since sometimes they are provisioned with "real"  
> addresses. I'd expect to see problems in the future with IPv6,  
> since far more people will be using globally routable addresses  
> with IPv6. 
> The reason that this happens is that --bind-interfaces uses the  
> bare-minimum BSD sockets API only. Detecting which interface a  
> packet arrived on, rather than the address to which it was sent,  
> needs non-portable API, and is impossible on some platforms  
> (openBSD, for instance) --bind-interfaces is a "works everywhere"  
> least common denominator. It's also useful when you're running  
> multiple instances of dnsmasq on one host, which is why most 
> people use it. 
> The fix is to use either the default listening mode, or if running 
> multiple instances, the new --bind-dynamic mode. --bind-dynamic is 
> only available on Linux, and --bind-interfaces is the only mode 
> available on openBSD, so BSD users have rather more problems here. 
> Summary. There's a problem is you want to accept queries in an  
> internal interface with a globally routable address and use  
> --bind-interfaces. The fix is to remove --bind-interfaces and, if  
> necessary, replace it with --bind-dynamic. This fix is not  
> applicable on all platforms, 
> The Real Soon Now 2.67 release logs a very prominent warning if the 
> dangerous combination is configured. 
  http://rob0.nodns4.us/ -- system administration and consulting 
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: 
Dnsmasq-discuss mailing list 
Dnsmasq-discuss at lists.thekelleys.org.uk 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20131025/d7beb8f7/attachment.html>

More information about the Dnsmasq-discuss mailing list