Understanding DNS Port Requirements
DNS (Domain Name System) primarily uses User Datagram Protocol (UDP) on port 53 for standard queries due to its low overhead. However, for larger responses or zone transfers, it falls back to Transmission Control Protocol (TCP) on port 53. When configuring iptables, ignoring either protocol can lead to intermittent failures where small queries work but large resolutions fail. Therefore, a robust configuration must explicitly handle both UDP and TCP traffic on port 53.
If you are using a local caching resolver like BIND or Unbound, the traffic might be loopback-based. In such cases, you typically only need to allow traffic from 127.0.0.1. However, for most server configurations pointing to external resolvers like Google's 8.8.8.8 or Cloudflare's 1.1.1.1, you must allow traffic destined for those specific IP addresses. It is crucial to identify your current DNS servers by checking the /etc/resolv.conf file or running systemd-resolve --status on modern Linux distributions.
Configuring Outbound DNS Rules
The first step is to ensure that your machine can send DNS queries out to the internet. This involves modifying the OUTPUT chain in the filter table. You need to create rules that match packets destined for port 53 using either UDP or TCP protocols. Below is the command structure for allowing outbound UDP DNS queries:
iptables -A OUTPUT -p udp --dport 53 -j ACCEPTSimilarly, you must add a rule for TCP to handle larger DNS transactions:
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPTThese commands append (-A) the rules to the end of the existing OUTPUT chain. If you have other restrictive policies at the end of the chain, placing them here ensures they are evaluated before any final DROP or REJECT rules. Always verify the order of your rules using iptables -L -n -v to ensure the ACCEPT rules are positioned correctly relative to any default deny policies.
Allowing Incoming DNS Responses
While sending queries is essential, your system also needs to receive the responses from the DNS servers. By default, many firewall configurations drop all incoming traffic unless explicitly allowed. You must therefore add rules to the INPUT chain to accept return traffic. The source port for DNS responses is 53, while the destination port is the ephemeral high-numbered port used by your client application.
To allow these responses, use the following commands:
iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -j ACCEPTNotice the use of --sport (source port) instead of --dport. This ensures that only legitimate responses from DNS servers are accepted. While this approach is simple, it is somewhat broad as it accepts any UDP/TCP packet coming from port 53. For enhanced security, you can restrict these rules further by specifying the -d flag with your specific nameserver IP address, ensuring that only traffic from trusted resolvers is permitted.
Stateful Filtering Best Practices
A more efficient and secure method than manually allowing ports is to leverage connection tracking. By enabling stateful filtering, iptables automatically allows return traffic for established connections. If you have already allowed outbound traffic for other services via stateful rules, DNS might already work if you permit new outbound connections generally. However, if you are implementing a strict whitelist approach, combining stateful rules with explicit port allowances is recommended.
You can check if connection tracking is active by looking for rules containing state or conntrack. If your policy allows established connections in the INPUT chain, you may not need the explicit inbound DNS rules mentioned above, provided the outbound rules are present. This reduces the complexity of your firewall configuration and minimizes the risk of misconfiguration.
Verifying Your Configuration
After applying the rules, test your DNS functionality using tools like nslookup or dig. If resolution fails, check your iptables logs for dropped packets. You can enable logging by adding a LOG target before the DROP target in your chains. Additionally, consider persisting your rules across reboots using tools like iptables-persistent or saving them to a script executed at startup. For complex setups involving multiple network interfaces, refer to our guide on IPTables: NAT Source Address Bridge Interface on Linux to understand how interface-specific rules interact with general routing tables.
Frequently Asked Questions
Why does DNS work sometimes but fail often?
This usually happens when only UDP port 53 is allowed, but some domains require TCP for large responses or EDNS0 extensions. Ensure you have added ACCEPT rules for both UDP and TCP protocols on port 53 in both INPUT and OUTPUT chains.
Can I block DNS traffic entirely for security?
Yes, you can block DNS by removing the ACCEPT rules or adding explicit DROP rules for port 53. However, this will prevent your system from resolving any hostnames, effectively breaking most internet applications except those using raw IP addresses.
How do I find my current DNS server IP?
You can view your configured DNS servers by checking the contents of /etc/resolv.conf or by running resolvectl status on systems using systemd-resolved. Use these IPs to refine your iptables rules for tighter security.
Do I need to restart the firewall after adding rules?
No, iptables rules apply immediately upon execution. However, they will be lost upon reboot unless you save them using a persistence mechanism like netfilter-persistent or by integrating them into your system's startup scripts.
What if I am using IPv6?
The rules above apply to IPv4. For IPv6, you must use ip6tables instead of iptables. The syntax remains identical, but you should replace iptables with ip6tables and ensure your system has valid IPv6 DNS servers configured.