DNS Peering: Phân giải Hybrid On-Premises

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

DNS peering là yếu tố hỗ trợ cốt lõi (critical enabler) cho các kiến trúc mạng lai (hybrid cloud architectures). Ví dụ nếu bạn có:

Các trung tâm dữ liệu nội bộ (On-premises data centers) kết hợp với GCP cloud
Nhiều nhà cung cấp đám mây (Multiple cloud providers) kết hợp với GCP
Mạng doanh nghiệp (Corporate network) kết hợp với tài nguyên trên GCP

Thì DNS peering là thành phần hạ tầng (infrastructure piece) tiếp theo cần triển khai sau split-horizon DNS.

Các kịch bản thực tế (Production scenarios) đòi hỏi sử dụng DNS peering:

Kịch bản 1: Mạng doanh nghiệp lai (Scenario 1: Hybrid Enterprise)
├── On-prem: dc.corp.internal (AD-integrated DNS)
├── GCP: gcp.corp.internal (Cloud DNS)
└── Nhu cầu (Need): Các máy chủ on-prem truy cập dịch vụ GCP qua DNS
                      Các dịch vụ GCP truy cập tài nguyên on-prem qua DNS

Kịch bản 2: Đa đám mây (Scenario 2: Multi-Cloud)
├── AWS: aws.corp.internal
├── GCP: gcp.corp.internal
└── Nhu cầu (Need): Tài nguyên trên các đám mây khác nhau có thể phân giải (resolve) lẫn nhau

Kịch bản 3: Di chuyển hệ thống dần dần (Scenario 3: Gradual Migration)
├── On-prem: legacy.example.com (BIND)
├── GCP: prod.example.com (Cloud DNS)
└── Nhu cầu (Need): Trong quá trình dịch chuyển, cả hai hệ thống đều phải hoạt động ổn định và không sử dụng IP tĩnh cứng (no hardcoded IPs)

Hệ quả khi cấu hình sai DNS (Cost of getting DNS wrong):

Phải khai báo IP tĩnh thủ công (manual IP hardcoding - một phản mẫu anti-pattern)
Hết thời gian chờ DNS (DNS timeouts) gây lỗi ứng dụng
Tăng độ trễ (latency) khi truy cập dịch vụ
Lỗ hổng bảo mật (các quy tắc tường lửa - firewall rules dựa trên tên miền không hoạt động được)

Nguyên lý cơ bản của DNS Peering

DNS Peering là gì? (What is DNS Peering)

DNS peering là cơ chế phân giải DNS xuyên dự án được cấp quyền (authorized cross-project DNS resolution). Cơ chế này cho phép VPC trong một dự án phân giải (resolve) các zone từ VPC của dự án khác.

Project A: VPC A
  ├── Private Zone "prod.internal.com"
  └── Bound to: VPC A

Project B: VPC B
  └── Ban đầu: Không thể phân giải (resolve) prod.internal.com
      
With DNS Peering:
  Project B → VPC B hiện đã có thể phân giải (resolve) prod.internal.com
              (thông qua zone của Dự án A)

So sánh DNS Peering với Forwarding (DNS Peering vs Forwarding)

Khía cạnh (Aspect)	Peering	Forwarding
Cơ chế (Mechanism)	Liên kết/sao chép zone (Zone replication/linking)	Chuyển hướng truy vấn (Query redirection)
Cấu hình (Setup)	Giữa các VPC trong GCP (Between GCP VPCs)	Trỏ đến máy chủ DNS bên ngoài (To external nameservers)
Hiệu năng (Performance)	Có bộ nhớ đệm, độ trễ thấp (Cached, low latency)	Thực hiện trên mỗi truy vấn, độ trễ cao hơn (Per-query, higher latency)
Phạm vi (Scope)	Toàn bộ zone (Entire zone)	Các truy vấn cụ thể (Specific queries)
Trường hợp sử dụng (Use Case)	Đa VPC trong GCP (Multi-VPC in GCP)	Mạng nội bộ/DNS bên ngoài (On-prem/external DNS)

Triển khai: Inbound Peering

Kiến trúc

Hub VPC (quản lý hạ tầng DNS dùng chung - shared DNS infrastructure):
├── Private Zone "prod.internal.example.com"
├── Inbound Server (129.154.169.252)
│   └── Lắng nghe các truy vấn peering (peering queries)

Spoke VPC (các dự án dịch vụ - service projects):
├── Thực hiện phân giải (Resolves) prod.internal.example.com
├── Thông qua inbound server 129.154.169.252
└── Nhận câu trả lời phân giải từ Hub zone

