I get your point, but this is already solved in a much easier manner with an OprnWRT router (and GUI etc) and kind of a strawman's argument using DNS for that. OpenWRT comes out of the box even with social website toggles that require no configuration.
Granted, you still have to install OpenWRT, but I still think that running a root DNS isn't necessary for home setups.
Technitium advertises itself with being able to serve as a root DNS, in both its documentation and on their blog [1]. So I think my argument is still valid, as it's way too over engineered to be a simple, self-hosted, home lab solution for the problem at hand.
> Had to remove the slash to pass through cloudflare block
I was going to write: You can’t write a comment with the text / etc / hosts?!
But I tried it and got the CloudFlare block page. That’s pretty incredible that a tech focused forum blocks you for simply referencing a common file on all Unix file systems. What state a sad future we live in.
Are there any uostream DNS Servers that would allow you to just download the while database and then everything immediately after its TTL runs out? I can image it would be a lot of traffic.
That would be zone transfer and its generally not allowed by DNS servers. And there couldn't be a single DNS server to query from, instead you would need to recursively query all the DNS servers which also is not exactly practical.
No. I use adguardhome to act as a private DNS for my android devices. It's the best way to get both DNS for self hosted services AND DNS filtering to remove tracking and ads in all android apps.
You can at least partially mitigate this by simply blocking the major DNS-over-https endpoints. There aren't that many. However, in my experience this really pisses off some devices e.g. Google/Nest Home speakers even if you have regular DNS working fine. You also of course won't catch the really nefarious devices phoning home over a custom non-public endpoint. It can be interesting just for logging purposes as well, that's what I do.
Yep, playing whack-a-mole trying to block it is a losing battle long term, but for now it kinda works. Serving content from the same endpoints is indeed the whole point because it makes it hard to block without collateral damage.
Probably the only way to really block it is some kind of SSL unwrapping and deep packet inspection at the firewall but that's a HUGE hassle to deal with and is itself a potential privacy issue.
Personally, I think DoH was a mistake. Instead of the network admin configuring the name resolution services (via DHCP, for example) each app has a hard-coded list of IP addresses that it will use to resolve hostnames. Instead of a system resolver that does the job we now have a resolver, complete with hard-coded server configuration, baked into various applications/devices.
Have you registered these domains? I’ve seen a lot of companies use “internal” domains that they don’t register and then are surprised when names they didn’t register end up resolving unintentionally to something external.
Its actually much more beneficial to use a local DNS server even for a single user. A single user will keep querying for DNS requests since OS/apps cache DNS only for a minute or so. Local DNS will keep cache for the full TTL of the record and thus reduce the number of DNS requests that go out of your network. Plus there is Serve Stale feature which improves resiliency. For privacy, depending on your scenario, you can either run recursive resolver or use encrypted DNS protocols to hide DNS from your ISP. There is also support for configuring SOCKS5 or HTTP proxy to route requests via another server or via Tor network.
Self-hosting allows you to block trackers at the DNS level. =) Depending on your level of hands-on you can block rentable infrastructure that trackers use and whitelist the apps which coincidentally also rent compute in that space. You can also use resolution telemetry to synthesize PTR records so that reverse DNS works for assets in the the cloud.
In order to accomplish those things I rely on Response Policy Zones and Dnstap, features which I don't see listed for this server. Nonetheless it does have filtering capability and decent coverage of features important to the average internet user, based on their listed features.
[I give away the RPZ / Dnstap stuff on GitHub, and I use BIND.]
I started on PiHole and moved to AdGuardHome and eventually landed on Technitium. I have a large home network and it does auto reverses and multiple record types that the others didn't. I really like Technitium.
Could you please explain what auto-reverse and multiple record types mean? The reason for asking is to learn what's missing from AG Home/DNS and maybe adding it in the future.
Auto-reverse means Auto RDNS zone creation. Where you're usually trying to translate hostnames to ip addresses, a reverse lookup translates an ip address to a hostname.
So, if I have an internal record, record.example.com @ 192.168.1.2, I can query the server to ask "Hey, who is at 192.168.1.2?" and the server would reply with "record.example.com". This works by creating not only the example.com zone, but also a "1.168.192.in-addr.arpa" zone with the proper mappings. Technitium server will ask you to create the zone if it doesn't already exist when you create an A record for a zone.
I went from piHole running in a container to this. All those weird spinners on youtube and unexplained confusing issues went away. This thing is awesome.
The functionality is massive. It is like going from Openwrt to mikrotik.
The only thing I find disturbing is, being a .net app, htop shows it using 100s of gigs of ram. I don't know what is going on with that, as it runs well and does not add any load to the host. Apparently it is normal dotnet thing.
Trying to post a listing but cloudflare seems to block me from saying anything but one line.
VSZ RSS
275156560 151048
using lxc info Memory 276.90MiB Swap 16.00KiB
wow, that is a PITA, just trying to be helpful. Anyway, seems a lot of virtual but next to no real memory.
edit: as I said, aside from the scary VM size, very small. I only have 60 local hosts though.
edit: ps, the dhcp/dns integration first class.
I have a few networks and run a couple of dhcp namespaces and it all works perfectly, with multiple routes distributed. I could never get that going with piHole. I was running dndmasq for years before that.
Can't add anything for the first question, but as for the second
>what does this do better than pi-hole does?
I block or redirect a few external DNS servers, like Google's, to a local DNS server and some devices go absolutely abeshit if the reply doesn't look like they expect. Like thousands of DNS lookups in minutes. Enough to kill pi-hole both on an RPI4, but also running on the same server as Technitium (dual Xeon proliant). So it seems it is more robust?
It does what pi-hole does and a lot more. Has encrypted DNS protocols like DNS-over-HTTPS, DNS-over-TLS, and DNS-over-QUIC support and also has built-in recursive resolver.
Sure, but its not what pi-hole does or support. You need to install another software and forward requests to it. Technitium DNS has this feature built-in along with support for DoT and DoQ, including support for DoH/3.
If you are looking for self hosting local resolver then just make sure its not accessible from public Internet. If you wish to host your own authoritative DNS server for your domain names then just configuring query rate limiting will mitigate DoS or DNS amplification attacks. I have been self hosting all my domain names since 2+ years now and its not much of an issue.
This is my only gripe as compared to AdGuard Home.
However, Technitium is miles ahead in terms of raw customization. One such example is synchronizing DNS servers. Unlike AdGuard Home you have to resort to an additional app [1], with technitium you do proper NS transfer [2].
Hosting own DNS Server at home that blocks some domains freaks me out. I have never run it, so don't know. But comparing to just running AdGuard on my macOS, there are some times, that website would not open or behave without AdGuard being turned off. It is easy to do on my local macOS, but in case of using AdGuard as DNS Server on my home network - that will require more steps.
Also, even if you run AdGuard as DNS on local network, you still need to run it on your macOS, if you are planning to travel.
I think it's just a tradeoff. I run Pihole and it does occasionally block things that I need, but it's rare. When it happens I log into the dashboard, look at what was recently blocked, and permanently unblock it if needed. On the plus side, fewer to no ads on all devices including mobiles.
For a sole user, yours is definitely a great way to economically utilize a single PiHole at home.
A suggestion for tho$e with multiple users: set up multiple PiHoles on your same network, then have "blocking levels" which each user can set up, e.g: 192.168.0.2 x.x.x.3 x.x.x.4 x.x.x.5 x.x.x.n
My DHCP auto-issues the "lowest level of blocking" PiHole to any client not specifying their own DNS (only 7 rules, mostly blocking pagead2 and doubleclick). Phones all point to a phone-specific local PiHole IP (which allows them to do phone-ier things). From there, users can block more ads simply by increasing the DNS IP by x.x.x.+1 [until shit stops working for them, then bump down 1].
For malingering DNS resolution issues, I'll sit down with the user/client and help them "massage the blocks" between x.x.x.n , but this is rare after the initial week or so of setup.
This also allows individual clients to entirely bypass your PiHoles, simply by them manually setting their DNS to x.x.x.1 [i.e. their router's IP].
----
YES I know that you can have a single PiHole resolve differently based on client IP, but my above solution allows for a much-simpler "levels of DNS protection" that most non-technical users can understand/modify, themselves. It is not inexpensive =D
My pihole is filled with my TV requesting analytics domains, pihole also blocks some ads on my phone. Probably my biggest annoyance is that google product suggestions are blocked when I generally want them.
I would say it’s a trade off, but with a positive value.
malware and other spying apps (like your television) are just adopting DNS over HTTPS (DoH) and bypassing whatever local DNS server you have deployed on your network, pihole and such are quickly becoming irrelevant.
Have you found any open resolvers that are using a shared CDN IP? I've been on the lookout for those ever since the first discussion of DoH appeared on HN. I have yet to find one but I would really like to know details if you have found one. Thus far I have been able to block DoH by NXDOMAIN'ing "use-application-dns.net" and blackhole routing about 80 IP addresses.
You can block HTTPS to known DoH providers. You can set up an alias in a firewall to load the list from https://public-dns.info/nameservers-all.txt. Its a bit of a cat-and-mouse game as it relies on that list being updated frequently and reliably, but its the best you're gonna get for blocking DoH.
Also make sure to block outgoing TCP and UDP 853 – this blocks DoT and DoQ too.
Who is behind this software and what's their motivation for it?
PiHole is very simple in that regard, it was created by some dude to fill a niche and has grown into a reasonably robust community which should be reasonably resilient to outside attacks (someone sneaking in a change which adds a "feature" which exfiltrates and sells my data).
AdGuard also is a very known company with an obvious motive, to sell you their software, but they've been around a long time and are widely used and seem relatively harmless.
I'm sure I'm a cynic at this point, but, I feel like I need to know who these guys are and why they are willing to invest in this.
If you look at sponsors that might answer your question. Someone is using the software in their product and making money so they would sponsor the developers, probably nothing more to it than that. Think open source can be a way for multiple companies to pull their resources and build software that they both need.
It's good to be skeptical, but we should also welcome newcomers since that provides resiliency in cases where well established options shutdown or get subverted themselves. I might not run this on my own network personally, but it seems worth keeping an eye on. It's good having options, especially open source options. This project may even result in improvements being made to PiHole or AdGuard!
Look at a graph of the use of the term "Technitium" on various social media over the last week and you get a glimpse onto what is an obvious concerted influencer campaign.
Glad Technitium is getting its day on HN! I've been using this for around six months now, did a deployment on my home network after rebuilding it from scratch. Multiple zones, forward zones, hosting SOA for internal domains, DNSSEC. Hands down the BEST modern DNS infra you can deploy if PiHole doesn't fit all of your needs. I'm running it on a Raspberry Pi 4 alongside my Unifi controller with zero issues!
Using Technitium on your local network is like rolling your own Route 53 management console internally. I hate to use that comparison, but I think that'll hit more for some users on HN! If you need that kind of fine grained control, or if you just don't want your hand held on DNS, that is why you would choose this over PiHole.
Thank you to the Technitium team for giving us such a great product! Even if your name is hard to spell.
86 comments
[ 3.0 ms ] story [ 183 ms ] thread(Had to remove the slash to pass through cloudflare block)
Granted, you still have to install OpenWRT, but I still think that running a root DNS isn't necessary for home setups.
[1] https://blog.technitium.com/2021/07/running-root-server-loca...
I was going to write: You can’t write a comment with the text / etc / hosts?!
But I tried it and got the CloudFlare block page. That’s pretty incredible that a tech focused forum blocks you for simply referencing a common file on all Unix file systems. What state a sad future we live in.
Works for one computer, doesn’t scale.
https://en.wikipedia.org/wiki/DNS_zone_transfer
Edit: another option allows for serving expired TTLs, which is permitted by rfc. There is a great explanation on their site [2]
[1] https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound...
[2] https://unbound.docs.nlnetlabs.nl/en/latest/topics/core/serv...
https://jpgpi250.github.io/piholemanual/doc/Block%20DOH%20wi... really digs into the nitty gritty of how to do it to a crazy extent.
Probably the only way to really block it is some kind of SSL unwrapping and deep packet inspection at the firewall but that's a HUGE hassle to deal with and is itself a potential privacy issue.
Personally, I think DoH was a mistake. Instead of the network admin configuring the name resolution services (via DHCP, for example) each app has a hard-coded list of IP addresses that it will use to resolve hostnames. Instead of a system resolver that does the job we now have a resolver, complete with hard-coded server configuration, baked into various applications/devices.
I run my own DNS, I would have said all the same things they did.
- Local caching reduces upstream queries significantly, making it much harder for upstream to profile you.
- Encrypt DNS traffic for incompatible devices.
In order to accomplish those things I rely on Response Policy Zones and Dnstap, features which I don't see listed for this server. Nonetheless it does have filtering capability and decent coverage of features important to the average internet user, based on their listed features.
[I give away the RPZ / Dnstap stuff on GitHub, and I use BIND.]
So, if I have an internal record, record.example.com @ 192.168.1.2, I can query the server to ask "Hey, who is at 192.168.1.2?" and the server would reply with "record.example.com". This works by creating not only the example.com zone, but also a "1.168.192.in-addr.arpa" zone with the proper mappings. Technitium server will ask you to create the zone if it doesn't already exist when you create an A record for a zone.
https://knowledge.digicert.com/constellix/standard-dns/rever...
Do you mind elaborating on what this means real world in terms of what that allows you to do?
And about 150M of virtual memory on my rpi.
Edit: Argh, I thought you meant pihole, sorry for the confusion
wow, that is a PITA, just trying to be helpful. Anyway, seems a lot of virtual but next to no real memory.
edit: as I said, aside from the scary VM size, very small. I only have 60 local hosts though.
edit: ps, the dhcp/dns integration first class. I have a few networks and run a couple of dhcp namespaces and it all works perfectly, with multiple routes distributed. I could never get that going with piHole. I was running dndmasq for years before that.
>what does this do better than pi-hole does?
I block or redirect a few external DNS servers, like Google's, to a local DNS server and some devices go absolutely abeshit if the reply doesn't look like they expect. Like thousands of DNS lookups in minutes. Enough to kill pi-hole both on an RPI4, but also running on the same server as Technitium (dual Xeon proliant). So it seems it is more robust?
However, Technitium is miles ahead in terms of raw customization. One such example is synchronizing DNS servers. Unlike AdGuard Home you have to resort to an additional app [1], with technitium you do proper NS transfer [2].
[2] https://github.com/bakito/adguardhome-sync
[1] https://reddit.com/comments/s91oo5/comment/htk9jnt
Also, even if you run AdGuard as DNS on local network, you still need to run it on your macOS, if you are planning to travel.
A suggestion for tho$e with multiple users: set up multiple PiHoles on your same network, then have "blocking levels" which each user can set up, e.g: 192.168.0.2 x.x.x.3 x.x.x.4 x.x.x.5 x.x.x.n
My DHCP auto-issues the "lowest level of blocking" PiHole to any client not specifying their own DNS (only 7 rules, mostly blocking pagead2 and doubleclick). Phones all point to a phone-specific local PiHole IP (which allows them to do phone-ier things). From there, users can block more ads simply by increasing the DNS IP by x.x.x.+1 [until shit stops working for them, then bump down 1].
For malingering DNS resolution issues, I'll sit down with the user/client and help them "massage the blocks" between x.x.x.n , but this is rare after the initial week or so of setup.
This also allows individual clients to entirely bypass your PiHoles, simply by them manually setting their DNS to x.x.x.1 [i.e. their router's IP].
----
YES I know that you can have a single PiHole resolve differently based on client IP, but my above solution allows for a much-simpler "levels of DNS protection" that most non-technical users can understand/modify, themselves. It is not inexpensive =D
I would say it’s a trade off, but with a positive value.
Insidious things, tsk tsk.
Also make sure to block outgoing TCP and UDP 853 – this blocks DoT and DoQ too.
Who is behind this software and what's their motivation for it?
PiHole is very simple in that regard, it was created by some dude to fill a niche and has grown into a reasonably robust community which should be reasonably resilient to outside attacks (someone sneaking in a change which adds a "feature" which exfiltrates and sells my data).
AdGuard also is a very known company with an obvious motive, to sell you their software, but they've been around a long time and are widely used and seem relatively harmless.
I'm sure I'm a cynic at this point, but, I feel like I need to know who these guys are and why they are willing to invest in this.
Using Technitium on your local network is like rolling your own Route 53 management console internally. I hate to use that comparison, but I think that'll hit more for some users on HN! If you need that kind of fine grained control, or if you just don't want your hand held on DNS, that is why you would choose this over PiHole.
Thank you to the Technitium team for giving us such a great product! Even if your name is hard to spell.