Introduction

Recently, I encountered a challenging issue while working with a machine (10.7.0.12) connected via a WireGuard VPN, with the host at 10.7.0.1. The core problem was a lack of internet access, despite a functioning network connection. This blog post details the steps I took to diagnose and resolve this DNS-related issue.

The Problem

While SSH’d into 10.7.0.12, I realized I couldn’t access the internet. The first hint of trouble came when I tried pinging Google:

ping google.com
ping: google.com: Temporary failure in name resolution

This error pointed towards a potential DNS issue, especially since my SSH connection was active, indicating that the network was operational.

Diagnosing the Issue

To further investigate, I ran nslookup to check DNS resolution:

nslookup google.com
;; communications error to 10.7.0.1#53: connection refused
Server:        127.0.0.53
Address:    127.0.0.53#53

** server can't find google.com: SERVFAIL

These results confirmed that DNS queries to 10.7.0.1 were being refused, despite the machine itself being reachable (verified by pinging 10.7.0.1).

Resolving the Issue

Step 1: Local DNS Test on the Host

On the host machine (10.7.0.1), I tested DNS resolution locally with nslookup google.com 127.0.0.1, which worked fine. This hinted that the issue might be related to a firewall configuration.

Step 2: Checking and Updating Firewall Settings

Using ufw status numbered, I discovered that the IP I was using wasn’t on the allowlist. After adding it and restarting the dnsmasq service, I was able to resolve DNS queries from 10.7.0.12.

Step 3: Configuring Conditional DNS Forwarding

However, a new requirement emerged: I needed to ensure that only DNS queries for domains ending in .ds were forwarded to 10.7.0.1. To achieve this, I configured dnsmasq on 10.7.0.12:

echo 'server=/ds/10.7.0.1' | sudo tee -a /etc/dnsmasq.conf
sudo systemctl restart dnsmasq

Note you need to have server=8.8.8.8 or something as well in order to resolve dns normally. Otherwise 127.0.0.53#53 cannot resolve DNS.

Step 4: Verifying the Configuration

Finally, I verified that DNS queries for .ds domains were correctly directed to 10.7.0.1, while others were handled locally on 10.7.0.12. This was done using dig or nslookup with different domain types.

Conclusion

In this case, a combination of firewall adjustment and DNS forwarding configuration resolved the internet access problem.