Self hosting a authoritative DNS and CDN
I have hosted many different applications and services over the decades, both professionally and for personal use. But so far there are two I have always stayed away from: authoritative DNS and content deliver networks (CDN). This is about to change.
You might rightfully ask why I am about to start hosting two components which are free or extremely cheap at the scale of my own projects. It comes down to ownership, features, price and most importantly: A learning opportunity.
Ownership
We have a lot of the Internet semi-centralised behind a handful of providers. The good thing about this is that those big providers compete by offering enough services for free, at least for many small and hobby projects.
But this does not change the nature of having a few companies run a significant part of the Internet. And some of these companies are actively doing things that can be considered harmful, be it to Open Source, to society or whatever moral stance you prefer to take a high ground on.
Deciding against using their services means you have to spend money and time on something you could get for free or dirt cheap. I also want to be very clear about the limitations I mentioned upfront. You will not get the same level of reliability, performance or scalability.
What I am interested in trying is if it is possible to get to an inexpensive, reproducible solution which is good enough, so you have a choice. This also means we do not want to spend 100s of dollars per month running a DNS server. Or spend hours each week maintaining a CDN.
The CDN will have three of four points of presence. This means latency and general speed will not even remotely compare to commercial offerings. But it will be far better than having everything run on a single server in a single location. And it will most likely be good enough for most.
And for what? Putting you back in control. Beside from whoever you rent server from. But it is your software delivering the data. You believe in keeping all logfiles turned off to not add to the all present and mostly pointless data collection we are seeing these days? One config flag and you are good.
There are also a fun few things you can do once you have control of the full stack, but before having deployed and tested everything I will not spoil the surprise.
One thing to not forget is that I am experimenting at a small scale - my blog sits at around 1000 unique visitors a day. One or two side projects will join later on. If one of our customers needs DNS or a CDN I will buy it from one of the big providers for the foreseeable future. Maybe forever. There is a very good chance this will not come close to where I am comfortable rolling it out for a paying customer with a million or more uniques a day.
Features
You can get lots of features and services for free or for a very small price. But there are still some for which you pay a considerable amount of money.
Routing requests to different IPs via geo location lookup is a good example. You likely get basic DNS with the purchase of a domain. But try finding a reliable provider offering a geoIP feature that does not cost ten or more dollars each month, or has some obscure usage based billing.
Even if you find one, they most likely charge per domain. How much time I will spend on DNS is something I do not know yet, and it partially will dictate the final price, but just the two servers to run the DNS software are cheaper than paying a provider for one domain.
CDNs cache GET
requests - this is the bare minimum I think you can always expect. But what about POST
? Good luck with that on free or inexpensive tiers. And over the past years I had a few moments where I would have wished this would be an option.
These are only two examples. You will see the complete list of features in the individual service write-up.
Learning
Most important to me is the learning opportunity. In theory I know how these two services work. I even wrote some software in this domain in the past, but only for internal use.
But there are nuances I have not seen live, for example with wireshark and with production traffic. Something will most likely go wrong at some point and this will probably be the aha moment making it worth it.
And depending on how well this goes I might even take this as an opportunity to implement a few features on a separate service layer, or maybe replace one of the core services. A first screening of the software suggests this will likely not happen, but I got the option if I ever feel like I am out of yaks.
Goals
The goals are well defined enough for me to get started. A three POP CDN and requests routed to the correct node via geo lookup when the DNS request is made. Software selection is still outstanding, but I will not opt for anything niche or self written (not yet at least).
I will most likely package the services as an OCI image so Docker and the likes can easily run them. I do not think this is the best idea, but it will help with the goal of making it reproducible and accessible if others are interested in doing the same.
This feels a bit like a missed opportunity to play with FreeBSD and jails again, a stack I vastly prefer over Docker and which has proven to be a "really good choice" for large scale CDNs.
The plan is to host one of my test domains and let some scripts gather telemetry for a few weeks before moving a slightly larger project or this blog over to the new infrastructure.
Most importantly when doing something I am not paid for: Have a lot of fun! :)
posted on Aug. 26, 2024, 5:42 p.m. in infrastructure, self-hosting, web