Pihole still offers nice things that a cloud solution can't, like local network resolution and DHCP.
Not everyone sees this as an advantage, and even if you do see it that way, you still might not need it. If PiHole works for you, keep using it. I actually want this because I want to share my adblocking/secure DNS setup with my less-technical friends and family, none of whom live with me/share a network/VPN. So needing no new software on their end, just a new resolver to be configured, is very appealing. It can work everywhere on all their devices and it's very easy to configure.
Taking it further: you can customize the DNS path as you wish with your own code in these designs. It's definitely not for everyone and if you like the convenience DHCP/local resolution provides, I wouldn't necessarily switch. But once you actually can like, use your DNS endpoint as an API, and you can configure your DNS resolver programmatically from any language anywhere via HTTP APIs, a lot of neat things become possible. I actually configure my custom DNS resolvers with custom service names pointing to my local devices already; I don't rely on just DHCP+hostname to provide the right resolvable name. And doing this can be as simple as a POST request to a custom endpoint I wrote; the resolver can then just serve custom A/AAAA records for those entries. So if you want flexibility/a custom DNS network, it's very appealing. But if you don't want it, I wouldn't worry about it much.
As an aside: for a generic replacement for pi-hole inside and outside one’s local network, NextDNS (it’s not self-hosted) works fine. It allows setting up ad blocking and tracker blocker filters from common filter lists, allows custom allow and deny lists, and provides 300k queries a month in the free plan (when this limit is exceeded, the DNS works but not the filter lists).
NextDNS/Adguard-DNS are more user friendly options.
You may be right, but a serverless resolver ain't anything I've seen before! Awesome project, and I'm glad to see that it all comw together-- not all projects do!
Let's say that the government / some central entity takes the blocking a step further by blocking Cloudflare's DNS-over-HTTPS (DoH) endpoint. I could just spin up a new instance on fly.io (or really any other service of your choosing), and use the new endpoint as the new DoH endpoint.
What I like about this service is the fact that I can still use a blocklist to block trackers & ads, just like how you would with NextDNS. Most of the services listed in the example page are pretty generous with their free plans, so the whole setup may end up being cheaper than the Pro plan[1] of NextDNS.
[0]: A number of quite essential services just got blocked by the government where I live, so this is a very real possibility.
Use cases: Block ads and tracking domains. Block malware domains. Parental control.
Bonus: Do all that over DoH/DoT to avoid ISP/government/hotel snooping or censoring.
I suspect this would impact latency. Any benchmarks done to compare Cloudflare workers, Deno and fly.io for this specific application (i don't think ping alone is fair)? I'm guessing fly.io is more suitable here. Also, DoH clients generally maintain a pool of connections to the DoH server i'm not completely sure how this is handled with something like Cloudflare workers.
Why is that?
Nope, thank you.
Living dangerously is one thing, being suicidal is another.
https://github.com/serverless-dns/serverless-dns/blob/main/s...
Fly.io simply boots a Linux kernel, and the Docker image you give it is then treated if it was full filesystem for that "instance". Whatever is in the container image is all you get. Many container environments aren't going to have init-like frameworks to initialize swap before booting the application; in fact the container only having say, node.js, a few .js files, and starting that immediately after kernel boot is actually a pretty good startup time optimization. So if you need swap space, because the runtime makes anonymous memory commitments larger than physical memory -- the only way to guarantee that is in the application path itself, like done here. You could also do a shell script I guess. You'd have to do this in any similar low-memory environment, really, if the init system didn't.
Seems reasonable; nothing too suspicious or odd in the long run. It's nothing you're going to need outside of these new-fangled container-like environments (besides, in this case, the shell commands are easily auditable and not in any way user-controllable through user input, vastly reducing defect surface area.) Took 10 minutes to audit and figure out if you've had some previous exposure to runtime tuning; comments to explain this would have been nice, though...
There is nothing "simply" in a Rube Goldberg machine of such magnitude.
On DoH you could put an API token in the URL. On DoT you could encode something similar in the `Host` header (though this isn't really secure as the SNI is retrievable so questionable how effective it really is and I'm not even sure if this is achievable on the edge runtimes).
Adding the DoH-token feature could still make sense, I guess? Unfortunately AFAIK Android supports only DoT, not DoH.
EDIT: This just in, DoH3 in Android: https://security.googleblog.com/2022/07/dns-over-http3-in-an...
Of that data, a relatively small fraction changes periodically. Most of it is static. Generally, I only do remote DNS data retrieval periodically, not immediately preceding each and every HTTP request when accessing a www site.
Every user is different but by controlling what RFC 1035 calls the "Master File" of DNS data I can avoid remote DNS lookups altogether. This speeds up www use for me, greatly. YMMV.
The point that get missed in these discussions, IMHO, is that DNS is not just an issue of speed.^1 (And users can improve speed without help from third parties.) DNS is also an issue of control. Controlling DNS allows me as a user to disable the www's dark patterns where the user selects a domain name to access and the "browser" connects to various domain names to which the user had no intention of connecting.^2 I can easily thwart unecessary, unwanted phoning home, telemetry, tracking and online advertising because they all rely on using DNS that is, to some degree if not wholly, outside the user's control.
1. For example, Google can undoubtedly win the race for DNS speed however the www user will always lose the contest over _control_.
2. Originally this auto-fetching feature may not have been intended to support "dark patterns". However its usage today is a key element of those practices. There are companies today whose vision for the www is shaped by a need for programmitic advertising and the privacy invasion that this requires. They puch for standards and protocols optimised to support "complex" web pages comprised of many components, potentially controlled by various third parties, the most important of which are related to _advertising_. A www user might have a different vision. For example, I am able to use the www quite effectively for informtation retrieval (not commerce) without using auto-fetching.^3 I treat www pages as "simple" ones with only one significant component and none controlled by third parties. This allows me to consume larger quantities of information more rapidly, with less distraction. "Simple" www pages are more valuable to me than complex ones. Though they might be less valuable to "tech" companies seeking to sell advertising services.
3. Common Crawl, the source for much-hyped "AI" projects such as GPT-3, uses the www in a similar way. There are no components for "complex" websites such as Javascript files in the archives.
What this means is that I do not need to store entire zone files. I only need to store the data for the domain names I will use. The point about storage capability is that this is no longer a limiting factor. When I started using the www, storage space was a limiting factor. I could not store the DNS data for every name I would ever use on a personal computer. Even the RAM on today's computers can be larger than the size of HDDs from the time when I started using the www. Everything has changed.
"For example, I am able to use the www quite effectively for information retrieval (not commerce) without using auto-fetching.^3 I treat www pages as "simple" ones with only one significant component and none controlled by third parties."
What this means is that the set of names I will use is (generally) deterministic. For example, if I aim to access the index.html page at https://example.com, I only retrieve the DNS data for example.com. The set of names for which I must retrieve DNS data is known, a priori.^1 To give a more practical example, I start with a list of all the domain names represented in HN submissions (cf. comments). I retrieve DNS data for those names only. (NB. A small minority of www sites submitted to HN do change hosting providers occassionally or change IP addresses relatively frequently.)
Thus when I read HN submissions, I am not performing any remote DNS queries. At an earlier point, I have performed bulk DNS data retrieval for all domain names in HN submmissions. The DNS data is stored in the memory of a localhost forward proxy or in custom zone files served by a localhost authoritative nameserver.
Another example might be domains found in Google Scholar search results. I collect these names from a series of searches then retrieve the DNS data in bulk. Then I can search and retrieve papers from many sources found through Scholar without making remote DNS queries.
There are a variety of sources for bulk DNS data. Some potential sources are
Public zone file access programs (Contact the registry. Many zones are available through ICANN's CZDS program.) https://czds.icann.org
Public scan data (Sadly, Rapid7 recently stopped publishing their foward DNS data.)
DoH open resolvers (Using HTTP/1.1 pipelining.)
Common Crawl archives (By extracting WARC-TARGET-IP.)
1. In contrast to using browser auto-fetching where I have no idea what other domain names might be automatically looked up when I visit example.com.
The TL;DR is that these serverless offerings require you to use the actual HTTPS hostname they expect, so it can actually, you know. Work. They are often run on cloud servers so you have to have a proper 'Host:' field configured when doing HTTP requests to resolve the service correctly and begin doing secure queries. But then how do you do the initial bootstrap and find the HTTPS hostname to use?
So if you want this turnkey, like, "I could configure my non-technical family PC to use it", you really need one extra piece: an ordinary DNS server on port 53 UDP. You actually configure your users to use this DNS server, but its only real job is to then point them to the real DoH server, with the hostname given, thus bootstrapping the connection. (Read the blog post about how this initial query is secured, I'll leave that to you.)
This kind of throws a wrench in the serverless thing, because you need some DNS service sitting on port 53 somewhere. But this initial bootstrap is much less latency sensitive than normal DNS and it is needed infrequently, so you could probably do this fine with CoreDNS and a shit $1 VPN on the internet. As a bonus, if you have clients that do not support DDR, you could configure this resolver to transparently use your serverless DOH resolver as a backend (so there's no difference in resolved names, just the features available.)
It looks like Deno is the only serverless offering I can see that offers UDP support, which means you could, for their platform only, avoid the intermediate VPS and have an entire DoH+DDR capable stack all at once. That's very appealing; maybe I should sign up...
It’s considered polite to define any terms you use:
[0] https://github.com/serverless-dns/serverless-dns/issues/67
I'll stick with the Tor Browser where I can, but we really need Tor-backed local resolvers.
My p30 Pro phones home on a lot of domains.
now that they are blocked via a pi hole my phone can no longer send that data.
I would count this as a plus to my privacy