Các bước thiết lập

bash

# Bước 1: Tại Hub Project - Tạo inbound server
gcloud dns inbound-policies create hub-inbound \
  --networks=projects/HUB_PROJECT/global/networks/hub-vpc \
  --enable-inbound-forwarding

# Bước 2: Lấy địa chỉ IP của inbound server
gcloud compute addresses describe inbound-server-ip \
  --region=us-central1 \
  --project=HUB_PROJECT
# Kết quả trả về: 129.154.169.252

# Bước 3: Tại Spoke Project - Tạo forwarding zone
gcloud dns managed-zones create peered-zone \
  --dns-name=prod.internal.example.com \
  --visibility=private \
  --networks=projects/SPOKE_PROJECT/global/networks/spoke-vpc

# Bước 4: Thêm đích đến cho forwarding (forwarding target)
gcloud dns managed-zones update peered-zone \
  --inbound-forwarding-servers=129.154.169.252 \
  --project=SPOKE_PROJECT

# Bước 5: Xác minh từ spoke VPC
# Kết nối SSH tới VM trong spoke VPC, sau đó chạy:
nslookup service.prod.internal.example.com
# Kết quả phải phân giải ra IP từ zone của hub

Triển khai bằng Terraform (Terraform Implementation)

hcl

# Hub Project
resource "google_dns_managed_zone" "hub_prod" {
  project  = "hub-project"
  name     = "hub-prod-zone"
  dns_name = "prod.internal.example.com."
  
  private_visibility_config {
    networks_list {
      network_url = google_compute_network.hub_vpc.id
    }
  }
}

resource "google_dns_inbound_forwarding_policy" "hub_policy" {
  project = "hub-project"
  name    = "hub-inbound-policy"
  
  networks {
    network_url = google_compute_network.hub_vpc.id
  }
  
  inbound_forwarding_servers {
    address = "129.154.169.252"
  }
}

# Spoke Project
resource "google_dns_managed_zone" "spoke_peered" {
  project  = "spoke-project"
  name     = "spoke-peered-zone"
  dns_name = "prod.internal.example.com."
  
  private_visibility_config {
    networks_list {
      network_url = google_compute_network.spoke_vpc.id
    }
  }
  
  peering_config {
    target_network {
      network_url = "projects/hub-project/global/networks/hub-vpc"
    }
  }
}

Triển khai: Outbound Peering (Hai chiều - Bidirectional)

Nếu cả hai dự án (both projects) đều cần phân giải các zone của nhau:

Hub VPC:
  ├── Zone "prod.internal.example.com"
  └── Outbound forwarding to 129.154.169.253 (spoke inbound)

Spoke VPC:
  ├── Zone "staging.internal.example.com"
  └── Outbound forwarding to 129.154.169.252 (hub inbound)

Kết quả (Result): Phân giải hai chiều (Bidirectional resolution)

Thiết lập

bash

# Hub Project - Tạo chính sách outbound (outbound policy)
gcloud dns outbound-policies create hub-outbound \
  --networks=projects/HUB_PROJECT/global/networks/hub-vpc \
  --outbound-forwarding-servers=129.154.169.253  # Đầu vào (inbound) của Spoke

# Hub Project - Tạo forwarding zone cho tên miền (domain) của spoke
gcloud dns managed-zones create hub-staging-peered \
  --dns-name=staging.internal.example.com \
  --visibility=private \
  --networks=projects/HUB_PROJECT/global/networks/hub-vpc

gcloud dns managed-zones update hub-staging-peered \
  --inbound-forwarding-servers=129.154.169.253

# Spoke Project - Thiết lập tương tự (theo chiều ngược lại)
gcloud dns inbound-policies create spoke-inbound \
  --networks=projects/SPOKE_PROJECT/global/networks/spoke-vpc \
  --enable-inbound-forwarding

gcloud dns outbound-policies create spoke-outbound \
  --networks=projects/SPOKE_PROJECT/global/networks/spoke-vpc \
  --outbound-forwarding-servers=129.154.169.252  # Đầu vào (inbound) của Hub

Mô hình lai: Tích hợp với On-Premises (Hybrid On-Premises Integration Pattern)

Kiến trúc: Hub-Spoke kết hợp On-Prem

Trung tâm dữ liệu nội bộ (On-Premises Data Center)
├── DNS Server 192.168.1.10
├── Zone "corp.internal"
└── Các dịch vụ (Services): AD, cơ sở dữ liệu, ứng dụng cũ (legacy apps)

GCP Hub Project
├── Private Zone "gcp.internal.com"
├── Inbound Server 129.154.169.252 (định tuyến GCP → spoke peering)
├── Outbound Forwarding tới 192.168.1.10 (định tuyến GCP → on-prem)
└── Đường truyền Cloud Interconnect/VPN kết nối tới on-prem

GCP Spoke Projects
├── Các VPC thực hiện peering với Hub
├── Có thể phân giải gcp.internal.com (qua hub peering)
├── Có thể phân giải corp.internal (qua hub → kết nối tới on-prem)
└── Sử dụng Shared VPC để kết nối mạng

Thiết lập: Cloud DNS kết hợp với On-Prem DNS

bash

# Hub Project - Tạo forwarding zone cho tên miền (domain) on-prem
gcloud dns managed-zones create onprem-forwarding \
  --dns-name=corp.internal \
  --visibility=private \
  --networks=projects/HUB_PROJECT/global/networks/hub-vpc

gcloud dns managed-zones update onprem-forwarding \
  --inbound-forwarding-servers=192.168.1.10  # Máy chủ DNS của On-prem

# Hub Project - Tạo chính sách inbound policy (cho spoke peering)
gcloud dns inbound-policies create hub-inbound \
  --networks=projects/HUB_PROJECT/global/networks/hub-vpc \
  --enable-inbound-forwarding

# Spoke Project - Tạo chính sách peering (peering policy)
gcloud dns managed-zones create spoke-peered \
  --dns-name=gcp.internal.com \
  --visibility=private \
  --networks=projects/SPOKE_PROJECT/global/networks/spoke-vpc

gcloud dns managed-zones update spoke-peered \
  --inbound-forwarding-servers=129.154.169.252  # Đầu vào (inbound) của Hub

# Spoke Project - Đồng thời cần forward tới on-prem thông qua hub
gcloud dns managed-zones create spoke-onprem \
  --dns-name=corp.internal \
  --visibility=private \
  --networks=projects/SPOKE_PROJECT/global/networks/spoke-vpc

gcloud dns managed-zones update spoke-onprem \
  --inbound-forwarding-servers=129.154.169.252  # Gửi yêu cầu tới hub để forward tiếp tới on-prem

Quy trình phân giải: Đầu-cuối (Resolution Flow: End-to-End)

Tài nguyên Spoke VPC:
  Truy vấn (Query): db.corp.internal

  Bước 1: Trình phân giải của Spoke VPC (Spoke VPC resolver)
  Bước 2: Kiểm tra spoke-onprem zone
  Bước 3: Gửi tới đích đến forwarding: 129.154.169.252 (hub)
  Bước 4: Hub tiếp nhận truy vấn (query)
  Bước 5: Kiểm tra hub-onprem zone  
  Bước 6: Gửi tới đích đến forwarding: 192.168.1.10 (DNS của on-prem)
  Bước 7: DNS của On-prem phản hồi kết quả: 192.168.1.100
  Bước 8: Phản hồi lan truyền ngược lại: spoke ← hub ← tài nguyên spoke
  Bước 9: Kết quả nhận được: 192.168.1.100

Độ trễ (Latency): ~5-10ms cho mỗi chặng (hop) (ở mức chấp nhận được, thông thường dưới 50ms).

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

Mô hình 1: Hub-and-Spoke DNS (Pattern 1)

Dự án trung tâm (Central Hub Project):
├── Quản lý toàn bộ hạ tầng DNS (DNS infrastructure)
├── Các private zone dành cho các dịch vụ dùng chung (shared services)
├── Các điểm cuối nhận yêu cầu peering (inbound peering endpoints)
└── Các quy tắc tường lửa (Firewall rules) cho phép lưu lượng spoke → hub

Các dự án Spoke (dev, staging, prod):
├── Thực hiện Peer với hub đối với các shared zones
├── Duy trì các local private zone riêng cho dịch vụ của từng team
└── Gửi outbound tới hub để truy cập các external zone

Lợi ích mang lại (Benefits):

✓ Quản lý DNS tập trung (Centralized DNS management)
✓ Đặt tên zone nhất quán (Consistent zone naming)
✓ Áp dụng chính sách bảo mật tại một điểm duy nhất (Single point of security policy)
✓ Dễ dàng thêm hoặc bớt các team

