DNS Open Resolvers on IPv4
LACNIC CSIRT is working together with CSIRT CEDIA on the “DNS Open Resolvers on IPv4” project that seeks to understand the current status of the region, identify open resolvers, and proactively alert and recommend potential corrections to how this service is configured.
Open DNS resolvers affect both those who have the open service as well as Internet security in general. This type of server is used as a vector for amplification DDoS attacks, as an attacker can send these servers a recursive DNS query that will return a large amount of data, much larger than the original DNS request packet. This makes the DNS server a very powerful traffic amplifier, as these amplified queries can be directed to a specific IP address, which then receives a large volume of traffic that would cause the services to be unavailable. To conduct this type of attacks, an attacker does not even need to control the hardware.
A recursive DNS server should only reply to queries from the clients that are on its same network, rejecting any that come from outside.
How to solve this problem
We strongly recommend re-configuring your DNS resolvers. Here are some ways to do this:
* Resolvers should only respond to their clients. They should not respond to queries from IP addresses outside their own network (in BIND, this requires defining a limited group of devices in the “allow-query” rule). In the following example, only networks 192.168.196.0/24 and 2001:db8::/32 will be able to perform queries. More networks can be added if we separate them with a semicolon (;):
allow-query {
192.168.196.0/24;
2001:db8::/32;
localhost;
}
}
* To resolve only domain names that are part of your authoritative zones (in BIND, you must define a limited set of hosts in the “allow-query” rule for the server in general, setting “allow-query” to “any” for each zone). Example:
allow-query {
192.168.196.0/24;
2001:db8::/32;
localhost;
}
}
allow-query {
192.168.196.0/24;
2001:db8::/32;
localhost;
}
}
* You can achieve the same behavior in unbound by using the access-control directive in the unbound.conf file. Example (add as many access-control directives as networks you have):
server:
access-control: 192.168.196.0/24 allow
access-control: 2001:db8::/32 allow
* In the case of mikrotik devices, we can stop resolving to third parties by deselecting the Allow Remote Requests checkbox:
Another option is to go to Mikrotik’s web control panel, IP→ DNS and deselect Allow Remote Requests:
If your company is an ISP, you must also check your network configuration and make sure that you do not allow spoofed traffic (traffic pretending to be from external IP addresses) to leave your network. Networks and devices that allow spoofed traffic (traffic with fake IP addresses) allow this and other types of attacks.
* If you use openwrt, dd-wrt or a Linux device, you may be using dnsmasq. In the case of dnsmasq, the solution is to prevent the entrance of UDP packets from the Internet to port 53 on our WAN interface. This can be configured in the firewall of your openwrt/dd-wrt or using iptables on your Linux device:
iptables -I INPUT -p udp –dport 53 -j DROP
How to check if your changes have been effective
Once you have made the necessary changes, you can go to https://openresolver.com/ and check whether the IP address we informed is an open resolver.
Open Resolvers on IPv6
If any of your DNS resolvers are configured for IPv6 or dual stack, we suggest checking the information and recommendations available at: