This stuff needs to be generated from the data model, not hard coded. One way to do that is to build a model class for services and a component template for displaying a form field for a service, and then simply iterate over each service field in a configuration. We may get fancier later on when services could have their own special configuration options, but let's think about that when we get to there.
Why would we go back to index? We instead want to show the stored configuration
IIRC we wanted a dropdown single-select for the MVP. Later on we could have a workflow to either select from an already registered domain or register a new one. Which is why probably it would make sense to already set up a table for DNS domains. We may discard it later if we have a direct API connection to the DNS management system, or use it for caching.
We want a service to be a proper class, because it will quickly have much more internal structure than just on/off. For instance we may want to configure the subdomain for a service (as was originally intended in Fediversity/Fediversity#107), or how much storage to reserve for that service, etc.
