Cloud DNS Managed Zones: Public so với Private

Tại sao điều này quan trọng trong production

Managed zone là đơn vị cơ bản nhất (atomic unit) của Cloud DNS—tất cả các records, policies, permissions, logging đều được liên kết (attached) ở cấp độ zone. Việc thiết kế phân cấp zone (zone hierarchy) sai ngay từ đầu sẽ dẫn đến những hậu quả dây chuyền (cascade):

Phạm vi ảnh hưởng (Blast radius): Khi xóa một zone đồng nghĩa với việc toàn bộ records trong zone đó bị mất
Mô hình phân quyền (Permission model): Áp dụng IAM binding ở cấp độ zone (Zone-level IAM binding), không phân quyền chi tiết đến cấp độ record (record level)
Chi phí & hạn mức (Billing & quota): Chi phí được tính trên mỗi zone, hạn mức (quota) cũng áp dụng trên từng zone
Kiến trúc Split-horizon (Split-horizon architecture): Sử dụng đồng thời cả public và private zone cho cùng một domain sẽ làm tăng độ phức tạp trong quản lý
Chia sẻ đa dự án (Multi-project sharing): Thực hiện thông qua DNS peering chứ không chia sẻ zone trực tiếp
Chi phí vận hành (Operational overhead): Phải đồng bộ hóa giữa nhiều zone (nếu cần thiết) và thực hiện xác thực (validation)

Thực tế: Một doanh nghiệp có thể phải quản lý hơn 500 zone (cho development, staging, production, dịch vụ bên ngoài). Mỗi zone đều là một điểm rủi ro. Thiết kế sai lầm sẽ dẫn đến ngừng hoạt động (outages) và tốn kém chi phí gỡ lỗi (troubleshooting).

Kiến Thức Cơ Bản Managed Zone

Trong Cloud DNS, managed zone là một tập hợp các DNS records dành cho một domain cụ thể:

Managed Zone "production.example.com" {
  Zone Name: "production.example.com"
  Records: 
    - service.production.example.com A 10.0.1.5
    - api.production.example.com A 10.0.2.100
    - db.production.example.com A 10.0.3.50
  Loại: Public | Private
  Phạm vi hiển thị (Visibility): internet-wide | VPC-specific
  Nameservers: ns-*.googledomains.com (auto-managed)
}

GCP sẽ tự động quản lý:

Hạ tầng nameserver (phân tán toàn cầu)
Tự động đồng bộ cấu hình zone (zone propagation)
Bật mã hóa bảo mật DNSSEC (tùy chọn)
Xử lý truy vấn (query) thông qua anycast routing

Bạn chỉ quản lý:

Tạo/xoá zone
Quản lý records (thêm/sửa/xoá)
Kiểm soát truy cập (IAM)
Các chính sách (policies) như forwarding, peering, response policies

Đặc Điểm Zone

Thuộc tính	Public Zone	Private Zone
Phạm vi hiển thị (Visibility)	Toàn internet	Chỉ trong VPC
Authoritative Nameservers	GCP global DNS	Trình phân giải nội bộ của VPC (GCP VPC-internal resolvers)
Phân giải (Resolve) từ bên ngoài	Có (từ bất kỳ đâu)	Không (chỉ trong VPC được cấu hình)
Trường hợp sử dụng (Use Case)	Domain công khai, website, các API	Dịch vụ nội bộ, cơ sở dữ liệu (databases)
Cập nhật Nameserver	Cập nhật tại nhà đăng ký domain (domain registrar)	Không cần nhà đăng ký (registrar)
Chi phí	$0.20/zone/tháng, $0.40/triệu truy vấn (queries)	Như nhau

Public Managed Zones

Mục đích

Public managed zones lưu trữ (host) các DNS records cho các domain có thể phân giải (resolve) từ bất kỳ đâu trên internet.

External User (8.8.8.8 resolver)
  truy vấn (query): api.example.com?
    ↓
  GCP Global DNS Servers (anycast 216.239.32.10)
    ↓
  [Public Zone "example.com"]
    ↓
  Response: 35.201.100.50 (public IP)

Quy Trình Tạo Zone

bash

# Step 1: Create public zone
gcloud dns managed-zones create example-zone \
  --dns-name=example.com \
  --visibility=public

# Step 2: Get nameservers
gcloud dns managed-zones describe example-zone --format="value(nameServers)"
# Output:
# ns-123.googledomains.com.
# ns-456.googledomains.com.
# ns-789.googledomains.com.
# ns-1011.googledomains.com.

