Alibaba Cloud DNS Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking and CDN

1. Introduction

Alibaba Cloud DNS is Alibaba Cloud’s managed authoritative Domain Name System (DNS) service for hosting public DNS zones and resolving your domain names to applications, endpoints, and other internet-facing resources.

In simple terms: you create (or migrate) your domain’s DNS zone to Alibaba Cloud DNS, add records like A, AAAA, CNAME, and MX, then point your registrar to the Alibaba Cloud DNS name servers so the internet can find your services.

Technically, Alibaba Cloud DNS provides authoritative DNS hosting with API/console-based record management, support for common record types, and (depending on edition/features enabled) intelligent routing, health-check-based failover, and security features like DNSSEC. It integrates naturally with Alibaba Cloud compute and networking services (ECS, SLB, CDN, OSS, etc.) because DNS is the entry point for most web and API traffic.

The main problem Alibaba Cloud DNS solves is reliable, scalable, centrally managed DNS for production systems—so your users can resolve your domain quickly and you can update routing safely during deployments, incidents, or migrations.

Note on naming/scope: “Alibaba Cloud DNS” typically refers to authoritative DNS hosting (managed public zones). Alibaba Cloud also offers other DNS-related products such as PrivateZone (private DNS for VPCs) and “Public DNS” resolvers. This tutorial focuses on Alibaba Cloud DNS (authoritative public DNS) and calls out adjacent services where relevant.

2. What is Alibaba Cloud DNS?

Official purpose: Alibaba Cloud DNS is a managed authoritative DNS service that hosts DNS zones for your domains and answers queries from recursive resolvers worldwide with the DNS records you configure.

Core capabilities (high level): – Host public DNS zones and manage DNS records via console, API, and CLI. – Support standard DNS record types used for websites, APIs, email, and certificate validation. – Provide governance and operational controls (role-based access via RAM, auditing via ActionTrail, change workflows you can build via IaC and CI/CD). – Offer optional advanced capabilities (commonly including intelligent routing and health checks) depending on your purchased edition and enabled features. Verify exact availability in official docs and the pricing page.

Major components: – DNS Zones (Domains): The authoritative zone for example.com (or a delegated subdomain). – Record sets (DNS records): A, AAAA, CNAME, TXT, MX, etc. – Name servers (NS): The authoritative name servers assigned to your zone by Alibaba Cloud DNS. – Management plane: Console + APIs + Alibaba Cloud CLI (aliyun) for configuration and automation. – Access control: Resource Access Management (RAM) users/roles and policies for least-privilege operations.

Service type: Managed, shared-responsibility, authoritative DNS hosting (control plane + authoritative answering infrastructure operated by Alibaba Cloud).

Scope (global/regional/account): – Authoritative DNS is inherently global in consumption: queries come from anywhere on the internet. – Configuration is account-scoped (your Alibaba Cloud account) and controlled via RAM. – Some feature availability and pricing may vary by region or billing entity. DNS query answering itself is global, while management endpoints and billing are tied to your Alibaba Cloud account. Verify in official docs for your account/region specifics.

How it fits into Alibaba Cloud: Alibaba Cloud DNS is foundational to the Networking and CDN stack: – It routes users to CDN, Server Load Balancer (SLB), ECS, API gateways, or third-party endpoints. – It supports blue/green deployments, disaster recovery, multi-region routing, and safe migrations. – It works alongside domain registration (Alibaba Cloud Domains), certificate services, and security monitoring/auditing.

3. Why use Alibaba Cloud DNS?

Business reasons

Reduce downtime risk: DNS is a critical dependency. Using a managed authoritative DNS reduces the operational burden of running your own DNS servers.
Faster changes: Product launches, incident response, and migrations often require DNS updates; APIs and automation shorten change cycles.
Consolidation: If your infrastructure is on Alibaba Cloud, keeping DNS in the same ecosystem can simplify operations and vendor management.

Technical reasons

Standards-based DNS: Support for common record types and DNS workflows (delegation, TTL tuning, validation records).
Automation-friendly: APIs and CLI enable DNS-as-code and CI/CD integration.
Advanced routing (optional): Depending on edition, you may gain intelligent routing, weighted records, and health-check-based failover. Verify exact features per edition.

Operational reasons

Centralized management: One console for zones, records, and access control.
Change control: You can implement approval workflows and drift detection via IaC pipelines.
Auditing: With Alibaba Cloud ActionTrail, DNS changes performed via API/console can be audited. Confirm details in ActionTrail + DNS docs.

Security/compliance reasons

Least privilege with RAM: Separate duties (read-only, record managers, zone admins).
DNSSEC (optional): If supported for your zone/edition, DNSSEC reduces the risk of DNS spoofing by providing cryptographic integrity. Verify DNSSEC support and constraints.
Controlled updates: Avoid “shared credentials” DNS updates by using RAM roles and short-lived access keys for automation.

Scalability/performance reasons

Managed authoritative infrastructure: Designed to handle high query volumes without you deploying or scaling DNS servers.
Global resolution: Authoritative DNS is reachable globally; performance depends on resolver behavior and any available routing features.

When teams should choose Alibaba Cloud DNS

You need managed authoritative DNS with tight integration into Alibaba Cloud operations.
You want to automate DNS changes via APIs/CLI and enforce IAM controls.
You operate internet-facing apps and need predictable DNS operations, environments, and auditing.

When teams should not choose it

You need features not available in Alibaba Cloud DNS (for example, specific traffic steering behaviors, integrated WAF rules at DNS, or proprietary resolver analytics). Compare alternatives carefully.
You require on-prem-only authoritative DNS with full control over the software stack (in that case, consider BIND/PowerDNS/Infoblox).
You are locked into another DNS provider because of organizational policy, global anycast footprint requirements, or specialized compliance rules—though many organizations use multi-DNS strategies.

4. Where is Alibaba Cloud DNS used?

Industries

SaaS and internet platforms
E-commerce and retail
Media and streaming (often paired with CDN)
Finance and fintech (with stronger change control and auditing)
Gaming (low-latency routing and regional endpoints)
Education and public sector (centralized management, compliance)

Team types

Platform engineering teams managing shared DNS zones across products
SRE/operations teams handling incident response and traffic shifts
DevOps teams building DNS automation in CI/CD
Security teams enforcing DNS governance (DNSSEC, access control, audit)

Workloads

Web frontends and APIs (A/AAAA/CNAME to SLB/CDN)
Email infrastructure (MX, TXT SPF/DKIM/DMARC)
Certificate validation (TXT for ACME DNS-01 or provider validation)
Multi-region active/active or active/passive architectures

Architectures and deployment contexts

Single-region production: DNS points to one SLB/CDN endpoint.
Multi-region: DNS steers users to the closest/healthiest region (feature-dependent).
Hybrid: Public DNS in Alibaba Cloud; internal service discovery handled by PrivateZone or other internal DNS.
Dev/test: Separate subdomains (dev.example.com, staging.example.com) with short TTLs for rapid iteration.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Alibaba Cloud DNS is commonly used. Feature availability can depend on edition—verify in official docs.

1) Host authoritative DNS for a production domain

Problem: You need a reliable place to manage DNS records for example.com.
Why Alibaba Cloud DNS fits: Managed authoritative DNS with console/API/CLI record management.
Example: Host example.com zone in Alibaba Cloud DNS; point www to a CDN endpoint.

2) Route `www` to Alibaba Cloud CDN (or another edge endpoint)

Problem: Reduce latency and offload origin traffic.
Why it fits: DNS is the entry point for mapping a hostname to your CDN distribution domain.
Example: www.example.com as a CNAME to the CDN domain provided by Alibaba Cloud CDN.

3) Map apex/root domain to a load balancer

Problem: You want example.com to reach your application.
Why it fits: Use A/AAAA records to point to SLB/ECS public IPs (depending on architecture).
Example: example.com A -> SLB public IP.

4) Email configuration (SPF, DKIM, DMARC, MX)

Problem: Mail deliverability issues and spoofing risks.
Why it fits: DNS supports MX and TXT records required for modern email authentication.
Example: Add MX records for your provider and TXT records for SPF + DMARC.

5) ACME DNS-01 validation for certificates

Problem: You need wildcard certificates or can’t expose HTTP validation.
Why it fits: Create/automate TXT records for _acme-challenge.example.com.
Example: CI pipeline uses aliyun alidns AddDomainRecord to publish validation tokens.

6) Blue/green deployment cutover

Problem: You need a controlled switch between old and new environments.
Why it fits: DNS record updates (with tuned TTLs) can shift traffic.
Example: api.example.com changes from A->OldSLB to A->NewSLB with a 60–300s TTL.

7) Disaster recovery (DR) failover (feature-dependent)

Problem: If Region A fails, you must route traffic to Region B.
Why it fits: Some DNS editions support health checks and failover routing. Verify feature support.
Example: Health check monitors https://app.example.com/health; DNS returns Region B if Region A is down.

8) Delegated subdomain for a team or environment

Problem: Multiple teams need autonomy without sharing full zone access.
Why it fits: Delegate team1.example.com to a separate zone/account via NS records.
Example: Platform team keeps example.com; app team manages dev.example.com in its own zone.

9) Manage IoT endpoints and regional ingestion

Problem: Devices need a stable hostname while backend changes.
Why it fits: DNS provides stable naming and can support regional endpoints (feature-dependent).
Example: ingest.example.com routes to regional ingestion services.

10) SaaS multi-tenant custom domains

Problem: Customers want customer.com mapped to your SaaS.
Why it fits: Use CNAME targets + verification via TXT.
Example: Customer adds CNAME app.customer.com -> tenant.your-saas.com, plus TXT ownership proof.

11) Compliance-driven change auditing for DNS

Problem: You must prove who changed DNS and when.
Why it fits: Use RAM + ActionTrail to audit record changes. Verify exact auditing details.
Example: Security reviews ActionTrail events for alidns API calls.

12) Migration away from another DNS provider

Problem: You want to move DNS hosting without downtime.
Why it fits: Standard zone/record creation; cutover by updating registrar NS.
Example: Import records, validate with dig @nsX, then change NS at registrar.

6. Core Features

Feature availability can vary by plan/edition. For any feature you plan to rely on in production, confirm in: – Docs: https://www.alibabacloud.com/help/en/alibaba-cloud-dns/ – Product page: https://www.alibabacloud.com/product/dns – Pricing page (edition matrix): https://www.alibabacloud.com/product/dns/pricing (verify)

6.1 Public authoritative DNS zone hosting

What it does: Hosts DNS zones for domains and answers authoritative queries.
Why it matters: DNS is the first hop for most services; authoritative hosting must be reliable.
Practical benefit: No DNS server maintenance; fast record updates through managed infrastructure.
Caveats: You must delegate your domain to the assigned name servers for changes to take effect globally.

6.2 DNS record management (common types)

What it does: Create/update/delete records like A, AAAA, CNAME, TXT, MX, NS, SRV, CAA (exact list may vary—verify in console/docs).
Why it matters: Different workloads require different records (web, email, validation).
Practical benefit: Central place to manage records with consistent access control.
Caveats: Some providers impose constraints (e.g., CNAME at apex). If you need “apex alias” behavior, confirm how Alibaba Cloud DNS supports it (if at all) in current docs.

6.3 TTL control and propagation strategy

What it does: Configure record TTL (time-to-live).
Why it matters: TTL affects how quickly clients/resolvers pick up changes.
Practical benefit: Lower TTLs for fast cutovers; higher TTLs for stability and fewer queries.
Caveats: Effective propagation depends on recursive resolvers honoring TTLs; some resolvers cache longer or prefetch.

6.4 Console + API + CLI automation

What it does: Manage zones and records via:
Web console
APIs (Alibaba Cloud OpenAPI)
Alibaba Cloud CLI (aliyun) with the alidns service namespace
Why it matters: Enables GitOps/DNS-as-code, repeatability, and fast incident changes.
Practical benefit: Automate certificate validations, environment creation, and controlled deployments.
Caveats: Secure your AccessKeys; prefer RAM roles and CI secrets management.

6.5 Access control with RAM (least privilege)

What it does: Assign permissions to users/roles for DNS operations.
Why it matters: DNS changes can cause outages or hijacking.
Practical benefit: Separate duties: read-only, record editor, zone admin, automation role.
Caveats: Ensure permissions are scoped to the minimum required APIs/resources.

6.6 Intelligent/line-based resolution (feature-dependent)

What it does: Return different answers based on conditions such as user location, ISP line, or other routing logic.
Why it matters: Reduces latency and supports multi-region architectures.
Practical benefit: Send users to the nearest region or best-performing endpoint.
Caveats: Requires correct configuration and testing; behavior can vary by resolver location. Confirm supported routing policies and lines in official docs.

6.7 Weighted records / simple load distribution (feature-dependent)

What it does: Distribute DNS responses among multiple endpoints using weights.
Why it matters: Useful for gradual rollouts and multi-origin architectures.
Practical benefit: Canary releases by shifting small percentages via DNS (with limitations).
Caveats: DNS is not a precise traffic router; caching causes uneven distribution. Use application-layer load balancing where strict control is required.

6.8 Health checks and failover (feature-dependent)

What it does: Monitor endpoints and automatically adjust DNS answers when an endpoint is unhealthy.
Why it matters: DNS-level failover improves availability for simple architectures.
Practical benefit: Automated DR failover without manual DNS edits.
Caveats: Health checks are not instantaneous; caching delays failover. For strict RTO/RPO, combine with multi-region load balancers and application resilience.

6.9 DNSSEC (feature-dependent)

What it does: Signs DNS zones so resolvers can validate authenticity (prevents certain spoofing attacks).
Why it matters: Protects users from tampered DNS responses.
Practical benefit: Stronger integrity guarantees for critical domains.
Caveats: Operational complexity: key management, DS records at registrar, rollover planning. Confirm exact DNSSEC workflow supported by Alibaba Cloud DNS.

6.10 Operational/audit visibility (often via ActionTrail)

What it does: Track who changed what and when (management plane events).
Why it matters: Required for compliance and incident investigation.
Practical benefit: Audit trail for DNS changes and API calls.
Caveats: Query logs (actual DNS query analytics) are different from change logs; availability varies—verify current DNS logging capabilities.

7. Architecture and How It Works

High-level architecture

DNS resolution involves multiple parties: 1. A user’s device asks a recursive resolver (ISP resolver, enterprise resolver, or public resolver like 8.8.8.8). 2. The recursive resolver follows delegation from the DNS root to TLD (.com) to your domain’s authoritative name servers. 3. Alibaba Cloud DNS authoritative servers respond with your configured records. 4. The recursive resolver caches the response for the TTL and returns it to the user.

Request/data/control flow

Control plane (management):
You authenticate to Alibaba Cloud (console/API).
You create a zone and records.
Changes are stored and propagated to authoritative infrastructure.
Data plane (DNS answering):
Public DNS queries arrive at authoritative name servers.
Responses are served according to your record sets, TTLs, and any routing/health policies (if enabled).

Integrations with related services

Common integrations in Alibaba Cloud’s ecosystem: – ECS (Elastic Compute Service): A/AAAA records to public IPs. – SLB (Server Load Balancer): A record to SLB public IP (or CNAME depending on product behavior—verify). – Alibaba Cloud CDN: CNAME to CDN acceleration domain. – OSS static website: CNAME patterns are common; exact mapping depends on OSS website endpoints—verify current OSS + DNS guidance. – ActionTrail: Audit DNS management events (API calls). – RAM: Users/roles/policies for access control. – PrivateZone (separate product): For internal VPC DNS; not a replacement for public authoritative DNS.

Dependency services

Alibaba Cloud account + billing
RAM (for IAM best practice)
Optional: ActionTrail (auditing), CloudMonitor (if health checks integrate—verify)

Security/authentication model

Console uses Alibaba Cloud login + MFA.
API/CLI uses AccessKey pairs (prefer RAM user/role with least privilege; rotate keys).
Resource-level permissions are enforced by RAM policies.

Networking model

Alibaba Cloud DNS authoritative servers are internet-facing by design (authoritative queries).
You control what records are published publicly.
For internal names, use PrivateZone or internal DNS rather than exposing internal IPs in public zones.

Monitoring/logging/governance considerations

Change auditing: Enable ActionTrail and send logs to Log Service (SLS) if required by compliance. (Confirm current ActionTrail integration patterns.)
DNS availability monitoring: Externally probe critical records and endpoints from multiple regions/providers.
Change governance: Use IaC/CI pipelines, peer reviews, and staged TTL reductions before cutovers.

Simple architecture diagram (Mermaid)

flowchart LR
  U[User Device] --> R[Recursive Resolver]
  R -->|Queries| NS[Alibaba Cloud DNS Authoritative NS]
  NS -->|DNS Response| R
  R --> U
  U --> APP[App Endpoint (SLB/CDN/ECS)]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Internet
    Users[Users]
    Resolvers[Recursive Resolvers (ISP/Public/Enterprise)]
  end

  subgraph AlibabaCloud["Alibaba Cloud"]
    DNS[Alibaba Cloud DNS (Authoritative)]
    ActionTrail[ActionTrail (Audit)]
    RAM[RAM (IAM)]
    SLB_A[SLB / Ingress - Region A]
    SLB_B[SLB / Ingress - Region B]
    CDN[Alibaba Cloud CDN (optional)]
    Origins[(ECS/ACK/OSS Origins)]
  end

  Users --> Resolvers
  Resolvers --> DNS
  DNS -->|Answer: www.example.com| CDN
  CDN --> Origins

  DNS -->|Answer: api.example.com| SLB_A
  DNS -->|Failover/Policy-based (optional)| SLB_B

  Admin[DNS Admin / CI Pipeline] --> RAM
  Admin -->|API/Console changes| DNS
  DNS --> ActionTrail

8. Prerequisites

Account and billing

An active Alibaba Cloud account.
Billing method set up (Pay-as-you-go or subscription where applicable).
A domain you control (registered with Alibaba Cloud Domains or another registrar).

Permissions / IAM (RAM)

You need permissions to manage DNS zones and records. Common approaches: – Use an Alibaba Cloud account (root) only for initial setup, then switch to RAM users/roles. – Create RAM policies that allow only required alidns API actions.

At minimum for this lab: – Permissions to add a domain/zone and manage records in Alibaba Cloud DNS.

Tip: Start with a controlled admin role, then refine to least privilege once you know which API calls you need.

Tools

A terminal with:
dig (Linux/macOS) or nslookup (Windows) for validation
Optional: curl for HTTP verification
Optional automation:
Alibaba Cloud CLI (aliyun): https://www.alibabacloud.com/help/en/alibaba-cloud-cli/latest/what-is-alibaba-cloud-cli
AccessKey for a RAM user (store securely)

Region availability

Alibaba Cloud DNS is a global authoritative service, but management/billing may be associated with specific regions or billing entities. Verify any region-specific constraints in official docs.

Quotas/limits

Typical quotas you should confirm before production: – Max domains/zones per account – Max records per zone – API rate limits – Min/max TTL – Advanced feature quotas (health checks, monitored endpoints, etc.)

Verify quotas in official docs because they can vary by edition and may change over time.

Prerequisite services (optional)

ActionTrail for audit logging of DNS management operations.
PrivateZone for internal DNS (separate product) if you need split-horizon/internal-only names.

9. Pricing / Cost

Alibaba Cloud DNS pricing is typically based on editions/plans (often including a free/basic tier and paid tiers) and feature-based dimensions.

Because DNS pricing and included quotas can vary by: – plan/edition – account type and billing entity – region/marketplace – feature usage (health checks, advanced routing, query volume)

…you should treat pricing as a model, not a single number.

Official pricing references

Pricing page: https://www.alibabacloud.com/product/dns/pricing (verify)
Product overview: https://www.alibabacloud.com/product/dns
Documentation: https://www.alibabacloud.com/help/en/alibaba-cloud-dns/

Common pricing dimensions (verify exact ones for your plan)

Edition subscription fee (monthly/annual) for advanced DNS features.
Number of hosted zones/domains included.
Number of DNS queries included per period, or query-based billing beyond included amounts.
Advanced routing policies (intelligent lines, geo/ISP routing) availability per edition.
Health checks: number of checks and check frequency can be a cost driver (if billed separately).
API calls: sometimes limited by rate rather than cost; verify if any API request charges apply.

Free tier (if applicable)

Alibaba Cloud DNS commonly offers a basic/free capability level for simple authoritative hosting. Exact included quotas and capabilities vary—verify in the pricing page and console.

Cost drivers

Many zones/records (large organizations with thousands of records)
High query volume (popular consumer sites, APIs, gaming)
Advanced policies (multiple lines/regions/weights)
Health checks and monitoring frequency (if available and billed)

Hidden/indirect costs

Incident costs from misconfiguration: A wrong CNAME or MX can cause outages. Invest in change control.
Operational tooling: External monitoring probes, CI/CD pipelines, and secrets management.
Supporting infrastructure: If DNS points to SLB/CDN/ECS, those services have their own costs.

Network/data transfer implications

DNS query traffic to authoritative name servers is part of the managed service; you generally don’t pay egress like typical compute services for DNS answers, but you may pay by query/plan. Verify billing rules.
The endpoints DNS points to (CDN, SLB, ECS) will incur their own internet traffic costs.

How to optimize cost

Use the free/basic tier for non-critical dev/test where appropriate.
Keep TTLs reasonable (not too low everywhere) to reduce query volume and improve cache hit rates.
Use advanced routing only where it adds measurable value.
Delegate subdomains to separate zones only when necessary (organizational overhead vs. benefits).
For health checks, monitor only critical hostnames and choose an appropriate interval.

Example low-cost starter estimate (model, not a number)

A simple small website might use: – 1 hosted zone (example.com) – 10–50 records (A, CNAME, TXT, MX) – No health checks – Moderate query volume

This often fits within entry-tier plans, sometimes even free/basic tiers—verify your plan’s included quotas.

Example production cost considerations

An enterprise may have: – Hundreds of zones (product lines, subsidiaries) – Thousands of records – Multi-region intelligent routing – Health checks for dozens of critical endpoints – High DNS query volume

In this case: – Choose a plan/edition sized to your availability and routing needs. – Model query volume and health check counts. – Consider multi-provider DNS for risk management (adds cost but reduces dependency risk).

10. Step-by-Step Hands-On Tutorial

Objective

Host a public DNS zone in Alibaba Cloud DNS, create a record (A or CNAME), delegate DNS to Alibaba Cloud name servers, and validate resolution using dig/nslookup.

Lab Overview

You will: 1. Add a domain (zone) to Alibaba Cloud DNS. 2. Create a DNS record for a test hostname. 3. Delegate the domain (or a subdomain) to Alibaba Cloud DNS by updating NS records at your registrar/existing DNS provider. 4. Validate resolution from multiple resolvers. 5. (Optional) Automate record creation using Alibaba Cloud CLI. 6. Clean up by removing records and/or the zone.

Estimated time: 30–60 minutes (DNS propagation time varies).

Cost: Often low or free for basic DNS hosting; depends on your plan. No compute resources required for this lab if you point records to an existing public IP you control (or a harmless test IP for DNS-only validation).

What you need

A domain you control, such as yourdomain.com.
Access to your domain registrar DNS settings (where you set authoritative name servers) or existing DNS provider (for subdomain delegation).
Alibaba Cloud console access with DNS permissions.

Step 1: Add your domain (zone) in Alibaba Cloud DNS

Sign in to the Alibaba Cloud console.
Navigate to Alibaba Cloud DNS (often listed as “DNS” in the console product list).
Docs entry point: https://www.alibabacloud.com/help/en/alibaba-cloud-dns/
Choose Add Domain (wording may differ slightly).
Enter your domain name, for example: – yourdomain.com

After you add the domain, Alibaba Cloud DNS will display: – The domain/zone – A set of authoritative name servers (NS) assigned to your zone

Expected outcome – Your domain appears in the DNS console with assigned name servers. – You can open the domain to manage DNS records.

Verification – In the DNS console, confirm you can view the domain and see the NS list.

Step 2: Create a DNS record (example: `A` record for `test`)

Create a simple record you can query.