Mô hình 2: Di chuyển hệ thống mạng lai dần dần (Pattern 2: Hybrid Gradually Migration)

Giai đoạn 1: Chỉ chạy On-Prem (Phase 1)
├── Toàn bộ dịch vụ chạy trên on-prem
├── Toàn bộ việc phân giải DNS diễn ra trên on-prem
└── Không có sự tích hợp với GCP

Giai đoạn 2: Cloud Bursting (Phase 2)
├── Các dịch vụ mới được triển khai trên GCP
├── Hệ thống DNS của on-prem forward tới GCP DNS
├── Hệ thống GCP DNS forward tới DNS của on-prem
└── Cơ chế phân giải hai chiều hoạt động ổn định

Giai đoạn 3: Đám mây làm chính (Phase 3: Cloud Primary)
├── Hầu hết các dịch vụ được đặt trên GCP
├── GCP DNS đóng vai trò làm máy chủ phân giải chính
├── DNS của on-prem bắt đầu bị hạn chế sử dụng (nhưng vẫn có thể kết nối)

Giai đoạn 4: Chỉ chạy Đám mây (Phase 4: Cloud Only)
├── Toàn bộ dịch vụ đều chạy trên GCP
└── Tắt hoàn toàn DNS của on-prem

Mô hình 3: Đa đám mây (Pattern 3: Multi-Cloud)

GCP
├── Zone gcp.services.internal
├── Inbound server đặt tại địa chỉ 129.154.169.252

AWS
├── Bản ghi Route 53 zone aws.services.internal
├── Cấu hình Conditional forwarder trỏ tới GCP inbound

Kết quả: Phân giải chéo đám mây mượt mà (Seamless cross-cloud resolution)

Khắc phục sự cố (Troubleshooting)

Sự cố 1: Spoke không phân giải được Hub Zone

bash

# From spoke VPC VM:
nslookup service.prod.internal.example.com

# Quá trình gỡ lỗi (Debugging):
1. Kiểm tra xem peering zone đã tồn tại trong spoke project chưa
   gcloud dns managed-zones list --project=spoke-project

2. Kiểm tra đích đến inbound forwarding (forwarding target)
   gcloud dns managed-zones describe peered-zone \
     --project=spoke-project

3. Kiểm tra địa chỉ IP của hub inbound server
   gcloud compute addresses describe inbound-server-ip \
     --region=us-central1 \
     --project=hub-project

4. Kiểm tra kết nối mạng (VPN/Interconnect phải đang hoạt động)
   gcloud compute ssh VM --zone=us-central1-a --tunnel-through-iap
   ping 129.154.169.252  # Kết quả phải hoạt động bình thường

5. Kiểm tra các quy tắc tường lửa (firewall rules)
   gcloud compute firewall-rules list \
     --filter="sourceRanges:spoke-vpc-subnet" \
     --format="table(name,allowed[].IPProtocol,allowed[].ports)"

Sự cố 2: Vòng lặp phân giải (Resolution Loops - Infinite Forwarding)

Kịch bản (Scenario):
  Zone A forward truy vấn tới Server B
  Server B tiếp tục forward ngược lại Zone A
  → Gây ra vòng lặp vô hạn (Infinite loop)

Gỡ lỗi (Debug):
  tcpdump -i eth0 port 53
  → Bạn sẽ thấy truy vấn liên tục nhảy qua lại

Giải pháp:
  Kiểm tra lại các đích đến forwarding
  Đảm bảo cấu hình không tạo vòng lặp: A → B → A

Sự cố 3: On-Prem không thể tiếp cận các dịch vụ GCP

bash

# From on-prem DNS server:
nslookup service.gcp.internal.example.com

# Quá trình gỡ lỗi (Debugging):
1. DNS của On-prem phải được cấu hình để forward các zone không xác định
   Ví dụ về cấu hình BIND (Example BIND config):
   
   zone "gcp.internal.example.com" {
     type forward;
     forward only;
     forwarders { 129.154.169.252; };
   };

2. Kết nối mạng phải cho phép các truy vấn DNS đi qua (cổng 53)
   Các quy tắc tường lửa (firewall rules) trên GCP phải cho phép CIDR của on-prem

3. Xác minh trạng thái của VPN/Interconnect
   gcloud compute interconnects list
   gcloud compute vpn-tunnels list

Các lưu ý về hiệu năng (Performance Considerations)

Độ trễ (Latency)