# Step 3: Update domain registrar
# Login to registrar (GoDaddy, Namecheap, etc.)
# Update nameservers to: ns-123.googledomains.com, ns-456.googledomains.com, etc.

# Step 4: Add records
gcloud dns record-sets transaction start --zone=example-zone
gcloud dns record-sets transaction add 35.201.100.50 \
  --name=api.example.com \
  --type=A \
  --ttl=300 \
  --zone=example-zone
gcloud dns record-sets transaction execute --zone=example-zone

# Step 5: Verify
dig api.example.com @ns-123.googledomains.com
# Should return 35.201.100.50

Ràng Buộc Đặt Tên

Tên của public zone phải tuân thủ các quy tắc đặt tên domain:

Hợp lệ:
- example.com
- api.example.com (subdomain)
- staging-api.example.com
- db-001.staging.example.com

Không hợp lệ:
- example (không có TLD - tên miền cao cấp nhất)
- .example.com (dấu chấm đầu)
- example.com. (dấu chấm cuối - gcloud sẽ tự động thêm vào)
- EXAMPLE.COM (không phân biệt chữ hoa/thường, hệ thống tự chuyển về chữ thường - lowercase)

Quan trọng: Tên zone phải trùng khớp với nhà đăng ký domain (domain registrar). Nếu bạn sở hữu domain example.com, bạn có thể tạo các zone sau:

example.com (root)
api.example.com (subdomain zone)
staging.example.com (subdomain zone)

Nhưng bạn không thể tạo zone other.com nếu bạn không thực sự sở hữu other.com.

Mô hình Production (Production Pattern): Phân cấp Zone

Thay vì sử dụng một zone lớn duy nhất, hãy chia nhỏ thành nhiều zone nhỏ hơn:

Cấu hình trong production:
├── example.com (root, ít records)
│   ├── A 35.201.100.50 (website)
│   └── MX 10 mail.example.com (email)
│
├── api.example.com (API zone)
│   ├── A 35.201.100.51
│   ├── api-v1.api.example.com A 10.0.1.100
│   └── api-v2.api.example.com A 10.0.2.100
│
├── cdn.example.com (CDN zone)
│   └── CNAME *.cdn.example.com trỏ tới nhà cung cấp CDN (CDN provider)
│
└── staging.example.com (staging)
    └── A 35.201.100.52

Lợi ích:

Cô lập quyền truy cập: Đội ngũ (Team) api.example.com sẽ chỉ chịu trách nhiệm quản lý api zone
An toàn trong vận hành: Việc xóa api zone không làm ảnh hưởng đến zone cha example.com
Thời gian sống (TTL) linh hoạt: Cấu hình TTL của api zone là 60s, staging là 300s
Quản lý hạn mức (Quota): Hạn mức được cô lập an toàn theo từng zone riêng biệt

Private Managed Zones

Mục đích

Private managed zones giúp phân giải (resolve) các truy vấn DNS (DNS queries) chỉ từ các VPC được cấp quyền (authorized VPCs). Thường được sử dụng cho các dịch vụ nội bộ (internal-only services).

Internal VM (10.0.1.5 in VPC A)
  truy vấn (query): db.internal.example.com?
    ↓
  GCP VPC Resolver (only within VPC A)
    ↓
  [Private Zone "internal.example.com" bound to VPC A]
    ↓
  Response: 10.0.3.50 (private IP)

External User (8.8.8.8 resolver)
  truy vấn (query): db.internal.example.com?
    ↓
  Không thể phân giải (zone không hiển thị)
    ↓
  Response: NXDOMAIN

Tạo Zone & Gắn VPC

bash

# Step 1: Create private zone
gcloud dns managed-zones create internal-zone \
  --dns-name=internal.example.com \
  --visibility=private \
  --networks=projects/PROJECT_ID/global/networks/VPC_NAME

# Step 2: Add records
gcloud dns record-sets transaction start --zone=internal-zone
gcloud dns record-sets transaction add 10.0.3.50 \
  --name=database.internal.example.com \
  --type=A \
  --ttl=60 \
  --zone=internal-zone
gcloud dns record-sets transaction execute --zone=internal-zone

# Step 3: Bind to additional VPCs (if needed)
gcloud dns managed-zones update internal-zone \
  --networks=projects/PROJECT_ID/global/networks/VPC_NAME_2