Open your domain in Alibaba Cloud DNS.
Select Add Record.
Configure: – Host/Record name (RR): test – Type: A – Value: Use a public IPv4 address you control.
If you only want to validate DNS resolution (not HTTP), you can temporarily use a documentation/test IP like 203.0.113.10 (TEST-NET-3), but it won’t serve web traffic. – TTL: Start with something moderate like 300 seconds (5 minutes), if configurable.

Save the record.

Expected outcome – A record exists: test.yourdomain.com -> <IP>.

Verification – The record appears in the record list for the zone.

Step 3: Delegate DNS to Alibaba Cloud DNS (choose one path)

You must ensure the internet queries Alibaba Cloud’s authoritative name servers for your domain.

Path A (most common): Change authoritative name servers at your registrar

At your domain registrar (where you registered yourdomain.com), update the domain’s Name Servers to the NS values shown in Alibaba Cloud DNS.

Expected outcome – The registrar displays Alibaba Cloud name servers for your domain. – Over time, the TLD delegation updates (propagation varies).

Path B (safer for labs): Delegate a subdomain only

If you don’t want to move the entire domain, you can delegate a subdomain, for example lab.yourdomain.com.

In Alibaba Cloud DNS, add a new domain/zone: lab.yourdomain.com.
Note the NS records assigned to lab.yourdomain.com.
In your current DNS provider for yourdomain.com, add NS records for the subdomain lab pointing to those Alibaba Cloud NS values.

Then create records inside the delegated zone: – test.lab.yourdomain.com A -> <IP>

Expected outcome – Only *.lab.yourdomain.com is hosted on Alibaba Cloud DNS; everything else remains on the original provider.

Verification – The parent zone contains NS delegation for lab. – Alibaba Cloud DNS hosts records inside lab.yourdomain.com.

Step 4: Validate DNS resolution using `dig` or `nslookup`

DNS changes can take time. Validate in two ways: 1) Query the Alibaba Cloud authoritative NS directly (bypasses global delegation issues). 2) Query through a public recursive resolver (tests real-world behavior).

4.1 Query authoritative NS directly (recommended first)

From your terminal, run:

# Replace with one of the authoritative NS hostnames shown in your Alibaba Cloud DNS console
NS_HOST="ns1.your-alidns-nameserver.example"   # replace
DOMAIN="test.yourdomain.com"                   # or test.lab.yourdomain.com

dig @"$NS_HOST" "$DOMAIN" A +noall +answer

Expected outcome – You see an A record answer with the IP you configured.

If you don’t have dig, use nslookup:

nslookup test.yourdomain.com NS_HOSTNAME_HERE

4.2 Query using a public resolver (tests delegation and caching)

For example, query Google Public DNS:

dig @8.8.8.8 test.yourdomain.com A +noall +answer

Or Cloudflare:

dig @1.1.1.1 test.yourdomain.com A +noall +answer

Expected outcome – Once delegation propagates, public resolvers return the same answer.

Step 5 (Optional): Manage records using Alibaba Cloud CLI

This is useful for automation (CI/CD, certificate validation, GitOps).

5.1 Install and configure Alibaba Cloud CLI

Follow: https://www.alibabacloud.com/help/en/alibaba-cloud-cli/latest/what-is-alibaba-cloud-cli

Configure credentials (prefer a RAM user with limited DNS permissions):

aliyun configure

You’ll provide: – AccessKey ID – AccessKey Secret – Default region (management plane operations; DNS is global in effect)

5.2 Add a record via CLI

Example:

aliyun alidns AddDomainRecord \
  --DomainName yourdomain.com \
  --RR cli-test \
  --Type A \
  --Value 203.0.113.10

List records:

aliyun alidns DescribeDomainRecords --DomainName yourdomain.com

Update a record (requires the record ID returned by DescribeDomainRecords):

aliyun alidns UpdateDomainRecord \
  --RecordId RECORD_ID_HERE \
  --RR cli-test \
  --Type A \
  --Value 203.0.113.11

Delete a record:

aliyun alidns DeleteDomainRecord --RecordId RECORD_ID_HERE

Expected outcome – Records are created/updated/deleted without using the console.

Verification – Re-run DescribeDomainRecords and query via dig.

API/CLI parameters can change. If any command fails, verify the latest alidns CLI reference in official docs.

Validation

Use this checklist:

Authoritative check (direct to NS): – dig @<alidns-ns> test.yourdomain.com A returns expected IP.
Delegation check: – dig yourdomain.com NS +short shows the NS set you configured at the registrar (may take time).
Recursive resolver check: – dig @1.1.1.1 test.yourdomain.com A returns expected IP.
TTL behavior check (optional): – Change record value, then observe caching behavior. Expect delays until TTL expires.

Troubleshooting

Common issues and fixes:

1) Public resolvers don’t return the record yet – Cause: Delegation not fully propagated; registrar changes can take time. – Fix: Query authoritative NS directly to confirm record exists; wait for NS propagation; ensure NS values match exactly.

2) SERVFAIL or REFUSED – Cause: Querying wrong server, DNSSEC misconfiguration (if enabled), or temporary resolver issues. – Fix: Test with multiple resolvers; disable DNSSEC until correctly configured; verify DS record at registrar if using DNSSEC.

3) You updated a record but still see old IP – Cause: Recursive caching. – Fix: Wait for TTL expiry; temporarily lower TTL before planned cutovers (best practice).

4) Record name mistakes (RR) – Cause: Confusion between test vs test.yourdomain.com. – Fix: In Alibaba Cloud DNS UI, RR usually expects only the leftmost label (test), not the full FQDN. Verify UI behavior.

5) CNAME conflicts – Cause: You can’t have a CNAME at the same name as other records (e.g., A + CNAME). – Fix: Remove conflicting records; use appropriate record type.

6) Automation fails with permissions – Cause: RAM policy missing required alidns actions. – Fix: Expand policy minimally; confirm required API calls using ActionTrail events.

Cleanup

Choose the cleanup level you want:

1) Remove lab records – Delete test / cli-test records from Alibaba Cloud DNS.

2) Remove the zone – Delete the domain/zone from Alibaba Cloud DNS if you don’t want to keep it.

