Opened 4 years ago

Last modified 2 years ago

#14951 reopened defect

Configure dnsmasq to NOT be an open resolver

Reported by: anonymous Owned by: developers
Priority: high Milestone: Attitude Adjustment 12.09.1
Component: packages Version: Trunk
Keywords: Cc:


DNS amplification attacks are the scourge of the net. Let your firewall down by mistake, and soon you'll be identified as a open resolver and be flooded for months by hopeful amplified DDoS attack packets — so many of them actually that even if you respond to them, there will be no amplification.

openwrt fails to configure dnsmasq to not be an open resolver. dnsmasq should be configure to only bind to the lan address(es) and/or interface(s) using options -a or -z. It is *never* acceptable to let dnsmasq listen to the wan.

Alternatively and/or additionally, a default rule to drop incoming traffic on port 53 might be a good idea if/when the firewall is open.

I'm opening as priority high because this is an Internet security issue.

Attachments (0)

Change History (28)

comment:1 Changed 4 years ago by olmari

I kinda hear you, but then again there is a firewall on per default, default settings is drop wan, only allow DHCP... Mistakes can be made ofcourse, but assume no firewall for WAN, DNS is propably the least of the worries..

comment:2 Changed 4 years ago by dtaht

dnsmasq CAN be used as a normal resolver and answer questions for hosts within it's lan.

comment:3 Changed 4 years ago by fahree

Last edited 4 years ago by fahree (previous) (diff)

comment:4 Changed 4 years ago by fahree

I'm the person who registered the bug.

Yes, the firewall usually takes care of blocking attack packets. But a small temporary mistake, and there you are flagged as an open resolver by the bad guys, and are condemned to permanent bombardment for many months (years?) to come.

It's good practice for a router product to have several lines of defense. dnsmasq has this functionality builtin but needs to be properly configured. Yes, it can and should answer queries on the lan. But no it MUST NOT answer queries on the wan.

comment:5 Changed 4 years ago by florian

  • Resolution set to wontfix
  • Status changed from new to closed

dnsmasq is only spawned on the LAN interface by default, so it will not even answer to DNS queries coming from the WAN interface, I do acknowledge the potential for what you are describing, although it does not sound like the default setup will cause any of this to happen. Anything that is non-standard is the user responsibility, so (s)he might as well have enabled the built-in feature you describe in dnsmasq.

comment:6 Changed 4 years ago by fahree

Uh? I didn't do anything non-default to my dnsmasq setup (that I know) and it definitely is NOT "spawned on the LAN interface", and did "answer to DNS queries coming from the WAN interface". That's a bug.

comment:7 Changed 4 years ago by fahree

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Sorry, this happened with default dnsmasq configuration on openwrt 12.09. Unless it has been fixed since that release, I'm reopening the bug.

comment:8 Changed 4 years ago by jow

Making dnsmasq bind to specific interfaces complicates its setup quite a bit.
In the case of dynamic wan interfaces it needs to be restarted whenever the iface changes.
For interface protocols like pppoe it needs to both exclude the tunnel iface and the physical one below.

If we default to whitelisting dns interfaces we need additional configuration, e.g. make it default to resolve
queries received via interfaces that also have a dhcp pool. This however will make it confusing for users who
want dns on no-dhcp interfaces.

Either way the dnsmasq config needs to be rewritten and the service restarted on every ifup event since
dnsmasq does not support runtime updates of the config state.

There is some ongoing work in trunk to make dnsmasq reloads more efficient but the problem of the additional
config requirements is not addressed yet.

In any case we cannot simply stick notinterface=eth1 into the config as it would merely cover a small subset of
default configurations so do not expect a non-firewall solution soon.

The same caveats apply to other services and the whole "just bind to lan" topic in general.

comment:9 Changed 4 years ago by fahree

A general mechanism for binding only lan interfaces is probably a good thing for openwrt to develop: it's not only for dnsmasq, dnsmasq will just the first and most universal service to benefit from it.

And indeed, the solution may not be easy. But it needs to be done. That's a security issue, to make the entire Internet safer.

comment:10 Changed 4 years ago by gobo@…

