Every time you open a website, your device asks another server for the address. That server is almost always run by your ISP by default, or by Google, or Cloudflare, and the operator of that server gets a log of every site you visit. Most people have never thought about this. The reason they should start thinking about it is not paranoia. It is that the piece of plumbing that turns names into addresses is owned by someone else, and that is the part of the chain you actually have room to fix.
According to the source guide I followed, self-hosting your own lookup server with Technitium on an Asustor NAS is one of the cleaner ways to take that plumbing back. I have been running it on my own setup for a few weeks, and the value is less about privacy theater and more about having a piece of network infrastructure that I can actually see and adjust.
This is not a step-by-step install guide. The internet already has plenty of those, and most of them are good. What I want to do here is talk through the decisions that the install guides skip, the things that you only learn by running the stack for a few weeks and watching the dashboard.
What changes when you own the lookup server
Most people think of DNS as a single thing. It is actually a chain. Your device asks a resolver, the resolver asks the authoritative server for the address, and the answer comes back. In the default setup, the resolver is your ISP’s resolver, and the ISP sees every name you ask about. The TLS handshake that protects the rest of your connection does not protect the lookup, because the lookup happens before the secure connection is even established.
Self-hosting shrinks the chain. Your devices ask your NAS, your NAS asks an upstream provider (Cloudflare, Quad9, whatever you pick), and the only party who sees both ends is you. Your ISP sees that you talked to your NAS, which they already knew because it is on your network. The upstream provider sees that someone is using their service, but not who on your network made each query. The lookup itself stays in your house.
The framing is the main thing. This is not a privacy silver bullet. It is a piece of plumbing you control. Plumbing that you control is meaningfully different from plumbing that someone else controls, and most people have not thought about which version of the plumbing they are using.
What you actually need before you start
The honest answer is that you need a piece of hardware that is always on, on your home network, and reachable from every device you want to point at it. An Asustor NAS running ADM is one of the cleaner options for this, because the Asustor platform already expects you to run a bunch of containerized services on the device. Any recent model will work, and the only software requirements are that Docker is installed and that you have a way to manage stacks.
You will also want Dockhand, a web-based tool that wraps the Docker CLI (the command-line interface for running containers) in a browser-friendly UI. It is not part of the look-up server itself, but it makes the deployment repeatable in a way that is hard to get from the raw CLI. Treat it as setup overhead that pays for itself the second time you need to redeploy the stack.
A couple of warnings to internalize before you click through anything:
- If you already have a different DNS service running on your NAS, stop it first. The standard DNS port is 53, and two services cannot bind to it at the same time. Pick one approach and stick with it.
- Give your NAS a static IP address, or set a DHCP reservation on your router (a setting that always gives the NAS the same IP). If your NAS IP changes every time the router restarts, your devices will lose access to the lookup server and your internet will quietly break. This is the kind of thing that drives people crazy two weeks after setup when nothing seems wrong but nothing works.
The installation pattern that any of these tools share
The install flow for Technitium is the same shape as the install flow for AdGuard Home, Pi-hole, and a dozen other self-hosted network tools. Connect to your NAS through File Explorer, create a single folder for the data, open your Docker management UI, paste a compose file, deploy, wait for the healthcheck to flip green.
That is the whole sequence. The interesting decisions are not in the install. They are in the configuration that follows.
The two configuration choices that matter most are which upstream resolver you trust, and which blocklist you start with. The upstream resolver is whatever your NAS asks when it does not know a name. Cloudflare at 1.1.1.1 and Quad9 at 9.9.9.9 are the two most common defaults. Both are privacy-respecting. Both have their own logging policies. Read them before you commit.
The blocklist decision is the one that bites people. The temptation is to start with the most aggressive list you can find, roll it out to the whole household, and feel good about yourself. The reality is that an aggressive blocklist will break banking sites, school portals, work VPNs, and a hundred other things that you did not realize depended on the network being able to reach a specific domain. Start with the smallest list that does what you actually want, give it a week, and expand from there.
Where the dashboard earns its keep
Once the stack is up and your devices are pointing at it, the value compounds. The dashboard shows every query in real time, which sounds gimmicky but is actually useful for spotting patterns. You can see which devices on your network are chatty, which sites are being asked for repeatedly, and which lookups are failing. That last category is the one I found most useful. Failing lookups often mean misconfigured smart home devices, expired certificates, or DNS rebinding (a small attack where a hostile name resolves to a private IP) attempts that you would otherwise miss.
You can also set up local DNS entries for your smart home devices. If you have a printer or a NAS or a media server that you want to reach by name instead of IP, you can give it a friendly hostname and never type an IP address again. The dashboard makes this configurable with a single form, and the changes apply immediately.
The export feature is the part that surprised me. Every query, every block decision, every failed lookup is logged in a file you can read. If you ever need to debug a network issue, or answer the question of whether a particular device on your network is acting up, you can grep the log and find the answer in seconds. That is the kind of visibility you do not get from the default ISP resolver.
Trade-offs
This kind of setup is for people who have already decided that handing their network logs to a third party is the wrong default, and who are willing to maintain a small piece of self-hosted infrastructure in exchange for control. The maintenance burden is real but tiny. The container updates itself when you redeploy the stack. The data lives in a folder you control. The dashboard is good enough for everyday use.
A few things I would tell past me before installing:
- Pick a blocklist before you turn this on for the whole household, and start small
- Set a static IP or DHCP reservation on your NAS before you point devices at it, or the next router restart will break things silently
- Plan for the time it takes to update the DNS settings on every device, and do not skip the per-device test phase
- Expect the first half hour to feel like setup busywork, and the next six months to feel like peace
You do not need every query logged. You need a system that lets you answer the question of who knows what your network is doing without squinting at your ISP’s terms of service. That is what self-hosting this kind of tool does well, and that is why Asustor owners with a free weekend are increasingly running one.