3) Undo delegation – If you changed registrar name servers, revert them to your previous DNS provider (be careful—this can cause outages). – If you delegated a subdomain, remove the NS delegation from the parent zone.

4) Remove CLI credentials – Delete AccessKeys if created only for the lab (preferred). – Remove local CLI credential profiles if needed.

11. Best Practices

Architecture best practices

Use DNS for naming and coarse routing, not precise load balancing. For strict traffic control, prefer SLB, gateway, or application-layer mechanisms.
Separate public and private DNS:
Public hostnames in Alibaba Cloud DNS
Internal service discovery in PrivateZone (separate product) or internal DNS
Use subdomain delegation to isolate teams/environments:
dev.example.com delegated to a dev account/team
prod.example.com tightly controlled

IAM/security best practices

Never use the root account for daily DNS changes.
Create RAM roles/users for:
Read-only DNS audit
Record editor for specific zones
Automation role for CI/CD
Require MFA for console access and use least privilege for APIs.
Protect AccessKeys in a secrets manager; rotate regularly.

Cost best practices

Keep TTLs reasonable (avoid globally low TTL unless necessary).
Use advanced routing and health checks only for critical hostnames.
Consolidate records when possible (avoid unnecessary record sprawl).

Performance best practices

Use higher TTLs for stable endpoints to maximize caching.
Lower TTLs before planned migrations/cutovers, then restore higher TTLs afterward.
Avoid frequent DNS changes for highly cached names; use indirection:
www -> CNAME app-edge.example.net
Then shift app-edge targets

Reliability best practices

Design endpoints for failure: multi-AZ load balancing, multi-region DR, and application resilience.
Consider a multi-provider DNS strategy for mission-critical domains (complexity tradeoff).
Maintain runbooks for:
Registrar access
NS delegation
Emergency rollback procedures

Operations best practices

Track DNS changes with tickets/PRs and peer review.
Use automated checks:
“No CNAME conflicts”
“MX records valid”
“SPF/DKIM/DMARC syntax checks”
Monitor externally:
DNS resolution from multiple networks/regions
HTTPS health checks on key hostnames

Governance/tagging/naming best practices

Use consistent naming:
app, api, auth, static, cdn, status
dev/staging/prod subdomains
Document ownership per zone and per critical record.
Maintain an inventory of zones and their delegations.

12. Security Considerations

Identity and access model

Use RAM to control who can manage DNS.
Prefer role-based access and avoid sharing credentials.
For automation, use least-privilege policies and rotate credentials.

Encryption

DNS queries are traditionally unencrypted (UDP/TCP 53) between resolvers and authoritative servers.
Some clients use DoH/DoT to recursive resolvers, but authoritative DNS is still served per standard DNS protocols. The authoritative hop is generally not end-to-end encrypted.
Use TLS at the application layer (HTTPS) regardless of DNS.

Network exposure

Public DNS records are public by design:
Do not publish private RFC1918 addresses in public zones unless you intentionally want split-horizon behavior and understand the risk.
For internal names, use PrivateZone or internal DNS.

Secrets handling

Avoid placing sensitive data in TXT records (they are public).
For verification tokens (ACME), keep TTL low and remove tokens after issuance.

Audit/logging

Use ActionTrail to capture DNS management events (adds accountability).
Store audit logs in a secure logging destination with retention and access control.

Compliance considerations

Many compliance regimes require:
Least privilege
Auditable change history
Separation of duties
Implement DNS change workflows via CI/CD + approvals.

Common security mistakes

Leaving AccessKeys in code repositories.
Granting broad alidns:* to too many users.
Allowing direct production DNS edits without review.
Forgetting to lock down registrar access (registrar compromise can override your DNS provider entirely).

Secure deployment recommendations

Protect registrar account with MFA and strong recovery controls.
Implement a “break glass” emergency procedure with audited access.
Use DNSSEC if it is supported and your team can operate it safely (key rollover planning is non-negotiable).

13. Limitations and Gotchas

Because limits vary by edition and evolve, treat these as common gotchas and confirm specifics in official docs:

DNS caching makes changes non-instant: TTL and resolver behavior can delay cutovers.
CNAME constraints: A name with a CNAME generally cannot have other record types.
Apex/root limitations: Some DNS providers handle root aliases differently. Confirm Alibaba Cloud DNS behavior for apex to CDN/load balancer patterns.
Quota ceilings: Zones, records, and API rate limits can block automation at scale.
Health checks are not instant failover: Even with health checks, cached answers can persist.
DNSSEC operational risk: Misconfigured DS records can cause complete resolution failure.
Registrar lock-in: DNS provider and registrar are separate; losing registrar access is catastrophic.
Internationalized domain names (IDN): Confirm punycode handling and console expectations.
Propagation time for NS changes: TLD NS updates can take longer than record TTL changes.
Split-horizon needs separate tooling: Public authoritative DNS is not a private service discovery tool; use PrivateZone or internal DNS.

14. Comparison with Alternatives

In Alibaba Cloud

Alibaba Cloud DNS: Public authoritative DNS hosting.
PrivateZone (separate product): Private DNS zones inside VPC networks for internal service names.

In other clouds

AWS Route 53: Authoritative DNS + health checks + routing policies.
Azure DNS: Authoritative DNS integrated with Azure.
Google Cloud DNS: Authoritative DNS for GCP.

Open-source / self-managed

BIND: Mature authoritative/recursive DNS server; high operational burden.
PowerDNS: Authoritative DNS with API; can be self-hosted.
Knot DNS: High-performance authoritative server.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Alibaba Cloud DNS	Hosting public DNS zones on Alibaba Cloud	Managed authoritative DNS, console/API/CLI, IAM via RAM, ecosystem fit	Advanced features depend on edition; DNS caching limits traffic control	You run workloads on Alibaba Cloud and want integrated DNS governance
Alibaba Cloud PrivateZone (separate)	Internal DNS in VPCs	Private/internal name resolution, split-horizon internal services	Not for public internet authoritative DNS	You need internal service discovery and private zones
AWS Route 53	AWS-centric global deployments	Mature routing policies and integrations	Different ecosystem; potential cross-cloud complexity	You are primarily on AWS or need Route 53-specific routing features
Azure DNS	Azure-centric orgs	Solid integration with Azure	Less relevant if you’re Alibaba Cloud-centric	Your workloads and governance are mostly in Azure
Google Cloud DNS	GCP-centric orgs	Simple managed authoritative DNS	Less relevant outside GCP	Your workloads are primarily on GCP
Cloudflare DNS	Internet-facing apps needing edge features	Strong global edge, DDoS protection options, easy UI	Vendor ecosystem differences; some features proprietary	You want a DNS provider tightly coupled with edge security/performance services
Self-managed (BIND/PowerDNS)	Full control / on-prem requirements	Maximum configurability, can run anywhere	High ops burden, patching, scaling, security hardening	You must run authoritative DNS on-prem or need custom DNS behavior

