Why would a university block incoming UDP traffic with destination port 53?
Solution 1:
The logic works like this:
- Only authoritative DNS servers that provide records to the internet are required to be exposed.
- Open recursive servers that are exposed to the internet will inevitably be found by network scans and abused. (See user1700494's answer)
- 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.
- 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.
Solution 2:
For example, attackers could use university's DNS server as transit host for DNS Amplification DDoS Attack
Solution 3:
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:
- Distributed Reflection DoS attack
- Cache poisoning
- TCP SYN floods
- DNS tunneling
- DNS hijacking
- Basic NXDOMAIN attack
- Phantom Domain attack
- Random subdomain attack
- Domain lock-up attack
- 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."
Solution 4:
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.
Solution 5:
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)