When would I open Port 53 for DNS?

Question

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

Solution 1

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?

Solution 2

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.

Solution 3

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.

Solution 4

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.

Solution 5

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)

View more solutions

Comments

[csi]

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]

And oops. I meant "open the port" not "secure the port". Editted

[csi]

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?

[ravi yarlagadda]

@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.

[Matt]

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.

[ravi yarlagadda]

@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.

[venzen]

the belief that outbound DNS queries use port 53 is incorrect.

[ravi yarlagadda]

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.

[venzen]

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.

[ravi yarlagadda]

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.

[ravi yarlagadda]

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.

[venzen]

Condescension doesn't change the fact that the OP is referring to a Linux host. A note on your answer doesn't change the fact that the TCP/IP model (of which UDP is a subset) does not allow common services (like DNS) to communicate over the same port. Your answer statement "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." is wrong.

[ravi yarlagadda]

the TCP/IP model (of which UDP is a subset) does not allow common services (like DNS) to communicate over the same port - Can you clarify what you mean by this? Are you saying that DNS queries can't use port 53 as both the source and destination port?

[Michael Hampton]

Can't be. DNS queries did exactly that for 20 years...

[venzen]

Gentlemen, this argument via comments is pointless. Michael Hampton, indeed, but the practice of allowing client/server communication via the same privileged port (0-1023) has been stopped by Iana RFCs. @Shane I am not talking about theoretical possibilities, but practical reality: the OP is "Locking down an application server" and has tagged it "linux". If you want to disprove my assertion then prove it wrong via a source or command line output. I have work to do and will not engage in further talk.

[ravi yarlagadda]

@venzen This was the case for most systems for a long time, and still will be for some older Linux systems - see kb.cert.org/vuls/id/800113 - the section on fixed source ports. But I do agree with you that it's not worth an argument, and you are absolutely right on the larger point that my answer didn't account for the random source ports used by most modern OSes. Thanks for your input, and apologies for the misunderstanding!

[Matt]

heh.. of course we miss the simple bit @venzen =) the destination port for the dns reply will be random above 1024 so the ops rule won't go near query replies. You'd need conntack or a static sport=53 dport>1024 rule to allow dns queries.