I've opened this issue with the dnsmasq developer directly, and they have taken this to heart and implemented an option to restrict the open recursive name server: "--local-service". This has been implemented in v2.69 released today.
If you apply this option by default it restricts the recursive name server to the local subnet, which is exactly what you want; ease of install and reasonably secure.

comment:11 Changed 4 years ago by etienne.rodrigue@…

As a security analyst, I can tell you this is a major bug. All OpenWrt installation since 12.09 can be used to amplify DDOS if default settings are used.

comment:12 Changed 3 years ago by chiblaok@…

Yes. Dnsmasq is listening on ALL interfaces by default. I just got blocked by my ISP and then I am surprised to know OpenWRT has such a low-level bug. Had to configure it by myself. I'm currently using trunk BB version of mid-September, 2014 on a DIR-505 router. Hope this problem can be resolved in future versions.

comment:13 Changed 3 years ago by anonymous

Since it is quite possible that more end-users will install the upcoming BB-14.07, consider enabling dnsmasq's newly introduced "--local-service" option:

Accept DNS queries only from hosts whose address is on a local subnet, ie a subnet for which an interface exists on the server. This option only has effect is there are no --interface --except-interface, --listen-address or --auth-server options. It is intended to be set as a default on installation, to allow unconfigured installations to be useful but also safe from being used for DNS amplification attacks.

comment:14 Changed 3 years ago by anonymous

How does it run on all interfaces if it's using:

