Learn.GTArsenals
Search

DNS Failure

Isolating DNS problems from routing problems when 'the Internet is down' but connectivity is actually fine.

1. Rule out routing entirely

If a user reports “the Internet is down”, you must first determine if it’s a routing/NAT issue or a DNS issue.

From a PC on the LAN, or from the router’s terminal:

  1. Ping a public IP: ping 8.8.8.8
  2. Ping a domain: ping google.com

If #1 succeeds but #2 fails with “Could not resolve”, the problem is isolated to DNS. Your routing and NAT are fine.

2. Who is providing DNS to the clients?

Look at the DHCP server configuration. What DNS server is the router telling the PCs to use?

CLI Check:

/ip dhcp-server network print
  • Scenario A: The dns-server is set to 8.8.8.8. The PCs are querying the internet directly. Check if your firewall is blocking outbound UDP/53.
  • Scenario B: The dns-server is set to the router’s LAN IP (e.g. 192.168.88.1). The router is acting as a DNS cache/relay. Proceed to step 3.

3. Check the router’s own DNS settings (Scenario B)

If the PCs are asking the router for DNS, the router must be configured to answer them, and it must know who to ask upstream.

CLI Check:

/ip dns print
  1. allow-remote-requests MUST be yes: If this is no, the router will ignore DNS requests from your LAN PCs.
  2. servers must have upstream IPs: If this is blank (and you aren’t receiving dynamic DNS servers from your ISP via DHCP/PPPoE), the router doesn’t know how to resolve the names. Add servers=8.8.8.8,1.1.1.1.

4. Check the Firewall (Protecting your DNS server)

If you enabled allow-remote-requests=yes, your router will now answer DNS queries. WARNING: It will answer queries from anyone, including the entire internet, if you haven’t firewalled your WAN port. This makes your router vulnerable to DNS Amplification DDoS attacks.

Ensure you have a rule dropping incoming WAN traffic on the input chain:

/ip firewall filter print
# You must have a rule like:
# action=drop chain=input in-interface=ether1

If your LAN PCs still can’t resolve DNS, ensure you don’t have a rule at the top of the input chain that is overly aggressive and accidentally dropping UDP/53 from the LAN side.