Implementing DNS Wildcard (Domain Wildcard) for Test Environment Management and Tag Domain Integration in the OMS Backend System

1. Problem Background

The company currently accesses test environments using online domain names combined with local host file modifications. This approach leads to several issues: forgetting to update the host file or browser socket cache can cause accidental access to production data, frequent host changes reduce efficiency for product, operations, and testing teams, and each environment switch requires operations staff to modify Nginx configurations.

Forgot to modify host or browser cache prevents host from taking effect, risking production data changes. Frequent host configuration changes lower efficiency for product, operations, and testing. Third‑party integration requires ops to change Nginx for each environment.

2. Evolution of Test Environments

2.1 Fixed Number of Test Environments

When multiple transaction services run in parallel, each branch (e.g., branch 1 and branch 2) requires its own set of dependent services deployed in the environment.

Advantage: traffic isolation. Disadvantage: with 500+ instances, launching a full set of instances per environment leads to massive resource waste (e.g., 5 environments × 500 instances = 2500+ instances).

2.2 Multi‑Environment Reuse: Dynamic + Stable

When multiple demands run in parallel, new demand branches can be deployed only in the dynamic environment.

Advantage: maintains traffic isolation while saving machine resources. Current drawback: during integration, testing, and product acceptance, manual host configuration is still required to access the dynamic environment.

3. Solution

Technical improvement: DNS wildcard (domain wildcard) resolution.

3.1 Principle

A "wildcard DNS" uses the asterisk (*) as a wildcard to map all sub‑domains to the same IP address.

3.2 Use Cases

Enable unlimited sub‑domains (the primary purpose of wildcard DNS). Prevent user typos from causing site inaccessibility (large sites usually use URL redirects instead). Allow users to type a short, simple URL to reach the website directly.

3.3 DNS Wildcard Configuration

Zhuanzhuan DNS platform:

4. Tag Domain Implementation in the OMS Backend System

When a company’s system evolves over many years, introducing new technologies (frontend, backend, ops, architecture, engineering efficiency) often requires personalized modifications across the entire chain to meet goals. The following outlines how the OMS backend system uses tag domains for such refactoring.

4.1 OMS Collaboration Platform Tag Domain Refactoring Points

DNS configuration with wildcard and ngx_lua for traffic grouping (handled by ops). SSO service QR‑code login refactoring (handled by architecture team). CI replaces static resource domain when deploying frontend services (handled by engineering efficiency team). Domain consolidation: frontend and backend services use separate domains; the backend domain is deprecated, keeping only the SCP frontend domain, with Nginx routing based on URI rules (frontend & backend teams). Frontend services read the browser‑provided host and dynamically compose URLs (frontend team).

4.2 Request Flow Diagram

As the saying goes, a picture is worth a thousand words; the request flow is illustrated below.

5. Tag Domain Usage and Effect

5.1 Usage Method

OMS协作平台相关地址：
1.测试环境
CI平台申请服务标签tag
访问方式：https://oms-tag.zhuanstest.com
2.内网生产环境：
访问方式：https://oms.zhuanxxx.com

5.2 Access Effect

As shown, there is no need for cumbersome host configuration; access is achieved directly via the domain name.

Author Bio

Gao Xiangyang, Head of OMS R&D in Zhuanzhuan Mid‑Platform.