Set Up a Local DNS Server on Android with Termux

Why Run a DNS Server on Android?

Most Android users never think about DNS – the service that translates human‑readable hostnames into IP addresses. Having a local DNS server on your phone can be useful for several reasons:

• Ad‑blocking and content filtering without installing a separate app.
• Testing custom host mappings while developing web or mobile apps.
• Providing DNS for a small LAN when you have no router with DNS capabilities.
• Learning networking fundamentals on a device you already carry.

Because the solution uses only free, open‑source tools (Termux and dnsmasq) it works on the majority of Android devices, regardless of manufacturer or carrier.

Before You Start

If you cannot or do not want to root the phone, the tutorial shows how to run dnsmasq on an unprivileged port (e.g., 5353) and how to point other devices to that port using IP:port syntax where the Android UI allows it.

Step 1 – Install Termux and Update Packages

After the upgrade, you should see a prompt similar to ~$. You are now ready to install dnsmasq.

Step 2 – Install dnsmasq

If the command fails, double‑check that you have a stable internet connection and that the pkg repositories are reachable.

Step 3 – Create a Basic dnsmasq Configuration

dnsmasq reads a configuration file called dnsmasq.conf. We will create a minimal version that works for most testing scenarios.

At this point you have a ready‑to‑run configuration. The next step is to make the Android Wi‑Fi interface reachable by other devices.

Step 4 – Turn Your Phone into a Wi‑Fi Hotspot (Optional but Recommended)

If you want other devices on the same network to use the DNS server, the easiest method is to enable Android’s built‑in hotspot feature. This creates a private Wi‑Fi network where your phone acts as the router.

Now the phone’s Wi‑Fi interface (often reported as wlan0) has a stable address that clients can reach.

Step 5 – Start dnsmasq

Running dnsmasq is as simple as invoking the binary with the configuration file we created.

If the process exits immediately, check the log file you defined earlier (/data/data/com.termux/files/usr/var/log/dnsmasq.log) for clues.

Step 6 – Point Clients to Your New DNS Server

Now that dnsmasq is listening on the phone’s hotspot IP (e.g., 192.168.43.1), you need to tell other devices to use it for DNS resolution.

Option A – Change DNS Settings on the Hotspot Client

1. On the client device (another Android phone, laptop, etc.), open the Wi‑Fi settings for the hotspot network.
2. Look for an “Advanced” or “IP settings” section. Switch from “DHCP” to “Static”.
3. Enter the following values (adjust the IP if your hotspot uses a different subnet):
   • IP address: any free address in the hotspot’s range, e.g., 192.168.43.10.
   • Gateway: 192.168.43.1 (the phone).
   • DNS 1: 192.168.43.1.
   • DNS 2: optional – you can leave blank or use a public DNS as fallback.
4. Save the settings and reconnect to the network.

After reconnecting, the client will send DNS queries directly to your Android phone.

Option B – Use a Non‑Privileged Port (No Root Required)

Some Android UI layers do not allow you to specify a custom DNS port. In that case you can run dnsmasq on a higher port (e.g., 5353) and use the iptables redirection trick. This method requires root because iptables manipulates the kernel’s network stack.

Clients can now keep the default DNS settings (pointing to 192.168.43.1) and the redirection will handle the port conversion.

Step 7 – Test the DNS Server

Testing confirms that the server is reachable and that custom mappings work.

If the client reports “timed out” or “server not reachable”, re‑verify the IP address of the hotspot, ensure the phone’s Wi‑Fi interface is still up, and confirm that the wake lock is active (run termux-wake-lock -s to see status).

Troubleshooting Common Issues

• dnsmasq fails to start with “permission denied”
  • Cause: Attempting to bind to port 53 without root.
  • Fix: Either run dnsmasq on an unprivileged port (e.g., 5353) as described in Option B, or root the device and allow binding to 53.