15. Real-World Example

Enterprise example: Multi-region e-commerce with controlled DNS change management

Problem: An e-commerce company runs in two Alibaba Cloud regions for resilience. They need controlled DNS changes, DR failover options, and auditable operations.
Proposed architecture:
www.example.com -> Alibaba Cloud CDN (CNAME)
CDN origin -> SLB in Region A and Region B (origin failover via CDN/origin policy, plus optional DNS-level routing if supported)
api.example.com -> SLB Region A (primary) and SLB Region B (secondary)
DNS changes managed via CI pipeline using alidns APIs
ActionTrail enabled for auditing DNS changes
Why Alibaba Cloud DNS:
Centralized DNS management in the Alibaba Cloud ecosystem
RAM-based least privilege for teams and automation
Optional intelligent routing/health check capabilities depending on edition (verify)
Expected outcomes:
Faster, safer cutovers for deployments
Auditable DNS operations for compliance
Improved resilience during regional incidents (combined with app-level DR)

Startup/small-team example: SaaS app with custom domains and automated certificate validation

Problem: A small SaaS team needs to support customer custom domains and issue certificates using DNS-01 challenges.
Proposed architecture:
tenant.customer.com CNAME -> tenant.saas.example.com
Ownership verification with TXT record
Automation service uses Alibaba Cloud CLI/API to add _acme-challenge TXT records during certificate issuance
Why Alibaba Cloud DNS:
Simple API/CLI automation for DNS updates
Easy management of records for verification and ACME
Expected outcomes:
Automated certificate issuance and renewals
Reduced manual ops work
Consistent governance as the company scales

16. FAQ

1) Is Alibaba Cloud DNS the same as a domain registrar?
No. Domain registration and authoritative DNS hosting are separate. You can register a domain with one provider and host DNS with Alibaba Cloud DNS by changing authoritative name servers.

2) Do I have to register my domain with Alibaba Cloud to use Alibaba Cloud DNS?
Typically no. You can host DNS for domains registered elsewhere by delegating to Alibaba Cloud name servers. Verify any account-specific constraints in the console.

3) What is the difference between Alibaba Cloud DNS and PrivateZone?
Alibaba Cloud DNS hosts public authoritative zones. PrivateZone (separate product) provides private DNS inside VPC networks for internal names.

4) How long do DNS changes take to propagate?
Record changes propagate according to TTL and resolver caching behavior. NS delegation changes at the registrar can take longer. Always validate using authoritative NS queries first.

5) Can I use Alibaba Cloud DNS for multi-region failover?
Possibly, depending on edition and supported features like health checks and routing policies. Verify in current Alibaba Cloud DNS docs/pricing.

6) Does Alibaba Cloud DNS support DNSSEC?
It may, depending on zone type/edition and region. DNSSEC requires DS record configuration at the registrar. Verify current DNSSEC documentation before enabling.

7) Can I point the root domain (example.com) to a CDN using CNAME?
DNS standards don’t allow a CNAME at the apex if there are other records like SOA/NS. Some providers offer “alias” features. Confirm Alibaba Cloud DNS behavior for apex routing in official docs.

8) What TTL should I use?
For stable production endpoints, higher TTLs reduce query volume and increase stability. For planned cutovers, temporarily lower TTL ahead of time. Common TTLs range from 60 seconds to 3600 seconds, but choose based on your operational needs.

9) How do I safely migrate from another DNS provider?
Recreate all records in Alibaba Cloud DNS, validate by querying Alibaba authoritative name servers directly, then switch NS at the registrar. Keep the old DNS zone unchanged until you confirm stable resolution.

10) Can I automate DNS changes in CI/CD?
Yes—use Alibaba Cloud DNS APIs/CLI with a least-privilege RAM role/user. Avoid embedding long-lived keys in code.

11) What record types do I need for email?
Typically MX plus TXT records for SPF, DKIM, and DMARC. Your email provider will supply exact values.

12) Why do I see different answers from different locations/resolvers?
Caching and resolver routing can cause differences. If you use intelligent/line-based resolution, answers can vary intentionally based on client/resolver location.

13) How do I troubleshoot “it works for me but not for users”?
Test with multiple public resolvers (1.1.1.1, 8.8.8.8) and query authoritative NS directly. Confirm TTL and whether some resolvers cached old answers.

14) Is DNS a good way to do canary releases?
DNS can help with coarse rollout via weighted records (if supported), but caching makes it imprecise. For reliable canaries, use load balancers/service mesh/application routing.

15) How do I prevent accidental DNS outages?
Use least privilege, peer review, change windows for critical zones, monitoring, and runbooks. Avoid direct manual edits for production unless necessary.

16) Can I delegate only a subdomain to Alibaba Cloud DNS?
Yes. Delegate dev.example.com or lab.example.com via NS records from your parent zone. This is a good low-risk adoption path.

17) Where can I see who changed a DNS record?
Use ActionTrail (management event auditing) to track API/console calls. Verify exact event names and coverage in Alibaba Cloud docs.

17. Top Online Resources to Learn Alibaba Cloud DNS

