DNS and DHCP are core services that people probably want on their home network. Most home users will be given a router or purchase one and just use the services built into it. The Stein home network is a little more complicated with multiple sub-nets and VLANs, so a more comprehensive solution was desired.
A major concern facing this design is that DNS and DHCP services are very important and need to be highly available. Secondary factors are low cost and simplicity. Both the ISC tools and Pacemaker were considered, but it was decided that they increased complexity without providing enough of a gain in functionality.
I recently bought a car with Android Auto. While the car's native infotainment system was pretty good and integrated so you could do things like change audio settings and channels with voice commands, it was restrictive in what you could say to it and you could not send text messages via voice. One thing that I wanted to be able to do is not only hear the messages read back to me, (which it did fine), but also reply or generate a new text message, (which it did not do). So I enabled Android Auto and thought things would be good. However, as soon as I asked Google to text someone, it responded that I needed to enable more access.
A naming convention is a way to give names to devices on a network so they are descriptive or easier to type into a connection string. In college I was a network administrator for the "spirits" lab where the various terminals had names like "vodka", "rum", etc. I did not start this, but did later modified it in another environment so that certain types of alcoholic beverages referred to a certain type of item e.g. switches were beers, servers were wines, etc.
I am a big fan of technology and making it work for me--to make my life more efficient and enriched. I also have a security background which means I keen eye on confidentiality, integrity and availability.
(FYI the picture here is the server rack circa 2001. A lot has changed since then but I like the retro look!)
The documents in the categories listed below describe how I have designed and implemented various technologies in my life as well as why I chose certain things or moved from one technology to another. Since I tend to rebuild or change some if not all of my supporting infrastructure every year, (usually over the year-end holiday season), these documents also serve as a step-by-step guide to which I can refer. While those details are specific to my environment and not meant to be generalized they may also be useful to others trying to implement something similar.