Blocked UDP Traffic
Causes Slow DNS Resolution

Domain name resolution(opens in new tab) happens over port 53 and uses the UDP protocol by default, because it's faster and less resource-intensive, compared to TCP.

Sometimes, due to packet size limitations, the connection may switch over to TCP, as explained on Server Fault(opens in new tab):

DNS uses TCP when the size of the request or the response is greater than a single packet such as with responses that have many records or many IPv6 responses or most DNSSEC responses.

However, if you happen to have a firewall that blocks UDP traffic, the connection will always switch over to TCP.

In my case, I tested this out with time(opens in new tab) and dig(opens in new tab):

time dig google.com +short

The domain resolution took over 2 seconds:

172.217.169.14

real    0m2.014s
user    0m0.006s
sys     0m0.011s

Next, I tried with the +tcp option of dig:

time dig google.com +short +tcp

The response dropped down to a fraction of a second:

172.217.169.14

real    0m0.013s
user    0m0.007s
sys     0m0.004s

This probably happened because the DNS request over UDP took 2 seconds to time out, before dig reopened it over TCP.

I was using DigitalOcean, so the solution was to simply add an outbound rule to my firewall that allowed all UDP traffic over all ports and destinations:

Now, if I ran dig without +tcp:

time dig google.com +short

I'd get quick response times here as well:

172.217.169.14

real    0m0.011s
user    0m0.009s
sys     0m0.000s

Conclusion

When it comes to firewalls, things are not always black and white. It's true that they either allow traffic or they don't, but the end result might not be so clear-cut. Apparently, denied traffic can cause applications to switch protocols in the background and silently slow things down.

Special thanks to Bobby Iliev(opens in new tab) for helping me out(opens in new tab).