How to Use Pi-hole or AdGuard Home With Starlink

Starlink provides the internet connection, while DNS decides which network address a device should use for a website or service. A local DNS filter such as Pi-hole or AdGuard Home can block advertising and tracking domains, create allow and deny lists, and give you a useful view of household DNS requests.

The filter does not improve satellite visibility, reduce congestion or replace a firewall. It can also make an otherwise healthy connection look broken when a required domain is blocked. The reliable approach is to give the filter a stable local address, point the correct network device at it, test from more than one client and keep a recovery path.

Decide which network layout you have

Before installing anything, identify which device is handing out local IP addresses. That device is normally the DHCP server, and it is the place where network-wide DNS should be configured.

Starlink Router is doing the routing

Run Pi-hole or AdGuard Home on a small computer, NAS or other always-on device on the Starlink LAN. If the Starlink router exposes a LAN DNS setting for your model, advertise the filter's local IP address there.

If the Starlink router does not let you replace the DNS server, you have two practical choices:

• Configure DNS on individual devices for a small test or a household with only a few clients.
• Use a compatible third-party router as the main router, then advertise the filter through that router's DHCP settings.

Do not assume that an ordinary wireless access point can advertise DNS. In access-point mode it usually extends the existing network while the Starlink router continues to provide DHCP.

Your own router is in charge

If you use Starlink in bypass mode with a third-party router, install the filter on the main LAN and set the third-party router's DHCP DNS option to the filter's local IP address. The exact menu name varies: look for LAN, DHCP, DNS server or network settings.

This is usually the cleanest arrangement because one router controls addressing, guest networks and DNS distribution. Establish ordinary internet access first, then change the DNS setting and test it before adding blocklists or other network features.

For background on the routing choice, see How to Use Your Own Router with Starlink Bypass Mode.

The filter runs in a container

A container on a NAS, mini PC or server can work well, but the network path must be clear. The DNS service needs to be reachable from your LAN over both UDP and TCP port 53, and the host needs a stable local address.

Container networking varies by platform. Follow the current instructions for the product and container system you use. Do not expose the DNS service or its administration page to the public internet, and do not make the rest of the household depend on a host that regularly sleeps.

Prepare the device that will run the filter

Choose a device that stays powered on whenever people need the internet. Ethernet is preferable for an always-on resolver, although Wi-Fi can be useful for a temporary test.

Before installing:

• Update the device and set a strong local administrator password.
• Give it a DHCP reservation in the router that controls your LAN, or use a properly managed static address.
• Record the device name and local IP address.
• Make sure the device clock and time zone are correct.
• Confirm that you can reach its administration page from a normal LAN client.
• Decide how you will recover if the device is powered off.

A DHCP reservation is often easier to maintain than a manually chosen address. It lets the router continue managing the address while ensuring the filter receives the same value. See How to Set Up a Starlink DHCP Reservation for Stable Local IPs for the general principle.

Do not install the filter on the Starlink dish or assume the Starlink router itself is a general-purpose Linux host. The filter belongs on a separate device on your local network.

Install the DNS filter with a recovery plan

Use the current installation instructions for Pi-hole or AdGuard Home and start with the product's normal, documented defaults. Do not add a large collection of third-party lists before basic DNS resolution works.

During setup:

1. Set a unique administration password.
2. Choose an upstream DNS provider you trust.
3. Limit the DNS listener to the local network unless your product documentation requires another mode.
4. Keep the administration page reachable only from your LAN or a private management network.
5. Note the filter's local IP address and the DNS service status.
6. Confirm that the filter can resolve an ordinary domain before changing the whole household.

The upstream provider still receives the DNS requests that your filter forwards. A local filter changes where your devices send their questions; it does not make DNS anonymous. Review logging and retention settings, and choose an upstream service that fits your privacy requirements.

Point the network at the filter

Change one layer at a time. The most useful setting is normally the LAN DHCP DNS setting on the router that serves your clients.

Set the primary DNS server to the filter's local IP address. If your router offers a secondary DNS field, be careful: adding a public resolver as the secondary can let clients bypass the filter whenever the router decides the primary is slow. If filtering is the goal, use the product's documented fallback or high-availability design instead of an unplanned public secondary.

After saving the router setting:

1. Disconnect and reconnect Wi-Fi on a test phone or computer.
2. Renew its network lease if needed.
3. Check which DNS server the client is actually using.
4. Open several normal websites and apps.
5. Confirm that the filter dashboard shows the test queries.

On Windows, you can run this in Command Prompt:

\\\ nslookup example.com \\\

On macOS or Linux, use:

\\\ dig example.com \\\

The result should identify the filter or the intended local DNS path. If it shows a public resolver, an unexpected router address or the old setting, the client has not yet adopted the new configuration.

Check IPv6 before calling the setup complete

A network can use IPv4 and IPv6 at the same time. If your filter handles IPv4 DNS but your router advertises a different IPv6 DNS path, some devices may bypass the filter without showing an obvious error.

Check whether your router and filter support IPv6 DNS advertisement. If they do, configure the filtered IPv6 path according to their current documentation and test it from an IPv6-capable client.

If your equipment cannot provide a consistent filtered IPv6 setup, treat the result as partial filtering. Do not claim that every device is covered, and do not weaken the firewall just to make the dashboard look complete. A temporary IPv6 test can help isolate the cause, but permanent network changes should be deliberate and documented.

Test the networks and devices people actually use

Test from the main household network, not only from the filter host. Check at least one wired client and one wireless client when possible.

Use a short checklist:

• Open ordinary news, search and streaming sites.
• Sign in to a service that you use regularly.
• Check a smart-home device or printer that needs local discovery.
• Confirm that the Starlink app still reports the connection normally.
• Look at the filter dashboard for recent queries.
• Test a guest network separately if you use one.
• Test a phone with any VPN, Private DNS or browser security feature enabled.

A guest network may intentionally use a separate DNS path or block access to local devices. That is a network design choice, not automatically a failure. Decide whether guests should use the filter, then configure that guest network explicitly.

Some phones, browsers, VPNs and apps use encrypted DNS or their own resolver. They may ignore the DNS server delivered by DHCP. If one device does not appear in the filter logs while other clients do, inspect that device's VPN, Private DNS, Secure DNS or browser settings before changing Starlink hardware.

Troubleshoot a broken site without disabling everything

If the internet appears offline immediately after the DNS change, check the filter host first. Is it powered on? Does it still have the reserved local address? Can you open its administration page from the LAN?

If the filter is unavailable, restore the previous DNS setting or use the documented fallback for your router. Renew the test client's lease and confirm that ordinary browsing works again. This separates a DNS service failure from a Starlink outage.

If only one site or app breaks:

1. Confirm that the service works on a different connection, such as mobile data.
2. Search the filter query log for the affected domain and related subdomains.
3. Allow only the required domain or category in the filter.
4. Clear the affected device's DNS cache or reconnect it to Wi-Fi.
5. Test again before changing another setting.

Avoid disabling every list as a first response. A narrow allow-list entry preserves most of the protection and gives you useful evidence about which domain was required.

If several unrelated sites fail, compare a filtered client with a client using the previous DNS setting. If the unfiltered client works, inspect the filter's upstream status, time synchronization, blocklists and local firewall. For a broader DNS investigation, see Some Websites Won't Load on Starlink? A DNS Troubleshooting Guide.

Keep the security boundary clear

A DNS filter is not a complete firewall, antivirus product or parental-control system. Keep the Starlink or third-party router firewall enabled, update the filter host, and use a strong administration password.

Do not port-forward the filter's DNS service or administration page. Do not publish its dashboard through a public hostname. If you need remote administration, use a private management VPN and limit access to the people who need it.

Review logs periodically. DNS logs can reveal household browsing patterns, so protect the dashboard and choose sensible retention. Back up the filter configuration if the product supports it, but do not store an administrator password in an unsecured note.

Roll back cleanly when needed

Write down the previous DNS setting before changing the router. To roll back:

1. Restore the router's DNS setting to its previous value or automatic mode.
2. Renew the client network lease or reconnect Wi-Fi.
3. Confirm ordinary browsing and essential devices.
4. Leave the filter powered on until you have confirmed that no client still depends on it.
5. Record what failed and which domain or network was involved.

A rollback does not require a Starlink factory reset. Avoid repeated power cycling of the dish or router when the evidence points to a local DNS configuration.

Quick decision guide

Use a local DNS filter when you want network-wide blocking, household allow-lists or a local record of DNS requests and you are comfortable maintaining one more always-on device.

Configure DNS on one device first when you are evaluating the idea or only need a personal block-list.

Use a third-party router when you need reliable network-wide DNS control, multiple LANs or a consistent guest-network policy that the Starlink router does not expose.

Expect exceptions. Some devices will use their own encrypted DNS, some guest networks are intentionally isolated, and IPv6 must be included if you want complete coverage.

Reviewed: 7 October 2026.