Ý nghĩa của việc liên kết VPC (VPC Binding)

Việc gắn một private zone sẽ tuân theo quy tắc hoạt động sau:

Zone "db.internal" gắn vào: [VPC A, VPC B]
  ↓
Tài nguyên thuộc VPC A: Phân giải (Resolve) được db.internal ✓
Tài nguyên thuộc VPC B: Phân giải (Resolve) được db.internal ✓
Tài nguyên thuộc VPC C: Không phân giải (Resolve) được db.internal ✗
Tài nguyên thuộc VPC D (dự án khác): Không phân giải (Resolve) được db.internal ✗

Liên kết xuyên dự án (Cross-project): Bạn cần sử dụng DNS peering (một tính năng riêng), chứ không thể chia sẻ zone trực tiếp.

Ảnh hưởng đến kiến trúc đa VPC (Multi-VPC Architecture)

Trường hợp sử dụng Shared VPC (khuyến nghị):

Dự án gốc (Host Project) quản lý DNS tập trung
├── Shared VPC
├── Private Zone "internal.prod.example.com"
│   └── Gắn vào: Shared VPC (mọi dự án dịch vụ - service project đều phân giải được)

Service Project A
├── Các VM/GKE nằm trong Shared VPC → Phân giải (Resolve) được internal.prod.example.com

Service Project B
├── Các VM/GKE nằm trong Shared VPC → Phân giải (Resolve) được internal.prod.example.com

Trường hợp không dùng Shared VPC (không khuyến nghị do phức tạp):

Project A: VPC A
├── Private Zone "a-internal.example.com" (gắn vào VPC A)
Project B: VPC B
├── Private Zone "b-internal.example.com" (gắn vào VPC B)

Cần cấu hình DNS peering để phân giải chéo giữa các dự án (resolve cross-project).

Quy tắc đặt tên Zone

Quy ước 1: Phân tách môi trường

Production: prod.example.com, api.prod.example.com
Staging: staging.example.com, api.staging.example.com
Development: dev.example.com, api.dev.example.com

Lợi ích: Giúp cô lập môi trường rõ ràng, dễ dàng phân chia quyền hạn.

Quy ước 2: Phân tách theo Đội ngũ/Dịch vụ (Team/Service)

Team auth: auth.internal.example.com
Team backend: backend.internal.example.com
Team data: data.internal.example.com
Team infra: infra.internal.example.com

Lợi ích: Mỗi đội ngũ có thể tự quản lý DNS của mình, xác định rõ trách nhiệm sở hữu.

Quy ước 3: Phân chia theo vị trí địa lý (Multi-region)

us-central1: us-c1.example.com
us-east1: us-e1.example.com
europe-west1: eu-w1.example.com

Lợi ích: Hỗ trợ chuyển vùng khi có sự cố (failover) theo vùng (region), tối ưu hóa cân bằng tải (load balancing).

Quy ước 4: Kết hợp các quy tắc trên (Khuyên dùng cho tổ chức lớn)

example.com (root)
├── api.prod.example.com (API của môi trường production, dùng chung không phụ thuộc team)
├── backend.prod.example.com (Các dịch vụ backend, thuộc quyền quản lý của team)
├── data.prod.example.com (Các dịch vụ dữ liệu - data services, thuộc quyền quản lý của team)
└── internal.prod.example.com (Các công cụ nội bộ, dùng chung cho mọi team)

Kiểm soát quyền truy cập Zone (IAM)

Quyền hạn được cấp ở cấp độ zone, không áp dụng riêng lẻ cho từng record:

bash

# Cấp quyền chỉ đọc (read) cho team
gcloud dns managed-zones add-iam-policy-binding api-prod-zone \
  --member=group:backend-team@company.com \
  --role=roles/dns.reader

# Cấp quyền quản trị DNS (DNS editor)
gcloud dns managed-zones add-iam-policy-binding api-prod-zone \
  --member=group:dns-admins@company.com \
  --role=roles/dns.admin

# Chỉ tạo record (không xóa zone)
gcloud dns managed-zones add-iam-policy-binding api-prod-zone \
  --member=serviceAccount:automation@project.iam.gserviceaccount.com \
  --role=roles/dns.recordAdmin

Các vai trò (roles) chính:

roles/dns.admin: Cấp toàn quyền quản trị (tạo/xóa/sửa zone)
roles/dns.recordAdmin: Chỉ được phép chỉnh sửa records (không được xóa zone)
roles/dns.reader: Chỉ được phép đọc thông tin