Resource Type	Name	Why It Is Useful
Official documentation	Alibaba Cloud DNS Documentation – https://www.alibabacloud.com/help/en/alibaba-cloud-dns/	Primary, authoritative source for features, workflows, and APIs
Product page	Alibaba Cloud DNS – https://www.alibabacloud.com/product/dns	High-level overview and positioning in Alibaba Cloud ecosystem
Official pricing	Alibaba Cloud DNS Pricing – https://www.alibabacloud.com/product/dns/pricing	Edition comparison and billing model (verify region/edition details)
CLI documentation	Alibaba Cloud CLI – https://www.alibabacloud.com/help/en/alibaba-cloud-cli/latest/what-is-alibaba-cloud-cli	How to install/configure CLI used for DNS automation
OpenAPI reference (entry)	Alibaba Cloud OpenAPI Portal – https://api.alibabacloud.com/	Find DNS (`alidns`) API actions and parameters
IAM documentation	Resource Access Management (RAM) – https://www.alibabacloud.com/help/en/ram/	Implement least privilege for DNS operations
Audit logging	ActionTrail – https://www.alibabacloud.com/help/en/actiontrail/	Audit DNS changes and API calls for compliance and troubleshooting
Architecture guidance	Alibaba Cloud Architecture Center – https://www.alibabacloud.com/architecture	Patterns for multi-region, DR, and scalable web architectures (DNS as a component)
Community learning	Alibaba Cloud Blog – https://www.alibabacloud.com/blog	Practical articles and updates; validate details against docs
Video learning	Alibaba Cloud YouTube – https://www.youtube.com/@AlibabaCloud	Webinars and service walkthroughs; confirm latest UI flows

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website
DevOpsSchool.com	DevOps engineers, SREs, platform teams	Cloud/DevOps tooling, automation, operational practices (check course outline for Alibaba Cloud content)	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	DevOps fundamentals, SCM/CI/CD, operations practices	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers, operations teams	Cloud operations, reliability, monitoring (confirm Alibaba Cloud coverage)	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, production ops	SRE practices, incident response, reliability engineering	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops and platform teams	AIOps concepts, observability, automation	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website
RajeshKumar.xyz	DevOps/cloud training content (verify current offerings)	Students, working engineers	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training programs (verify cloud coverage)	Beginners to intermediate DevOps engineers	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps guidance/services (verify current scope)	Teams needing short-term help	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support/training resources (verify current scope)	Ops teams and engineers	https://www.devopssupport.in/

20. Top Consulting Companies

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website
cotocus.com	Cloud/DevOps consulting (verify current portfolio)	DNS governance, automation pipelines, cloud architecture reviews	DNS migration plan, CI/CD DNS automation, incident readiness runbooks	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and enablement	Platform engineering, IaC, DevOps processes (confirm Alibaba Cloud experience)	Build DNS-as-code workflows, implement least privilege RAM policies	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify current offerings)	Operations maturity, automation, monitoring	DNS change governance, external monitoring setup for key domains	https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Alibaba Cloud DNS

DNS fundamentals: authoritative vs recursive, NS delegation, TTL, record types
Basic networking: IP addressing, HTTP/HTTPS, load balancing concepts
Security fundamentals: IAM, least privilege, MFA, audit logging
Basic Alibaba Cloud concepts: accounts, RAM, regions, billing

What to learn after Alibaba Cloud DNS

Alibaba Cloud CDN and edge patterns (DNS + CDN integration)
Server Load Balancer (SLB) architectures and multi-AZ design
Infrastructure as Code (Terraform or other IaC) for repeatable DNS management (verify provider support for Alibaba Cloud DNS resources)
Observability: synthetic monitoring, SLOs/SLIs, incident response
Advanced DR and multi-region architectures

Job roles that use it

Cloud engineer / cloud administrator
DevOps engineer
SRE / production engineer
Platform engineer
Security engineer (DNS governance and auditing)
Solutions architect

Certification path (if available)

Alibaba Cloud certifications change over time. Check Alibaba Cloud Certification portal for current tracks and whether DNS is covered explicitly: – https://edu.alibabacloud.com/certification (verify current URL/structure)

Project ideas for practice

Build a “DNS-as-code” repo that:
Creates zone records via CI using aliyun alidns commands
Validates changes with dig before merge
Implement subdomain delegation for dev/staging/prod and separate RAM roles per environment
Automate ACME DNS-01 challenges for wildcard certs (carefully handle secrets and cleanup TXT records)
Build an external DNS + HTTP monitoring dashboard for critical hostnames

22. Glossary

Authoritative DNS: The DNS server/service that hosts the official records for a domain and answers with authority.
Recursive resolver: A DNS server that queries authoritative servers on behalf of clients and caches results.
Zone: A DNS namespace hosted by an authoritative provider (often the domain like example.com).
Record: A mapping in DNS (e.g., A, AAAA, CNAME, MX, TXT).
NS record: Name server record indicating which servers are authoritative for a domain/zone.
SOA record: Start of Authority record containing zone metadata.
TTL: Time-to-live; how long resolvers cache a DNS answer.
FQDN: Fully qualified domain name, e.g., api.example.com.
A record: Maps a name to an IPv4 address.
AAAA record: Maps a name to an IPv6 address.
CNAME record: Alias from one name to another canonical name.
MX record: Mail exchanger record for email routing.
TXT record: Free-form text record used for verification and email auth (SPF/DKIM/DMARC).
DNSSEC: DNS Security Extensions; signs DNS data to prevent certain spoofing attacks.
Delegation: Assigning authority for a domain/subdomain to specific name servers via NS records.
RAM: Resource Access Management; Alibaba Cloud’s IAM service.
ActionTrail: Alibaba Cloud service for auditing API/console actions.

23. Summary

Alibaba Cloud DNS is Alibaba Cloud’s managed authoritative DNS service in the Networking and CDN category. It hosts public DNS zones, lets you manage records through the console/API/CLI, and supports operational controls through RAM and auditing integrations.

It matters because DNS is a critical dependency for nearly every internet-facing workload—websites, APIs, email, certificate validation, and multi-region architectures. Cost is typically driven by your plan/edition, query volume, and optional advanced features like intelligent routing and health checks (verify on the official pricing page). Security depends heavily on strong IAM (RAM), registrar protection, careful change management, and optional DNSSEC if you can operate it safely.

Use Alibaba Cloud DNS when you want managed authoritative DNS with Alibaba Cloud ecosystem alignment and automation-friendly operations. Next, practice by delegating a subdomain, automating record changes with the alidns CLI, and implementing monitoring and audited change workflows for production zones.

Category