Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
DNS is a quite well matured technology and it's just as complex as it needs to be and not a bit more. It's a very robust system which has been a big part of the backbone of the internet as we know it today for decades and it's responsible for quite a large chunk of stuff working as intended globally for millions and billions of people all day every day.
It's not hard to learn per se (it's something you can explain on a basic level to every layman in 15 minutes or so), it's just a complex system and understanding complex systems isn't always easy nor fast. Running your own DNS-server/forwarder for a /24 private subnet is rather trivial thing to do, but doing it well requires that you understand at least some of the underlying tehcnology.
You really need to learn how to walk at first and build on that to run. It's just a fundamental piece of technology and there's no shortcuts with it due to nature of DNS services. You can throw whatever running on a container by following step-by-step instructinos and call it a day, but that alone doesn't give you the knowledge to understand what's going on under the hood. That's just how the things are and should I have my way with things, that same principle should apply to everything, specially if it's going to face the public internet.
Yeah, I don't think I really agree with the author as to the difficulty with
dig. Maybe it could be better, but as protocols and tools go, I'd say that dig and DNS is an example where a tool does a pretty good job of coverage. Maybe not DNSSEC, dunno about howdigdoes there, and knowing to use+norecurseis maybe not immediately obvious, but I can list a lot of network protocols for which I wish that there were the equivalent todig.However, a lot of what of what the author seems to be complaining about is not really stuff at the network level, but the stuff happening on the host level. And it is true that there are a lot of parts in there if one considers name resolution as a whole, not just DNS, and no one tool that can look at the whole process.
If I'm doing a resolution with Firefox, I've got a browser cache for name resolutions independently of the OS. I may be doing DNS over HTTP, and that may always happen or be a fallback. I may have a caching nameserver at my OS level. There's the
/etc/hostsfile. There's configuration in/etc/resolv.conf. There's NIS/yp. Windows has its own name resolution stuff hooked into the Windows domains stuff and several mechanisms to do name resolution, whether via broadcasts without a domain controller or with a DC whether that's present; Apple has Bonjour and more-generally there's zeroconf. It's not immediately clear to someone the order of this or a tool that can monitor the whole process end to end -- these are indeed independent systems that kind of grew organically.Maybe it'd be nice to have an API to let external software initiate name resolutions via the browser and get information about what's going on, and then have a single "name resolution diagnostic" tool that could span multiple of these name resolution systems, describe what's happening and help highlight problems. I can say that
gethostbyname()could also use a diagnostic call to extract more information about what a resolution attempt attempted to do and why it failed; libc doesn't expose a lot of useful diagnostic information to the application, though libc does know what it is doing in a resolution attempt.