Mô hình áp dụng trong Production (Production Pattern):

Lập trình viên (Developer): Gán quyền dns.recordAdmin để chỉnh sửa records
Kỹ sư hạ tầng (Platform engineer): Gán quyền dns.admin để quản lý zone
Công cụ tự động hóa (Automation như Terraform): Gán quyền dns.recordAdmin

Hạn mức (Quota) và Giới hạn

Hạn mức Cloud DNS được tính trên từng zone:

Quota	Giới hạn	Ý nghĩa
Số lượng Records mỗi zone	100,000	Đủ dùng cho hầu hết trường hợp, cần chú ý khi triển khai (deploy) lớn
Số lượng Record sets mỗi zone	100,000	Tương tự như trên
Số lượng truy vấn mỗi giây (QPS)	Đột biến (Burst): 1000 QPS, duy trì (sustained): burst/zone	Sẽ bị giới hạn tốc độ (rate limit) nếu vượt quá
Thời gian thay đổi nameserver	Lan truyền trong vài giây	Có hiệu lực ngay lập tức (khác với DNS truyền thống)

Ví dụ: Nếu một zone chạm ngưỡng giới hạn (rate limit), các truy vấn (queries) gửi đến các zone khác sẽ không bị ảnh hưởng nhờ cơ chế cô lập.

Giám sát hạn mức (quota):

bash

gcloud compute project-info describe --project=PROJECT_ID --format='value(quotas[name:QUOTA_NAME].limit)'

# Để theo dõi tỷ lệ truy vấn (query rate):
# Dùng Cloud Monitoring → xem các DNS metrics

Xóa Zone và Khả năng Phục hồi

Cơ chế xóa

Thực hiện xóa zone:

bash

gcloud dns managed-zones delete zone-name
# Zone sẽ lập tức biến mất khỏi console
# Các record sẽ ngừng phân giải (resolve) sau vài giây
# Tuy nhiên: Thông tin zone vẫn được lưu vết trong Cloud Audit Logs

Khả năng phục hồi (trong vòng 30 ngày):

bash

# Nếu zone bị xóa, bạn cần tạo lại một zone trùng tên rồi phục hồi (restore) lại các record
# (Hệ thống không hỗ trợ tự động phục hồi như dịch vụ Google Cloud Storage)

Lưu ý quan trọng trong production: Hãy luôn sao lưu (backup) các record trong zone (thông qua Terraform, Ansible, hoặc các kịch bản script).

bash

# Sao lưu (Backup) các record của zone
gcloud dns record-sets list --zone=zone-name > zone-backup.txt

# Hoặc sử dụng Terraform (phương án khuyên dùng)
resource "google_dns_managed_zone" "prod" {
  name        = "prod-zone"
  dns_name    = "prod.example.com"
  description = "Production zone - IaC managed"
}
resource "google_dns_record_set" "api" {
  name = "api.prod.example.com"
  type = "A"
  ttl  = 300
  rrdatas = ["10.0.1.5"]
  managed_zone = google_dns_managed_zone.prod.name
}

Các lỗi thường gặp và cách phòng tránh

❌ Lỗi 1: Sử dụng duy nhất một zone cho tất cả các dịch vụ (services)

Zone "example.com" chứa:
  - các record cho API
  - các record cho cơ sở dữ liệu (database)
  - các record cho công cụ nội bộ
  - các record cho môi trường staging

Vấn đề: Không thể thực hiện cô lập quyền hạn, không thể xóa các record của staging mà không gây ảnh hưởng đến môi trường production.

Giải pháp: Hãy chia nhỏ thành nhiều zone riêng biệt (ví dụ: api.example.com, db.example.com, staging.example.com).

❌ Lỗi 2: Dùng public zone cho các dịch vụ nội bộ

Private Zone: Không được cấu hình
Public Zone "example.com" chứa:
  - api.example.com → 10.0.1.5 (Làm LỘ địa chỉ IP nội bộ - private IP ra ngoài internet!)

Vấn đề: Các địa chỉ IP nội bộ (private IP) bị phơi bày ra ngoài internet, và có thể phân giải được từ cả bên trong lẫn bên ngoài.

Giải pháp: Sử dụng mô hình private zone chuyên biệt cho các dịch vụ nội bộ.

