I’m starting to see something similar. On a system that was working perfectly, the DNS seems to have stopped working. Emails can’t go out because the system can’t resolve the smtp.gmail.com. Asterisk grinds to a halt if I use urls for my sip trunk host name. What would cause a system with working DNS (127.0.0.1, 8.8.8.8 and 8.8.4.4) to just stop working?
UDP and TCP port 53… (UDP for most queries, TCP if the reply gets too long or for things such as zone transfers (but this doesn’t apply in your case)…)
You were correct sir. Rebooting the router/firewall did the trick. Quick question on how DNS works and port opening. I’ve never opened ports on a router and yet DNS always works. Are we talking about opening ports on the outbound traffic? Port 53 for outbound UDP traffic? If this is the case then DNS could be problematic on locked down site that restrict outbound traffic?
Most people don’t lock down their outbound configuration on a firewall. Usually, they open the outbound up to just about everywhere and then keep that port open while the traffic is running.
With DNS, though, there is a wrinkle. If the response from the DNS server is too big or complex, the system will respond on “not opened by outbound traffic” TCP port. This means that most DNS queries will work just fine, but the big transfers may fail.
Since this is a well-understood side effect of the DNS protocol, most firewalls take this into account. If you firewall locked up on that port (with another request, for example) it’s possible that the reboot of the firewall was all that was needed to solve the problem.
If your servers/computers did not have their outbound traffic restricted that’s normal and for most LANs outbound traffic is unrestricted…
(It’s usually restricted for security reasons or to limit which sites your user browse…)
Yes… Oubound traffic to port 53 in both UDP and TCP…
(You would open inbound traffic if you were hosting a DNS accessible from the outside…)
TCP as well… TCP is used for zone transfers (which don’t apply in this case) but also in situations where the response is too long and things such as that…
I have such a locked down site (in a way and it’s because I wanted it that way…).
My PBX is in another segment (ie not the LAN) which doesn’t allow all traffic by default (essentially what enterprise grade routers/firewalls call a DMZ which is different from what a home router/firewall calls a DMZ) so I have to open ports for each protocol I want to allow outbound traffic to…
DNS is a special case as I could tell my PBX to use the DNS forwarder of my router/firewall but if I want to access any outside DNS I need to allow outbound traffic to port 53 UDP and TCP…
(“Real” DMZ in opposition to a “fake” DMZ, what the Wikipedia page calls a DMZ host…)
It will fall back to TCP which is why I recommend opening both UDP and TCP even though UDP will work fine most of the time…
If I recall correctly when the UDP reply gets too long a truncation flag gets set and the request can be redone (usually automatically by the resolver) in TCP (if the port is opened of course…).
Apparently the problem will get worse and worse as responses are increasingly getting bigger…
I would have to read up on it as I have not done DNS admin very actively in recent years (but I did for a very long period in the past).
