Locking down an application server. The server hosts a web app that is served via http. There are a few other ports open as well.

Port 53 is open for DNS. Why would I need this?

Extra: (Do not need to answer this but...) Would this command open that port using iptables in Linux

#  iptables -A INPUT -m tcp -p tcp --dport 53 -j ACCEPT

Port 53 is open for DNS. Why would I need this?

You need to have UDP 53 allowed for responses to DNS queries that your server sends, as UDP is a stateless protocol. Don't block it if you want any kind of outbound connectivity, software updates, etc.

Note that for name resolution software in most modern operating systems that's been patched with DNS source port randomization, the source port of the queries (and thus, the destination port of the response) won't necessarily be 53; in those cases, it's probably safe (but unnecessary, unless you have a rogue DNS resolver listening) to block UDP port 53.

Would this command secure that port using iptables in Linux

You don't need to allow TCP 53 inbound unless your server is actually a DNS server. Your second command has -m udp -p tcp, which doesn't make a lot of sense.. typo?

  • Thanks. DNS is hosted elsewhere - say Amazon Route53 or Network Solutions or elsewhere. So that means I can keep INBOUND closed, even if using subdomains & virtual host directives?
    – csi
    Feb 21 '13 at 1:24
  • @ChristopherIckes No. Your server still needs to make outbound DNS queries - inbound port 53 UDP traffic must be allowed (the responses to your queries) for those to function correctly. Feb 21 '13 at 1:35
  • 1
    Even though UDP is a stateless protocol, conntrack can still maintain state of UDP conversations. If NEW connections are allowed out and you have a iptables -A INPUT -m conntrack --ctsate ESTABLISHED,RELATED -j ACCEPT rule like most, UDP will also be managed under this. When you send a UDP request, it will maintain state and allow a reply on the same port/ip. If a reply is received to that packet, the "connection" will become ASSURED and keep state for a larger timeout.
    – Matt
    Feb 21 '13 at 2:51
  • @mindthemonkey Thanks for mentioning that - a deny on udp/53 above that in the rules will still prevent responses, so I wanted to specifically advise against that - but of course that's an important thing to note that's the preferred alternative over opening udp/53 explicitly. Feb 21 '13 at 5:24
  • the belief that outbound DNS queries use port 53 is incorrect.
    – venzen
    Feb 21 '13 at 5:25

If only use your local network, use a local nameserver and have no connection to random sites on the Internet then you do not need to leave port 53 open. But if you do want to use the Internet then you need to be able to translate hostnames to IP addresses. For that you need DNS.


When would you open port 53? I would assume when you are hosting DNS zones. Are you running DNS internally or subbing it out? If you run than you better have 53 open if you want anyone to get the records. As you said you have your DNS hosted elsewhere there is no reason to keep these ports open even with Vhosts and whatnot.

As far as the IPtables rule I'm not sure what you mean by secure, but that will open the port for you.

  • Thanks. DNS is hosted elsewhere - say Amazon Route53 or Network Solutions or elsewhere. So that means I can keep this closed, even if using subdomains & virtual host directives?
    – csi
    Feb 21 '13 at 1:20
  • And oops. I meant "open the port" not "secure the port". Editted
    – csi
    Feb 21 '13 at 1:20

DNS uses UDP port 53

Why would I need this?

If you want to use your server as a DNS server (for example you're hosting your own domains)


If the application server in question is not a DNS server then you do not require port 53 to be open. An "open port" means that the port is externally visible to clients in the network (or out on the internet, possibly). Contrary to popular belief a server or host does not need to have port 53 open to make outgoing DNS queries - this is not how the TCP/IP model works. You can run tcpdump on a host and then issue a DNS lookup from another terminal or browser to confirm this:

'tcpdump -n -s 1500 -i eth0 udp port 53'

So to answer your question: You would only open port 53 on a host that is offering DNS services to a network.

Not part of your question, but it would be advisable to have a firewall installed on any and all network server hosts. This safeguards against instrusion from attacks originating outside the network as well as against virus/trojan and "very clever" (but malignant) users inside the network. A firewall would also simplify the task of opening and closing ports as well as setting access policies as you wish, thereby circumventing the need to manually create (and remember) complex iptables rules.

  • 1
    You seem to be confusing DNS lookups over TCP (which occur in a minority of cases, and should not be used for most queries) with DNS lookups over UDP. Some firewall software (including iptables, as mentioned by mindthemonkey in the comments on my answer) will track a fake connection and allow the traffic as an established connection, but make no mistake: UDP is stateless, and unless your firewall's being smart about allowing responses to recent queries, you need UDP port 53 open to get packets in response to your queries. Feb 21 '13 at 5:30
  • i politely but totally disagree with the stated need for port 53 to be open to external hosts in order for the localhost to resolve DNS. I am writing this message from a machine with port 53 closed. TCP connection tracking on the (localhost) firewall manages the authenticity of DNS queries going out from random ports above port 1023.
    – venzen
    Feb 21 '13 at 5:43
  • 1
    need for port 53 to be open to external hosts - Not blocking packets doesn't mean responding to unsolicited traffic or inbound connections. A explicit block in iptables could take precedence over the established traffic, depending on rule order. TCP connection tracking on the firewall - in most cases DNS queries are UDP traffic, your OS firewall is making educated guesses at fake connections - this is OS/firewall dependent. random ports above port 1023 - DNS source port randomization is a security mechanism to prevent cache poisoning; whether it's in place again depends on the OS. Feb 21 '13 at 6:14
  • Look man, you're talking a lot but the answer to the question remains that you only need port 53 open on a host that serves DNS to the network. Execute 'tcpdump -n -s 1500 -i eth0 udp port 53' to confirm that a client DNS request never uses port 53 on the localhost
    – venzen
    Feb 21 '13 at 6:26
  • Again, that is due to DNS source port randomization. Without knowing the OS and patch levels of the server being referred to in the question, you can't assume that your computer's behavior applies to theirs. You're absolutely right that most modern systems don't send DNS queries with a source of 53 as they've been patched for randomization - I'll add a note on that to my answer. Feb 21 '13 at 6:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.