append_interface() {
	local ifname=$(uci_get_state network "$1" ifname "$1")
	xappend "--interface=$ifname"

in init.d script? --local-service wouldnt even have an effect, because it's already limited to lan interfaces.

comment:15 Changed 3 years ago by JMV

On BB and
OpenWrt Chaos Calmer r45574 / LuCI (git-15.113.66125-f322842)

ci set dhcp.@dnsmasq[0].wildcard=0
uci commit


listen-address= in /etc/dnsmasq.conf

(I have not exhuastively tested --local-service, but it did not work for me)

comment:16 Changed 3 years ago by JMV


listen-address=, /etc/dnsmasq.conf

resolving also works in the router

comment:17 Changed 2 years ago by anonymous

i'm using default configuration in latest trunk and this still isn't fixed.

i don't care much if it will accept requests from lan only hosts or from all hosts, the main issue here is it is listening on wwan interface and a simple nmap scan from wan/wwan side reveals exact dnsmasq version used:

Starting Nmap 5.00 ( ) at 2015-09-05 14:45 CEST
NSE: Loaded 30 scripts for scanning.
Initiating Ping Scan at 14:45
Scanning [2 ports]
Completed Ping Scan at 14:45, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:45
Completed Parallel DNS resolution of 1 host. at 14:45, 0.02s elapsed
Initiating Connect Scan at 14:45
Scanning [1000 ports]
Discovered open port 53/tcp on
Increasing send delay for from 0 to 5 due to 41 out of 136 dropped probes since last increase.
Increasing send delay for from 5 to 10 due to 25 out of 81 dropped probes since last increase.
Increasing send delay for from 10 to 20 due to 11 out of 18 dropped probes since last increase.
Increasing send delay for from 20 to 40 due to 11 out of 27 dropped probes since last increase.
Completed Connect Scan at 14:45, 38.15s elapsed (1000 total ports)
Initiating Service scan at 14:45
Scanning 1 service on
Completed Service scan at 14:46, 6.01s elapsed (1 service on 1 host)
NSE: Script scanning
NSE: Starting runlevel 1 scan
Initiating NSE at 14:46
Completed NSE at 14:46, 0.00s elapsed
NSE: Script Scanning completed.
Host is up (0.00057s latency).
Interesting ports on
Not shown: 999 closed ports
'''53/tcp open  domain  dnsmasq 2.75
Read data files from: /usr/share/nmap
Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 44.35 seconds

comment:18 Changed 2 years ago by jow

  • Resolution set to fixed
  • Status changed from reopened to closed

if you do not want dnsmasq to listen on wwan then simply configure it accordingly. We can't handle any possible use case in the default config.
The original objective of this ticket (don't be an open resolver) has been fixed eight months ago by adding the local-service option.

comment:19 Changed 2 years ago by gent@…

I have found this thread while searching for a solution on DNS Amplification Attack issue on a wireless access point made by Ligowave which is using dnsmasq for DNS. The problem I was having was due to assigning a real IP to the Ligowave AP was being used for DNS Amplification which the unit is left open for dns queries on the Ethernet interface to the outside world which is a security problem. Unfortunately, Ligowave does not have a way to fix this (yet) and the unit was generating 6 Meg of constant traffic.

I found a temporary fix. Either put the unit behind a firewall or ssh into the unit and kill the dnsmasq and then restart it the option:


However this will go back to defaults if the unit is rebooted. I could not find a more permanent solution, but if anybody has it, please share.


comment:20 follow-up: Changed 2 years ago by vectormu@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

Greetings all.

I may have found a possible fix?

This is my first time using OpenWRT (upgrade to an old WRT54GL Tomato 1.28), but not securing a linux machine.

My hardware is a TP-Link WDR3600 v1.5, OpenWRT 15.05 (Chaos Calmer Sept. 14, 2015).

I agree with OP, etienne, et al. In my opinion, this is still a bug. Best security practice consists of WAN-facing ports being be closed and/or stealthed, unless SPECIFICALLY opened, in the default firmware configuration. This method is one layer of a multi-layered security approach.

But I digress.

This is definitely a bug in the default configuration of the dnsmasq. With the default firmware configuration(s), I port-scanned my machine's WAN IP and FQDN with the following commands:

Commands run:
nmap -vv <blah.blah.external.ip>
nmap -vv <>

and both commands return "Port 53 open"

I also did a dig command to see if anyone external to my firewall can use my DNS server.

Commands run:
dig @<blah.blah.external.ip> any
dig @<> any

and both commands return the DNS entries for as reported by my DNS server.

I then shut down dnsmasq to retest.

Command run:
/etc/init.d/dnsmasq stop

Then I re-ran nmap and dig commands as above. Port 53 does not return available via nmap on external (WAN) interfaces, and the DNS server does not respond to external (WAN) dig requests (or internal (LAN) requests since the service was stopped - duh!).

I implemented JMV's fix by adding "listen-address=," to /etc/dnsmasq.conf and that almost took care of the issue. Port 53 still showed open on external (WAN) nmap scans, but my DNS server timed out / did not respond to external (WAN) DNS dig requests. Internal (LAN) nmap and dig operations showed open port 53 and DNS resolution as expected.

Digging around the internetz, I found adding:


as the final fix. External (WAN) nmap scans do not show an open port 53, external (WAN) dig requests time out (see above for commands run). Internal (LAN) access to DNS services work as expected.

Note: internal DNS tested by:

nmap -vv (from client PC - port 53 open as expected)
dig @ any (from router with dig package installed - returns DNS entries for as expected)
dig @ any (from client PC and router - returns DNS entries for as expected)

where is my OpenWRT router's LAN IP address.

Can someone else please verify these configuration entries resolve the open WAN port 53 / external DNS access issues on their box? I did not run wireshark on the WAN interface to see what actually happens to the DNS packets, whether they were DROP or REJECT - I was just happy my WAN ports were closed down from script-kiddies.

Note 2: I tried all combinations of ruleset order and rules in iptables and none of them seemed to be able to close down port 53. Only by adding the above 2 lines to the end of /etc/dnsmasq.conf would external (WAN) port 53 and external (WAN) DNS access be restricted.

If this works, please push these /etc/dnsmasq.conf configuration change upstream for future 15.xx releases.

Thank you.

comment:21 Changed 2 years ago by vectormu@…

Also, sorry if I posted in wrong forum. While doing a search to commission my new router, this was the topmost relevant google result I found. I wanted to drop my findings here in case it could help others, like Gent.

If it's in the wrong thread moderators, please accept my apology and move to an appropriate place.


comment:22 Changed 2 years ago by anonymous

thanks, these config lines are very useful since it's always better to fix the problem at it's root then cure it with firewall or workarounds.

last time i had problems with this turned out dns was open on wan but only when scanned wan ip from lan, since you say it's broken again looks like i'll have to give it another scan.

comment:23 Changed 2 years ago by anonymous

Thank you for looking into this.

comment:24 in reply to: ↑ 20 Changed 2 years ago by anonymous

Replying to vectormu@…:

Just to ask the obvious question...when you port-scanned the WAN IP/FQDN, you did it from a machine outside your LAN, right?

It certainly seems to me that the default firewall rules would block this, regardless of dnsmasq's configuration. Have you modified them somehow?

comment:25 Changed 2 years ago by anonymous

Initially, I performed the port scan/DNS dig from inside my LAN during the usual performance check and network lockdown. After fiddling with iptables for a bit and getting nowhere (plus lots of google searches), I thought to check it from an outside source - in case NAT and/or firewall rules were not reflecting the "true" port state to the outside world.

I went to:

and did a lookup of my FQDN using localhost ('s DNS server). Obviously, it returned my DNS data. Then I did a DNS lookup of my FQDN using my as the "server" entry and it returned my DNS data. That's when I started to dig around some more and settled on the addition of two lines at the end of /etc/dnsmasq.conf.

When I get home, I will comment out those two lines in /etc/dnsmasq.conf, restart dnsmasq, and re-run the tests, just to make sure.

Even so, shouldn't dnsmask not listen on the external (WAN) IP for any client requests, even if the request originated from within the LAN?

In other words, in a (secure) default config:

dig @ any

from a LAN client PC should return nslookup results, while a:

dig @external.wan.ip.ip any

from a LAN client PC should time out, either due to dnsmasq (or bind or whatever DNS server package) ignoring DNS requests from that specific IP/interface (depending on configuration) or due to firewall rules?

Either way, I will comment out the lines, retest, and post my findings.


comment:26 Changed 2 years ago by anonymous

I'm not sure, but I *think* the relevant default firewall rules only apply to packets that actually enter from the WAN interface. Packets that enter from the LAN interface but with the destination IP of the WAN interface won't be filtered.

comment:27 Changed 2 years ago by anonymous

In particular, if you run iptables -S, you can see that the rules specify an ingress interface, not a destination.

comment:28 Changed 2 years ago by anonymous

Oh man! Egg on my face! I am so sorry!

I removed these 2 additional line from /etc/dnsmasq.conf:


From a client PC on the LAN side, I ran:

nmap my.WAN.ip.ip


dig @my.WAN.p.ip any
dig any

These commands returned results. - which I expected.

I then decided to test to see if machines outside my LAN could query my DNS server (via WAN IP/FQDN). Again, I used

Well, the first time kloth returned no results. I ran it again, and it returned results. Ran it again and it returned no results. WT<bleep>?

Looking at kloth's search query return, sometimes it used localhost (as in kloth's DNS server), then it would use my DNS server sometimes. No rhyme or reason behind which server it choose. It appears, that when I used kloth's DNS, I would get DNS results. When it decided to run the DNS query using my DNS server (IP or FQDN), it would timeout. ARGH! A pain in the butt for troubleshooting!

So, in an effort to be thorough, I rigged up another router/switch (actually my old WRT54GL Tomato) upstream of my OpenWRT WAN port, and from the client PC plugged in upstream of my OpenWRT router WAN port I ran:

nmap openwrt.router.wan.ip


dig @openwrt.router.wan.ip any

(keeping in mind I could only use IP addresses since my network flow is: upstream provider -> WRT54GL Tomato -> Client PC and OpenWRT router's WAN port plugged into the LAN switch side of the WRT54GL)

Well, golly-gee-willikers! The OpenWRT WAN port does not respond to nmap scans or DNS dig queries originating from the WAN port side (ie, they return as "server timeout"). There was normal DNS resolution with additional client PCs plugged into the LAN-side switch of the OpenWRT router.

So, in summary, you are correct. The default OpenWRT rules seem to block traffic on port 53 inbound (DNS client query) coming into the WAN port - when queried from a WAN-side machine. When queried from a LAN-side machine to the WAN IP/FQDN, the default OpenWRT rules return the port as being open and it responds to dig queries.

And one additional caveat: sometimes ISP's block some ports outside their subnet. So while the whole WWW can't see your open port, other clients on your ISP's subnet might be able to (but this was not the case in this instance.)

My humble apologies for bringing up this non-issue.

Please consider this ticket resolved and closed.

Thank you!

  • vm

(ps - if you like I can post my iptables -S output for reference and review)

Add Comment

Modify Ticket

as reopened .

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.