<html><head></head><body>I am testing my current setup with dnsmasq as an authorized server and a 3 slave dns server.<br>I am using a standard domain register with slave dns support. ( www.nxs.nl )<br>Only the slave dns servers has access from the internet to dnsmasq, the rest is blocked by the firewall.<br>This setup adds a extra DNS server but reduces the risk that dnsmasq is exposed to the internet for everybody.<br><br>The current problem with this setup you can't added out of the zone IP addressen IPv4 nor IPv6.<br>I am not sure but I don't know if dnsmasq created PTR record on the slave server. <br>My dns provider nor my ISP does support this. Which is for 99% the case and also no problem.<br><br>I also have a Sixxs IPv6 tunnel which allows me to setup a reverse dns server.<br>I want to use this range for my fix servers.<br><br>I did send Simon a email with my ideas and though about it.<br>I think we will see some changes in the upcoming releases.<br><br>Greats,<br><br>René van Dorst<br><br><br><div><span title="rob0@gmx.co.uk">/dev/rob0</span><span class="detail"> <rob0@gmx.co.uk></span> , 25-10-2013 0:06:<br><blockquote class="mori" style="margin:0 0 0 .8ex;border-left:2px blue solid;padding-left:1ex;">On Thu, Oct 24, 2013 at 05:28:29PM +0100, Simon Kelley wrote:

<br>> On 24/10/13 17:03, Brian Rak wrote:

<br>> >We've recently undertaken a project to clean up our network, and 

<br>> >lock down all the open DNS resolvers. As you may know, these are 

<br>> >very frequently used for DDOS attacks: 

<br>> ><a href="http://openresolverproject.org/" target="_blank">http://openresolverproject.org/</a> , 

<br>> ><a href="http://www.team-cymru.org/Services/Resolvers/" target="_blank">http://www.team-cymru.org/Services/Resolvers/</a> .

<br>> >

<br>> >I haven't been able to find any sort of configuration option that 

<br>> >would prevent DNSMasq from being abused like this, and I've had to 

<br>> >resort to iptables rules instead. Is there a configuration option 

<br>> >that that would disable responding to DNS queries from certain 

<br>> >interfaces? The other option that seems handy would be one to only 

> >reply to DNS queries from hosts that have a configured DHCP lease.

<br>> >

<br>> >Are there any features of DNSMasq that would prevent it from being

> >abused to conduct attacks?

<br>> 

<br>> This is an important topic, and quite difficult to understand, so 

<br>> I'm going to take this opportunity to try and put a definitive 

> statement on the record.

<br>

Good stuff here, as usual, but questions still exist.

<br>

<br>Yes, I think of dnsmasq in its original mission mostly: as a DNS 

<br>forwarder and provider of internal DNS for [DHCP usually] LAN hosts. 

<br>That seems to be the gist of your response here: to keep dnsmasq safe 

from Internet attackers, don't expose dnsmasq to the Internet.

<br>

<br>However, in the coming age of IPv6 and [we hope] the decline of NAT, 

<br>users will be more likely to want to expose dnsmasq to the Internet 

<br>as an authoritative nameserver. I can see the potential need for 

<br>serving both ip6.arpa zones and a zone such as "dh6.example.com" (the 

<br>--domain in dnsmasq terms.)

<br>

<br>I have reviewed the "AUTHORITATIVE CONFIGURATION" section as well as 

<br>all the --auth-* settings in the manual, and I still have two 

<br>concerns:

<br>

<br>1. Is there a way to designate interfaces which ONLY respond to 

<br>queries for our authoritative names? (--auth-server looks like it 

<br>might do this, but it does not quite say so.) If I'm acting as NS 

<br>host for dh6.example.com and <whatever>.ip6.arpa, I need to respond 

<br>to those queries to anyone, but I don't want to let them look up 

<br>google.com nor lists.thekelleys.org.uk. For that matter, they 

<br>shouldn't even be able to get any names from /etc/hosts UNLESS those 

names are in my zone.

<br>

<br>2. Is there a way to limit the response rate on these queries on the 

external IP address[es]?

<br>

<br>A third concern, which isn't quite relevant to this thread, but I 

<br>might as well mention anyway:

<br>

<br>3. what about DNSSEC signing, will dnsmasq ever be able to serve 

signed data?

<br>

<br>I'm a big fan of dnsmasq, BTW; it has made the jobs of SMB/SOHO 