Phân giải Single-VPC: ~1-2ms (có cache)
Phân giải Peering (1 chặng): ~5-10ms (qua 1 lần forwarding)
Phân giải Hybrid (2 chặng): ~10-20ms (từ hub → on-prem)

Đặc thù: Vẫn nằm trong phạm vi chấp nhận được và đáp ứng thỏa thuận mức dịch vụ (SLA budgets).

Bộ nhớ đệm (Caching)

DNS Peering không làm ảnh hưởng đến cơ chế cache:

Spoke VM thực hiện phân giải service.prod.internal.example.com
  → Hub thực hiện forward → Nhận được câu trả lời
  → Kết quả được lưu bộ nhớ đệm (cached) tại local
  → Các truy vấn tiếp theo sẽ đọc trực tiếp từ cache local (tức thì)

Thời gian sống (TTL) quyết định thời điểm bộ nhớ đệm hết hạn.

Tải lượng truy vấn (Query Load)

Nếu hub là điểm quản lý DNS tập trung cho 100 dự án spoke:
  100 dự án × 1000 truy vấn/giây = 100k QPS gửi tới hub

Rủi ro: Hub có thể trở thành điểm nghẽn cổ chai (bottleneck).

Biện pháp giảm thiểu:
  1. Dịch vụ Cloud DNS có thể xử lý hàng triệu QPS (thông thường không phải là vấn đề lớn)
  2. Sử dụng regional peering nếu có sẵn (không phải mọi vùng đều hỗ trợ)
  3. Cân nhắc tách biệt hub cho mỗi vùng (ví dụ: hub cho us-central1, hub cho eu-west1)

Các lưu ý về bảo mật (Security Considerations)

Kiểm soát truy cập (Access Control)

bash

# Chỉ các dự án spoke cụ thể mới được phép peer với hub
gcloud dns inbound-policies create hub-restricted \
  --networks=projects/HUB/global/networks/hub \
  --enable-inbound-forwarding

# Quyền IAM của Hub zone: Chỉ quản trị viên hub mới được phép chỉnh sửa
gcloud dns managed-zones add-iam-policy-binding hub-prod-zone \
  --member=group:dns-admins@company.com \
  --role=roles/dns.admin

Phòng chống tấn công chiếm đoạt DNS (DNS Hijacking Prevention)

Máy chủ DNS của on-prem có thể bị xâm nhập bảo mật:
  Truy vấn: service.example.com → 192.168.1.10 (on-prem) → trả về IP độc hại

Biện pháp giảm thiểu:
  1. Kích hoạt tính năng xác thực DNSSEC (nếu được hỗ trợ)
  2. Giám sát các truy vấn DNS để phát hiện hành vi bất thường (anomalies)
  3. Sử dụng đường truyền VPN/Interconnect bảo mật (được mã hóa)
  4. Định kỳ kiểm tra (audit) danh sách các bản ghi DNS

Giám sát và Ghi nhật ký (Monitoring & Logging)

bash

# Kích hoạt tính năng ghi nhật ký truy vấn DNS
gcloud dns policies create log-policy \
  --description="Ghi nhật ký tất cả truy vấn" \
  --enable-logging \
  --log-network=projects/HUB/global/networks/hub-vpc

# Xem nhật ký (logs)
gcloud logging read "resource.type=dns_policy" \
  --limit=50 \
  --format=json | jq '.[] | {timestamp: .timestamp, queryName: .payload_proto.query_name}'

# Thiết lập cảnh báo khi có lỗi truy vấn peering xảy ra
# (Cấu hình thông qua Cloud Monitoring)

Danh sách kiểm tra (Checklists)

Trước khi triển khai (Pre-Deployment)

[ ] Sẵn sàng các VPC Hub và Spoke
[ ] Thiết lập VPN/Interconnect giữa hub và on-prem (nếu sử dụng mạng lai)
[ ] Cấu hình các tuyến đường mạng (network routes) giữa các VPC
[ ] Các quy tắc tường lửa (Firewall rules) cho phép lưu lượng DNS đi qua (cổng 53)

Quá trình thực hiện (Implementation)

[ ] Tạo chính sách inbound peering policy trên hub
[ ] Tạo các peering zone trên các dự án spoke
[ ] Tạo các forwarding zone (nếu có kết nối on-prem)
[ ] Kiểm thử kết nối từ spoke → hub → on-prem (đầu-cuối)

Sau khi triển khai (Post-Deployment)