❌ Lỗi 3: Không thực hiện sao lưu (backup) zone

Zone bị xóa nhầm → Hoàn toàn không thể tự phục hồi

Giải pháp: Quản lý bằng Terraform dưới dạng Infrastructure as Code (IaC) và thiết lập sao lưu tự động.

❌ Lỗi 4: Cấu hình giá trị TTL không hợp lý

database.internal.example.com TTL=0
→ Mọi truy vấn (query) đều phải gửi trực tiếp đến authoritative nameserver
→ Làm tăng độ trễ (latency) và dễ bị giới hạn tần suất truy cập (rate limit)

Giải pháp: Đặt TTL=300 (5 phút) cho các record ít thay đổi, và TTL=60 cho các record thường xuyên cập nhật.

Zone Naming và Hành vi của Resolver

Ủy quyền Subdomain (Subdomain Delegation - quan trọng khi mở rộng)

Trong trường hợp zone "example.com" đang tồn tại, trình phân giải (resolver) sẽ xử lý truy vấn cho "api.example.com" như thế nào?

Kịch bản 1 (Scenario 1): api.example.com là một bản ghi A record nằm ngay trong zone cha

Zone "example.com" {
  api.example.com A 10.0.1.5
}

Truy vấn (Query): api.example.com?
→ Phân giải (Resolve) trực tiếp trong zone → Trả về 10.0.1.5

Kịch bản 2 (Scenario 2): api.example.com được cấu hình như một zone độc lập riêng biệt (delegated zone)

Zone "example.com" {
  api.example.com NS ns-1.googledomains.com  # Cấu hình ủy quyền
}

Zone "api.example.com" {
  api.example.com A 10.0.1.5
}

Truy vấn (Query): api.example.com?
→ Zone cha example.com phản hồi: "hãy truy vấn máy chủ ns-1.googledomains.com"
→ ns-1 trả về: 10.0.1.5

Ảnh hưởng trong production: Việc ủy quyền subdomain sẽ tạo thêm 1 chặng DNS (DNS hop), làm tăng độ trễ (latency) lên một chút.

Đánh đổi (Trade-off):

Cấu hình Zone đơn: Vận hành đơn giản hơn, tốc độ nhanh hơn, nhưng bị hạn chế trong việc phân quyền
Cấu hình Nhiều zone: Phức tạp hơn trong quản lý, tăng nhẹ độ trễ (latency), nhưng tăng khả năng cô lập bảo mật

Khuyến nghị: Hãy sử dụng mô hình nhiều zone cho các tổ chức lớn, và duy trì một zone đơn cho các dự án quy mô nhỏ.

Các mô hình áp dụng trong Production (Production Patterns)

Mô hình 1: Cấu trúc Zone hướng Dịch vụ (Pattern 1)

Mỗi team sở hữu 1 zone:
- auth-team: auth.internal.example.com
- backend-team: api.internal.example.com
- data-team: db.internal.example.com

Lợi ích mang lại:
✓ Xác định trách nhiệm sở hữu rõ ràng
✓ Khả năng chỉnh sửa độc lập hoàn toàn
✓ Cơ chế cô lập quyền hạn tối ưu
✓ Dễ dàng thêm mới hoặc loại bỏ dịch vụ

Mô hình 2: Phân chia Zone theo Môi trường (Pattern 2)

prod.example.com (quản lý toàn bộ dịch vụ của môi trường prod)
staging.example.com (quản lý toàn bộ dịch vụ của môi trường staging)
dev.example.com (quản lý toàn bộ dịch vụ của môi trường dev)

Lợi ích mang lại:
✓ Dễ dàng nâng cấp (promote) dịch vụ giữa các môi trường (thông qua sao chép records)
✓ Tùy biến thời gian sống (TTL) khác nhau cho từng môi trường
✓ Tạo lập ranh giới kiểm toán (audit) rõ ràng

Mô hình 3: Kết hợp song song Public và Private (Pattern 3)

Zone "example.com" (mô hình public, cấu trúc tối giản)
  - example.com A 35.201.100.50 (website)
  - api.example.com A 35.201.100.51 (public API)

Zone "internal.example.com" (mô hình private, chỉ truy cập nội bộ)
  - database.internal.example.com A 10.0.3.50
  - cache.internal.example.com A 10.0.3.51
  - admin.internal.example.com A 10.0.1.100

