Subdomains as add-on domains.

I understand that by definition they are subdomains, however, there are situations where we are not using them in the traditional sense of subdomains. In practice, we often intend for them to function as fully independent add-on domains.

A common example is when we use subdomains as temporary development environments. In these cases, we need them to behave like add-on domains, particularly because that is how they are being configured and added within SPanel. Although SPanel allows the entry of a subdomain as if it were an add-on domain, it ultimately categorizes and manages it under the subdomains section. This is problematic because of the way SPanel internally treats subdomains—specifically, it restricts access to certain features that are available only to add-on domains, such as DNS zone management.

This discrepancy creates functional limitations that can significantly impact our workflows. For instance, when a domain is managed as a true add-on domain, we have full control over its DNS settings. But when it’s relegated to being a subdomain in SPanel’s structure, those controls are either limited or completely unavailable, despite our intent and setup.

Furthermore, it's important to recognize that in the U.S., it’s common for institutions such as schools and government entities to use subdomains as their primary domains (e.g., school.k12.state.us or agency.gov). These are not just sub-sections of a larger site but are treated as distinct entities, often with their own infrastructure and administrative needs. Treating them as mere subdomains limits the flexibility and control that organizations require, and it does not reflect their real-world usage.

For these reasons, we believe SPanel should revise how it handles subdomains that are intended to function as add-on domains. At minimum, there should be an option to allow users to manage such domains with the full set of features typically reserved for add-on domains.