What is a subdomain? How do I create and manage one?

　　Before discussing subdomains, we need to understand what a domain name actually is. You can think of a domain name as your house number; for example, "example.com" is the name of the street where your house is located. But just having a street name isn't enough. Your house might have a front door, a back door, a garage door, and a side door, each leading to different rooms. A subdomain is an extension of these house numbers; for example, "news" in "news.example.com" is a subdomain. More precisely, a subdomain is a prefix added to your main domain name, separated by periods (.). Technically, it belongs to the leftmost part of the Domain Name System (DNS), and DNS treats it as a separate entry.

　　Many people have a misconception that subdomains must start with "www," since "www" has been deeply ingrained in people's minds since the birth of the internet. But actually, "www" itself is a subdomain; it's just so common that people often forget it belongs to the subdomain category. Besides "www", you can create any prefix you can think of: "blog", "shop", "mail", "api", "admin", "test", even "this.is.a.very.long.subdomain" is perfectly legal. The key is how you want to organize your online assets.

　　Speaking of organizing online assets, this is where the core value of subdomains lies. Imagine you're running a medium-sized online education platform with the main domain "example.com". You could use "course.example.com" for the course playback system, "payment.example.com" for payment processing, "forum.example.com" for student discussions, and "status.example.com" to display the operational status of each service. What's the most direct benefit of this? Isolation. Even if the "forum" subdomain is compromised, it's difficult for attackers to laterally penetrate the payment system because they are usually deployed separately, both logically and physically. Of course, I'm talking about the ideal situation; you actually need to deploy them on different servers or in different containers. Simply giving them names doesn't constitute isolation.

　　Creating a subdomain isn't exactly difficult, but it's not as simple as you might think. The specific steps depend entirely on your domain registrar and DNS provider. Log in to your domain registrar, select your domain, find the DNS record settings, and click "Add record." You'll see several dropdown options: A record, CNAME record, TXT record, MX record, etc. If you want to create "shop.example.com" and point it to a fixed IP address, create a new A record, enter "shop" in the "Name" field, and enter your server's IP address. Save the record. After a minute or two, or at most a few hours (depending on DNS propagation time), "shop.example.com" will be accessible.

　　However, there's a common pitfall: many beginners enter the complete "shop.example.com" in the "Name" field. This is incorrect because the DNS system automatically completes the main domain name. If you enter "shop," the system will generate "shop.example.com," but if you enter "shop.example.com," the system might generate "shop.example.com.example.com," which would be problematic. Different registrars have different interface styles. Some will ask you to fill in the complete subdomain, but most modern control panels are intelligent and will prompt you on how to fill it in.

　　Besides A records, CNAME records are also commonly used. An A record directly points a subdomain to an IP address, while a CNAME record points to another domain. For example, if you want "www.example.com" and "example.com" to access the same website, you would usually use a CNAME record to point "www" to "example.com". The advantage of this is that if the server's IP address changes in the future, you only need to modify the A record for "example.com", and all CNAME records pointing to it will automatically change accordingly. However, CNAME records are not a panacea; they cannot be used for root domains, nor can they coexist with other records with the same name, as stipulated by the DNS protocol itself.

　　Managing subdomains is actually much more complex than creating them, because you need to carefully consider which subdomains should exist, which should be disabled, which should be publicly accessible, and which should only be used on the internal network. Many companies initially think subdomains can be used indiscriminately. However, as projects multiply, a quick glance at the control panel reveals dozens or even hundreds of records, some pointing to expired cloud servers, others being test domains created by interns and never used again. These unattended DNS records are like unlocked backdoors, posing a significant security risk. Last year, a well-known tech company suffered substantial losses because a hacker took over a cloud storage bucket after forgetting to remove a subdomain pointing to an expired one, placing a phishing page on it.

　　Therefore, a practical management practice is to add clear comments and tags to each subdomain. Professional services like Cloudflare and AWS Route53 support adding descriptive information to each DNS record, allowing you to include the subdomain's purpose, creation date, owner, and expected lifespan. For example, "course.example.com" is labeled "Course on-demand system, person in charge Zhang San, created in January 2024, perpetual," and "test.api.example.com" is labeled "Test environment API, person in charge Li Si, created in June 2025, valid until September 2025." If you haven't shut down this test domain by October, you'll know you should ask Li Si if he forgot to delete it.