<br>network administrators much easier. The features I mention would 

<br>improve safety while exposed to the Internet, but I am not sure 

they're worth the added size and code complexity.

<br>

<br>It could well be best that dnsmasq should stick to its original 

<br>mission. Those who want advanced features could use it as a hidden 

<br>master for BIND (or other nameservers.) That part can work safely, 

and the slave server could do inline signing.

<br>

<br>

<br>

<br>PS to Simon, a note on your manual: you should stick to example names 

<br>for zones, not "our.zone.com" or "secondary.myisp.com". Note that 

<br>both zone.com and myisp.com exist (the former being owned by 

<br>Microsoft.) I'd consider perhaps s/com/example/ for those. Reference: 

<br>RFC 6761.

<br>

<br>Also in three places you make reference to "ipv6.arpa", which in 

other placess is correctly called "ip6.arpa".

<br>

<br>Another very minor nitpick: under --interface you mention "IP alias 

<br>interfaces (eg "eth1:0")". Those aren't interfaces at all; only the 

<br>brokenness of Linux ifconfig(8) displays them as such. Please 

<br>consider changing "interfaces" there to "labels". Help stamp out 

<br>ignorance ... and even Linux net-tools itself! :)

<br>

<br>

> First the simple stuff.

<br>> 

<br>> Dnsmasq has --interface --except-interface and --listen-address

<br>> configuration options that disable response to DNS queries from

<br>> certain interfaces. The first thing that has to be done is to use

> these. Mostly it's the only thing that needs to done.

<br>> 

<br>> 

> Now, the complicated stuff.

<br>> 

<br>> Under certain circumstances, --interface=<interface> degrades to 

<br>> mean the same as --listen-address=<address on interface>. For 

<br>> instance if eth0 has address 192.168.0.1 and dnsmasq is configured 

<br>> with --interface=eth0, then dnsmasq will reply to any query which 

<br>> is sent to 192.168.0.1, no matter what interface it actually 

<br>> arrives at. The circumstance under which happens is when the 

> --bind-interfaces flag is used.

<br>> 

<br>> Now, in the above example, this isn't a problem, since a botnet 

<br>> can't direct traffic to an RFC-1918 address. If, on the other hand, 

<br>> the address of an internal interface (ie one configured to accept 

<br>> DNS queries) is globally routable, then queries which arrive via 

<br>> another interface (ie one linked to the internet) with the 

<br>> destination address of the internal interface _will_ be replied to, 

> and a DNS reflection attack is possible.

<br>> 

<br>> This has mainly been seen in libvirt and OpenStack installations 

<br>> which use dnsmasq, since sometimes they are provisioned with "real" 

<br>> addresses. I'd expect to see problems in the future with IPv6, 

<br>> since far more people will be using globally routable addresses 

<br>> with IPv6.

<br>> 

<br>> The reason that this happens is that --bind-interfaces uses the 

<br>> bare-minimum BSD sockets API only. Detecting which interface a 

<br>> packet arrived on, rather than the address to which it was sent, 

<br>> needs non-portable API, and is impossible on some platforms 

<br>> (openBSD, for instance) --bind-interfaces is a "works everywhere" 

<br>> least common denominator. It's also useful when you're running 

<br>> multiple instances of dnsmasq on one host, which is why most

> people use it.

<br>> 

<br>> The fix is to use either the default listening mode, or if running

<br>> multiple instances, the new --bind-dynamic mode. --bind-dynamic is

<br>> only available on Linux, and --bind-interfaces is the only mode

> available on openBSD, so BSD users have rather more problems here.

<br>> 

<br>> Summary. There's a problem is you want to accept queries in an 

<br>> internal interface with a globally routable address and use 

<br>> --bind-interfaces. The fix is to remove --bind-interfaces and, if 

<br>> necessary, replace it with --bind-dynamic. This fix is not 

<br>> applicable on all platforms,

<br>> 

<br>> The Real Soon Now 2.67 release logs a very prominent warning if the

> dangerous combination is configured.

<br>-- 

<br>  <a href="http://rob0.nodns4.us/" target="_blank">http://rob0.nodns4.us/</a> -- system administration and consulting

<br>  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

<br>

<br>_______________________________________________

<br>Dnsmasq-discuss mailing list

<br><a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" class="mailto">Dnsmasq-discuss@lists.thekelleys.org.uk</a>

<br><a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a>

<br></blockquote></div></body></html>