From my understanding DNS uses UDP and port 53. What undesirable things could happen if incoming UDP packets to port number 53 weren't blocked?

UPDATE: Packets originate or are destined to the university-operated local DNS server or university-operated authoritative DNS server would be allowed.

  • 19
    Why would a university block incoming UDP traffic with destination port 53? - Why wouldn't they? Or put another way: Why would they allow incoming UDP (or TCP) traffic with a destination port of 53 to transit the network/firewall inbound except to get to the authoritative name servers for the public domain name(s) if those name servers were hosted on the internal university network? – joeqwerty Feb 10 '16 at 18:21
  • 2
    All inbound UDP traffic for port 53 is blocked, except to the university's own DNS servers? That sounds suspiciously like an attempt at using DNS for censorship to me. Albeit one that won't work at all on any system I can think of, since clients will just try TCP when the UDP requests don't come back. Unless you forgot to mention that they also drop TCP traffic for port 53. – Blacklight Shining Feb 11 '16 at 14:15
  • 5
    As a general practice, a system administrator never asks themselves "is there a good reason why I should block this port". Usually, they have all ports blocked by default in their firewall, and they ask themselves "is there a very good reason why I should open this port". – Federico Poloni Feb 11 '16 at 16:01
  • DNS does not use only UDP, it uses TCP as well. if you allow UDP traffic, you should allow TCP too, or things will break (and vice versa, if you drop UDP, drop TCP too). – Edheldil Feb 11 '16 at 16:49
  • 2
    @FedericoPoloni Just don't pretend that you're providing "Internet access" if you do this, because you're not. – David Schwartz Feb 11 '16 at 19:24

The logic works like this:

  1. Only authoritative DNS servers that provide records to the internet are required to be exposed.
  2. Open recursive servers that are exposed to the internet will inevitably be found by network scans and abused. (See user1700494's answer)
  3. The likelihood of someone accidentally standing up an exposed recursive server is greater than that of an exposed authoritative DNS server. This is because many appliances and "out of the box" configs default to allowing unrestricted recursion. Authoritative configurations are much more customized and infrequently encountered.
  4. Given 1-3, dropping all unsolicited inbound traffic with a destination port of 53 protects the network. In the rare event that another authoritative DNS server needs to be added to the network (a planned event), exceptions can be defined on an as-needed basis.

For example, attackers could use university's DNS server as transit host for DNS Amplification DDoS Attack

  • In the link you posted, under dns amplification, it mentions how you could use a dig query to receive a response 50x greater than than query. But if incoming UDP traffic on port 53 is blocked how come I can still make a dig query to a university address. – Daniel Kobe Feb 10 '16 at 18:44
  • 1
    @DanielKobe The DNS zone owning the host record in question is not bound to only exist on the DNS server that you can't currently send UDP/53 packets to. It could also be an indication of a split-horizon DNS setup. – Mathias R. Jessen Feb 11 '16 at 0:45

Andrew B's answer is excellent. What he said.

To answer the question "What undesirable things could happen if incoming UDP packets to port number 53 weren't blocked?" more specifically, I googled "DNS-based attacks" and got this handy article. To paraphrase:

  1. Distributed Reflection DoS attack
  2. Cache poisoning
  3. TCP SYN floods
  4. DNS tunneling
  5. DNS hijacking
  6. Basic NXDOMAIN attack
  7. Phantom Domain attack
  8. Random subdomain attack
  9. Domain lock-up attack
  10. Botnet-based attacks from CPE devices

That's not a conclusive list of possible DNS-based attacks, just ten that an article found noteworthy enough to mention.

Really, the short answer is "If you don't have to expose it, don't."

  • 3
    "If you don't have to expose it, don't." which is true for many things in life. – user9517 Feb 11 '16 at 16:51

They are blocking it, because they can and it is a sensible security policy.

The problem is often more serious than having potential open resolvers - at then end of the day it does not matter setting up DNS servers securely, without being open resolvers, with anti-DDOS measures when any server or machine with a DNS service installed by mistake, and doing DNS forwarding requests to the main DNS server will allow any attacker to bypass your traffic limiting and security restrictions implemented on your DNS servers.

The requests will also appear to come from the internal infra-sctructure, and may expose DNS internal names, and unwanted details of the internal organisation/network/IP addressing.

Also, as per network security rules, the less number of services and services you expose to the outside, the less probabilities of them being compromised and being used as an entry point to leverage an attack on your infra-structure from the inside.


Usually, when it comes to UDP traffic, you want to be restrictive because:

a) Compared to TCP, it is harder for a packet filter to reliably determine if an incoming packet is an answer to a request from inside the network... or an unsolicited request. Enforcing client/server roles via a packet filtering firewall thus gets harder.

b) Any process that binds to a UDP port on a server or client computer, even if it only binds to that port because it wants to make a request itself, will be exposed to unsolicited packets too, making system security dependent on there being no defects in the process that would allow exploiting or confusing it. There have been such issues with eg NTP clients in the past. With a TCP client, unsolicited data sent to that client will, in most cases, be discarded by the operating system.

c) If you are running NAT, heavy UDP traffic can create a lot of workload for the NATing equipment because of similar reasons as in a)


There exist Tools that create VPN tunnel using the DNS protocol and port.

iodine is one of them. It allows to bypass firewalls by tunneling the traffic completely through a server running this software. As the description states, it uses the DNS protocol.

This and similar tools might be the reason for this limitation.

  • 2
    You can tunnel IP over pretty much any of the common application protocols, not to mention TLS, so that's hardly a good reason for dropping traffic. Besides, you would think an IP-over-DNS scheme would bind to an ephemeral port client-side (like regular DNS clients do), rather than port 53. – Blacklight Shining Feb 12 '16 at 6:19

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.