• No DNS responses from the client
  • Check that the client’s DNS setting points to the correct IP (the hotspot’s gateway).
  • Verify that the hotspot is still active; Android may turn it off after a period of inactivity.
  • Run ping 192.168.43.1 from the client to ensure basic connectivity.
• Log file is empty
  • Make sure the directory /data/data/com.termux/files/usr/var/log exists and is writable.
  • Create it manually if needed:

    mkdir -p /data/data/com.termux/files/usr/var/log

• dnsmasq stops when the screen turns off
  • Android may kill background processes to save battery. The termux-wake-lock command prevents the CPU from sleeping, but some OEMs still enforce aggressive task killing.
  • Solution: Install the termux:boot add‑on from the Play Store and add a script ~/.termux/boot/start-dnsmasq.sh that launches dnsmasq on boot. Also enable “Battery optimization” exclusion for Termux in Settings → Apps → Termux → Battery.

Advanced Use Cases

1. Using dnsmasq as an Ad‑Blocker for the Whole Hotspot

Replace the single address= line with a comprehensive blocklist. One popular source is the hosts file from StevenBlack. To import it:

# Download the hosts file (requires termux-api curl or wget)
curl -L https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts -o hosts.txt
# Convert to dnsmasq format (each line: address=/domain/0.0.0.0)
awk '/^0\.0\.0\.0/ {gsub(/^0\.0\.0\.0[ \t]+/, ""); print "address=/" $1 "/0.0.0.0"}' hosts.txt >> dnsmasq.conf

After updating the file, restart dnsmasq (kill the old process and start a new one). All devices connected to the hotspot will now benefit from the blocklist without installing any extra apps.

2. Custom Host Overrides for Development

When testing a web service that is not yet publicly reachable, you can map a hostname to your development server’s IP:

address=/my‑test‑api.local/10.0.0.42

Clients that resolve my-test-api.local will connect directly to 10.0.0.42. This is handy for mobile‑first developers who need to test on real devices.

3. Using dnsmasq for DHCP (Experimental)

dnsmasq can also serve DHCP leases, but Android’s built‑in hotspot already runs a DHCP server on port 67. Running a second DHCP server on the same interface will cause conflicts. If you disable the hotspot’s DHCP (possible only on rooted devices or custom ROMs), you can enable it in dnsmasq by adding:

dhcp-range=192.168.43.50,192.168.43.150,12h

Because this tutorial targets non‑root users, we keep DHCP disabled and rely on Android’s native implementation.

Cleaning Up – Stopping dnsmasq and Removing the Configuration

If you no longer need the DNS server, follow these steps to shut it down cleanly.

All log files are stored inside Termux’s private directory, so they disappear when you delete the folder.

Security and Privacy Considerations

• Local network exposure – By default dnsmasq listens only on the Wi‑Fi interface, but if you later enable it on cellular data, any device on that network could query your phone. Keep the interface= line to limit exposure.
• Query logging – The log file contains every hostname queried by your clients. If you share the device with others, consider disabling log-queries or regularly truncating the log.
• Rooted devices – Using iptables redirection requires root. Granting root access to Termux gives the app full control over the device, so only do this on a device you trust.
• Public Wi‑Fi – Never enable the hotspot while connected to a public Wi‑Fi network, as it can unintentionally bridge traffic between networks.

Recap – What You Have Achieved

By the end of this tutorial you should be able to:

• Install Termux and dnsmasq on an Android phone without rooting.
• Configure dnsmasq to act as a lightweight DNS resolver that forwards to upstream servers.
• Run dnsmasq as a background service that survives screen lock.
• Direct other devices on the same hotspot to use the phone’s DNS server.
• Implement simple ad‑blocking or custom host overrides.
• Troubleshoot common startup and connectivity problems.

This capability turns a regular Android phone into a handy network tool for developers, privacy‑conscious users, and anyone who wants fine‑grained control over DNS on a small LAN.