　　Another easily overlooked but extremely important point is the relationship between SSL certificates and subdomains. Now everyone is used to using HTTPS to access websites, which involves SSL certificates. Traditional single-domain certificates only protect one specific domain, such as "example.com." If you want to protect "shop.example.com" and "blog.example.com," you have a few options. One is to buy a wildcard certificate, which uses "*.example.com" to indicate that all first-level subdomains are protected; it's slightly more expensive but convenient. Another is to use a multi-domain certificate provided by a free CA like Let's Encrypt, which can cover multiple specific subdomains with one certificate. Regardless of the method, you need to plan your subdomain system in advance. Don't wait until your certificate expires to find that a subdomain is causing security warnings for users accessing it due to the lack of a certificate.

　　Speaking of which, I'm reminded of a less common but very practical technique: using subdomains for A/B testing or canary releases. For example, if your main site is "example.com" and you want to launch a new homepage layout but are unsure of user reaction, you can create "beta.example.com" pointing to the new server, and then allow some users to access this subdomain by configuring forwarding or modifying their local hosts files. A more advanced approach is to use a load balancer to determine whether to route traffic to "example.com" or "beta.example.com" based on the user's cookies or IP address range. The advantage of this is complete isolation between the old and new environments. If a major problem occurs with the new version, you can simply switch traffic back to the main site without any collateral damage.

　　The use of subdomains varies significantly depending on the scenario. Large internet companies often have hundreds or even thousands of subdomains. Unlike individual website owners who manually add them one by one in their control panels, they use automation tools and Infrastructure as Code (IaaC) practices. For example, they use Terraform to manage DNS records. All subdomain configurations are written in the version control system, making it clear who created which subdomain, for what purpose, and when it was modified. Combined with CI/CD pipelines, developers submit a pull request, the code is automatically merged after approval, and DNS records are automatically updated—all without anyone needing to log into the web console.

　　Access control also deserves a mention. If you're not working alone but with a small team, you need to carefully control who can create and modify subdomain records. This may sound obvious, but you don't know how many companies have only one shared account for DNS management, with everyone knowing the password, even interns who leave. A more reasonable approach is to utilize the team functionality provided by your DNS provider, assigning different permissions to different people. For example, regular developers can only view records, not modify them; operations engineers can modify but not delete domains; and only the technical lead has full access. This can be further amplified by requiring critical operations to undergo secondary confirmation or be audited through operation logs.

　　Subdomains can also be used in creative ways, such as for dynamic DNS. Those with a home NAS or who need to access internal network devices from outside should be familiar with this. You can use an API key from your domain registrar to have your home router periodically tell the DNS server: "My current dynamic public IP address is this; please update the A record for 'nas.example.com'." This way, no matter how your broadband connection redials, you can always access your home devices through this fixed subdomain. A similar approach can be used for region-specific intelligent DNS resolution, such as resolving "us.example.com" to a US server IP address and "cn.example.com" to a Chinese server IP address, allowing users in different regions to automatically access the nearest server.

　　The most outrageous example of subdomain misuse I've seen is at a startup where they directly created subdomains for each customer's tenant ID, such as "customer123.example.com". The design itself isn't flawed; the problem lies in the lack of strict access control. This allows users to easily guess the subdomain formats of other customers and directly access their data pages. This is a classic example of a subdomain enumeration attack. Attackers don't need advanced technology; a simple dictionary script can be used to try "customer1", "customer2", and so on up to "customer10000" to find a large amount of accessible customer data. To avoid this problem, either avoid such obvious regular naming, add strong authentication at each subdomain level, or simply use path parameters like "example.com/customers/123".

　　Finally, here's a little-known fact: there are limits to the number of subdomain levels. Theoretically, the total length of a complete domain name cannot exceed 253 characters, and each tag (the part between two dots) cannot exceed 63 characters. This means that theoretically, you can create four, five, or even deeper levels of subdomains, such as "a.b.c.d.e.f.g.example.com". However, in practice, most browsers and DNS resolvers don't support subdomains beyond five levels well, and how are users supposed to remember such long addresses? Therefore, unless there are special technical requirements, sticking to first-level subdomains is sufficient, with second-level subdomains at most.

　　From creation to management, subdomains seem simple, but truly using them effectively requires a clear plan for your entire network architecture. It's not something you can configure and then forget about; it's more like a potted plant that needs periodic pruning, removing dead branches and guiding new growth in the right direction. Spend an hour or two reviewing the DNS records of all your domains, deleting those long-unused test subdomains, and adding notes and responsible persons to the ones still in use. Trust me, your future self will thank you for this diligence.