[ ] Kích hoạt tính năng query logging
[ ] Cấu hình các cảnh báo giám sát (monitoring alerts)
[ ] Kiểm thử chuyển vùng sự cố (Failover tested) nếu cần tính sẵn sàng cao
[ ] Cập nhật tài liệu hướng dẫn
[ ] Đào tạo đội ngũ về quy trình xử lý sự cố

DNS Peering: Phân giải Hybrid On-Premises ​

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

Nguyên lý cơ bản của DNS Peering ​

DNS Peering là gì? (What is DNS Peering) ​

So sánh DNS Peering với Forwarding (DNS Peering vs Forwarding) ​

Triển khai: Inbound Peering ​

Kiến trúc ​

Các bước thiết lập ​

Triển khai bằng Terraform (Terraform Implementation) ​

Triển khai: Outbound Peering (Hai chiều - Bidirectional) ​

Thiết lập ​

Mô hình lai: Tích hợp với On-Premises (Hybrid On-Premises Integration Pattern) ​

Kiến trúc: Hub-Spoke kết hợp On-Prem ​

Thiết lập: Cloud DNS kết hợp với On-Prem DNS ​

Quy trình phân giải: Đầu-cuối (Resolution Flow: End-to-End) ​

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

Mô hình 1: Hub-and-Spoke DNS (Pattern 1) ​

Mô hình 2: Di chuyển hệ thống mạng lai dần dần (Pattern 2: Hybrid Gradually Migration) ​

Mô hình 3: Đa đám mây (Pattern 3: Multi-Cloud) ​

Khắc phục sự cố (Troubleshooting) ​

Sự cố 1: Spoke không phân giải được Hub Zone ​

Sự cố 2: Vòng lặp phân giải (Resolution Loops - Infinite Forwarding) ​

Sự cố 3: On-Prem không thể tiếp cận các dịch vụ GCP ​

Các lưu ý về hiệu năng (Performance Considerations) ​

Độ trễ (Latency) ​

Bộ nhớ đệm (Caching) ​

Tải lượng truy vấn (Query Load) ​

Các lưu ý về bảo mật (Security Considerations) ​

Kiểm soát truy cập (Access Control) ​

Phòng chống tấn công chiếm đoạt DNS (DNS Hijacking Prevention) ​

Giám sát và Ghi nhật ký (Monitoring & Logging) ​

Danh sách kiểm tra (Checklists) ​

Trước khi triển khai (Pre-Deployment) ​

Quá trình thực hiện (Implementation) ​

Sau khi triển khai (Post-Deployment) ​

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

DNS Peering: Phân giải Hybrid On-Premises

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

Nguyên lý cơ bản của DNS Peering

DNS Peering là gì? (What is DNS Peering)

So sánh DNS Peering với Forwarding (DNS Peering vs Forwarding)

Triển khai: Inbound Peering

Kiến trúc

Các bước thiết lập

Triển khai bằng Terraform (Terraform Implementation)

Triển khai: Outbound Peering (Hai chiều - Bidirectional)

Thiết lập

Mô hình lai: Tích hợp với On-Premises (Hybrid On-Premises Integration Pattern)

Kiến trúc: Hub-Spoke kết hợp On-Prem

Thiết lập: Cloud DNS kết hợp với On-Prem DNS

Quy trình phân giải: Đầu-cuối (Resolution Flow: End-to-End)

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

Mô hình 1: Hub-and-Spoke DNS (Pattern 1)

Mô hình 2: Di chuyển hệ thống mạng lai dần dần (Pattern 2: Hybrid Gradually Migration)

Mô hình 3: Đa đám mây (Pattern 3: Multi-Cloud)

Khắc phục sự cố (Troubleshooting)

Sự cố 1: Spoke không phân giải được Hub Zone

Sự cố 2: Vòng lặp phân giải (Resolution Loops - Infinite Forwarding)

Sự cố 3: On-Prem không thể tiếp cận các dịch vụ GCP

Các lưu ý về hiệu năng (Performance Considerations)

Độ trễ (Latency)

Bộ nhớ đệm (Caching)

Tải lượng truy vấn (Query Load)

Các lưu ý về bảo mật (Security Considerations)

Kiểm soát truy cập (Access Control)

Phòng chống tấn công chiếm đoạt DNS (DNS Hijacking Prevention)

Giám sát và Ghi nhật ký (Monitoring & Logging)

Danh sách kiểm tra (Checklists)

Trước khi triển khai (Pre-Deployment)

Quá trình thực hiện (Implementation)

Sau khi triển khai (Post-Deployment)

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