Lợi ích mang lại:
✓ Xác lập ranh giới bảo mật public/private rõ ràng
✓ Các record public không bao giờ vô tình làm rò rỉ địa chỉ IP nội bộ (private IPs)
✓ Thiết lập các mô hình phân quyền hoàn toàn độc lập

Cloud DNS Managed Zones: Public so với Private ​

Tại sao điều này quan trọng trong production ​

Kiến Thức Cơ Bản Managed Zone ​

Đặc Điểm Zone ​

Public Managed Zones ​

Mục đích ​

Quy Trình Tạo Zone ​

Ràng Buộc Đặt Tên ​

Mô hình Production (Production Pattern): Phân cấp Zone ​

Private Managed Zones ​

Mục đích ​

Tạo Zone & Gắn VPC ​

Ý nghĩa của việc liên kết VPC (VPC Binding) ​

Ảnh hưởng đến kiến trúc đa VPC (Multi-VPC Architecture) ​

Quy tắc đặt tên Zone ​

Quy ước 1: Phân tách môi trường ​

Quy ước 2: Phân tách theo Đội ngũ/Dịch vụ (Team/Service) ​

Quy ước 3: Phân chia theo vị trí địa lý (Multi-region) ​

Quy ước 4: Kết hợp các quy tắc trên (Khuyên dùng cho tổ chức lớn) ​

Kiểm soát quyền truy cập Zone (IAM) ​

Hạn mức (Quota) và Giới hạn ​

Xóa Zone và Khả năng Phục hồi ​

Cơ chế xóa ​

Các lỗi thường gặp và cách phòng tránh ​

❌ Lỗi 1: Sử dụng duy nhất một zone cho tất cả các dịch vụ (services) ​

❌ Lỗi 2: Dùng public zone cho các dịch vụ nội bộ ​

❌ Lỗi 3: Không thực hiện sao lưu (backup) zone ​

❌ Lỗi 4: Cấu hình giá trị TTL không hợp lý ​

Zone Naming và Hành vi của Resolver ​

Ủy quyền Subdomain (Subdomain Delegation - quan trọng khi mở rộng) ​

Các mô hình áp dụng trong Production (Production Patterns) ​

Mô hình 1: Cấu trúc Zone hướng Dịch vụ (Pattern 1) ​

Mô hình 2: Phân chia Zone theo Môi trường (Pattern 2) ​

Mô hình 3: Kết hợp song song Public và Private (Pattern 3) ​

Tài liệu tham khảo (References) ​

Cloud DNS Managed Zones: Public so với Private

Tại sao điều này quan trọng trong production

Kiến Thức Cơ Bản Managed Zone

Đặc Điểm Zone

Public Managed Zones

Mục đích

Quy Trình Tạo Zone

Ràng Buộc Đặt Tên

Mô hình Production (Production Pattern): Phân cấp Zone

Private Managed Zones

Mục đích

Tạo Zone & Gắn VPC

Ý nghĩa của việc liên kết VPC (VPC Binding)

Ảnh hưởng đến kiến trúc đa VPC (Multi-VPC Architecture)

Quy tắc đặt tên Zone

Quy ước 1: Phân tách môi trường

Quy ước 2: Phân tách theo Đội ngũ/Dịch vụ (Team/Service)

Quy ước 3: Phân chia theo vị trí địa lý (Multi-region)

Quy ước 4: Kết hợp các quy tắc trên (Khuyên dùng cho tổ chức lớn)

Kiểm soát quyền truy cập Zone (IAM)

Hạn mức (Quota) và Giới hạn

Xóa Zone và Khả năng Phục hồi

Cơ chế xóa

Các lỗi thường gặp và cách phòng tránh

❌ Lỗi 1: Sử dụng duy nhất một zone cho tất cả các dịch vụ (services)

❌ Lỗi 2: Dùng public zone cho các dịch vụ nội bộ

❌ Lỗi 3: Không thực hiện sao lưu (backup) zone

❌ Lỗi 4: Cấu hình giá trị TTL không hợp lý

Zone Naming và Hành vi của Resolver

Ủy quyền Subdomain (Subdomain Delegation - quan trọng khi mở rộng)

Các mô hình áp dụng trong Production (Production Patterns)

Mô hình 1: Cấu trúc Zone hướng Dịch vụ (Pattern 1)

Mô hình 2: Phân chia Zone theo Môi trường (Pattern 2)

Mô hình 3: Kết hợp song song Public và Private (Pattern 3)

Tài liệu tham khảo (References)