My Awesome Project

Appearance

DNS Forwarding: Cấu hình Upstream Resolvers ​

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

DNS forwarding đóng vai trò làm lớp keo kết nối (glue layer) giữa Cloud DNS và các máy chủ DNS bên ngoài (external nameservers như on-premises DNS, ISP resolvers, các dịch vụ DNS bên thứ ba).

Các kịch bản thực tế (Real-world scenarios):

Kịch bản 1: Tích hợp với On-Premises (Scenario 1)
├── Máy chủ BIND của on-prem sở hữu zone corp.internal
├── Cloud DNS chưa biết thông tin về corp.internal
└── Giải pháp (Solution): Sử dụng Forwarding zone → gửi truy vấn tới BIND của on-prem

Kịch bản 2: Di chuyển hệ thống cũ (Scenario 2: Legacy System Migration)
├── Máy chủ DNS cũ (Infoblox) chạy trên địa chỉ 192.168.1.10
├── Hệ thống Cloud DNS mới chỉ phục vụ bên ngoài (external)
└── Trong quá trình di chuyển (migration): Tạo Forwarding zone trỏ về hệ thống cũ (legacy)

Kịch bản 3: Dự phòng DNS nhà mạng (Scenario 3: ISP DNS Failover)
├── Mặc định (Default): Sử dụng 8.8.8.8 (Dịch vụ DNS miễn phí của Google)
├── Nhu cầu (Need): Cấu hình upstream đặc thù cho công ty (corporate proxy)
└── Giải pháp (Solution): Sử dụng Forwarding zone → trỏ tới corporate resolver

Kịch bản 4: Định tuyến có điều kiện (Scenario 4: Conditional Routing)
├── Các truy vấn (Queries) cho *.internal → chuyển tiếp (forward) tới on-prem
├── Các truy vấn (Queries) cho *.example.com → sử dụng public DNS
└── Áp dụng các quy tắc định tuyến (routing rules) khác nhau cho mỗi domain

Hệ quả khi triển khai sai cách (Impact of wrong implementation):

  • Hết thời gian chờ DNS (DNS timeouts) do không kết nối được đích đến forwarding
  • Vòng lặp vô hạn (Infinite loops) do chuyển tiếp ngược lại chính nó
  • Làm giảm hiệu năng (Performance degradation) do phải qua các chặng trung gian không cần thiết
  • Vi phạm các quy định tuân thủ (Compliance breaches) do không ghi nhận lịch sử truy vấn

Nguyên lý cơ bản của Forwarding Zone ​

Khái niệm (Concept) ​

Forwarding zone chính là cơ chế chuyển hướng truy vấn có điều kiện (conditional query redirection).

Quá trình phân giải thông thường (Normal Resolution):
  Query: unknown.domain.com
  └── Cloud DNS kiểm tra các local zone
      → Không tìm thấy bản ghi
      → Forward tới hệ thống public DNS mặc định
      → Trả về kết quả

Mô hình Forwarding Zone:
  Query: corp.internal (matched by forwarding zone)
  └── Cloud DNS kiểm tra cấu hình của forwarding zone
      → Khớp mẫu tìm kiếm!
      → Chuyển tiếp (Forwards) truy vấn tới upstream cụ thể (192.168.1.10)
      → Trả về kết quả

  Query: api.example.com (not matched)
  └── Cloud DNS sẽ xử lý theo quy trình thông thường

Các loại chuyển tiếp (Types of Forwarding) ​

Loại (Type)Đích đến (Target)Trường hợp sử dụng (Use Case)Ví dụ (Example)
Internal ForwardingDNS của On-premMô hình mạng lai (Hybrid cloud)corp.internal → 192.168.1.10
External ForwardingPublic DNSĐịnh tuyến có điều kiện (Conditional routing)private.service → 10.0.1.100
Chained ForwardingGắn với zone GCP khácĐa dự án (Multi-project)zone-a → trỏ peering tới zone-b

Triển khai: Internal Forwarding (On-Prem) ​

Kiến trúc (Architecture) ​

Cloud DNS (máy chủ phân giải mặc định - default resolver):
├── Cấu hình Zone corp.internal (đóng vai trò forwarding zone)
├── Đích đến (Target): 192.168.1.10 (BIND trên on-prem)
└── Áp dụng đối với: các truy vấn trong VPC (VPC queries)

Tài nguyên trong VPC (10.0.1.5):
  Truy vấn (Query): server.corp.internal
    ↓
  Trình phân giải VPC (VPC Resolver - 169.254.169.254)
    ↓
  Kiểm tra các local zone → khớp với forwarding zone "corp.internal"
    ↓
  Chuyển tiếp (Forward) tới địa chỉ 192.168.1.10
    ↓
  BIND của on-prem phản hồi kết quả: 192.168.1.100
    ↓
  Kết quả nhận được: 192.168.1.100

Thiết lập bằng lệnh GCP (Setup: GCP Command) ​

bash
# Tạo forwarding zone
gcloud dns managed-zones create onprem-corp \
  --dns-name=corp.internal \
  --visibility=private \
  --networks=projects/PROJECT_ID/global/networks/default

# Thêm đích đến chuyển tiếp (forwarding target)
gcloud dns managed-zones update onprem-corp \
  --inbound-forwarding-servers=192.168.1.10

# Tùy chọn: Thêm máy chủ phụ để đảm bảo tính sẵn sàng cao (HA)
gcloud dns managed-zones update onprem-corp \
  --inbound-forwarding-servers=192.168.1.10,192.168.1.11,192.168.1.12

Thiết lập bằng Terraform (Setup: Terraform) ​

hcl
resource "google_dns_managed_zone" "onprem_corp" {
  name        = "onprem-corp-zone"
  dns_name    = "corp.internal."
  description = "Forwarding to on-premises BIND"
  visibility  = "private"
  
  private_visibility_config {
    networks_list {
      network_url = google_compute_network.default.id
    }
  }
  
  # Forwarding configuration
  forwarding_config {
    target_nameservers {
      ipv4_address = "192.168.1.10"
    }
    target_nameservers {
      ipv4_address = "192.168.1.11"
    }
  }
}

# Đảm bảo khả năng kết nối mạng
resource "google_compute_firewall" "allow_dns_to_onprem" {
  name      = "allow-dns-to-onprem"
  network   = google_compute_network.default.id
  direction = "EGRESS"
  
  allow {
    protocol = "udp"
    ports    = ["53"]
  }
  
  destination_ranges = ["192.168.1.0/24"]
}

Logic xử lý lỗi và Thử lại (Failover & Retry Logic) ​

Dịch vụ Cloud DNS của GCP sẽ tự động xử lý khi máy chủ forwarder gặp sự cố (failover):

Máy chủ chính (Primary): 192.168.1.10 (BIND 1 trên on-prem)
Máy chủ phụ (Secondary): 192.168.1.11 (BIND 2 trên on-prem)

Truy vấn (Query): server.corp.internal

Bước 1: Gửi thử tới máy chủ chính (192.168.1.10)
  → Bị hết thời gian chờ hoặc không thể kết nối
  
Bước 2: Thử lại (Retry): Gửi tới máy chủ phụ (192.168.1.11)
  → Thành công → Lưu kết quả vào bộ nhớ đệm (Response cached)
  
Bước 3: Các truy vấn tiếp theo sẽ sử dụng máy chủ phụ (đồng thời thử lại máy chủ chính theo cơ chế giảm dần exponential backoff)

Cơ chế tự động chuyển vùng (Automatic failover) = Không cần can thiệp thủ công.

Các mô hình chuyển tiếp nâng cao (Advanced Forwarding Patterns) ​

Mô hình 1: Định tuyến có điều kiện (Pattern 1) ​

Thực hiện chuyển tiếp các domain khác nhau tới các upstream khác nhau:

bash
# Zone của On-prem → trỏ về DNS của on-prem
gcloud dns managed-zones create onprem-forward \
  --dns-name=corp.internal \
  --visibility=private \
  --networks=projects/PROJECT_ID/global/networks/default

gcloud dns managed-zones update onprem-forward \
  --inbound-forwarding-servers=192.168.1.10

# Nhà cung cấp bên ngoài → trỏ về DNS bên ngoài
gcloud dns managed-zones create provider-forward \
  --dns-name=external.provider.com \
  --visibility=private \
  --networks=projects/PROJECT_ID/global/networks/default

gcloud dns managed-zones update provider-forward \
  --inbound-forwarding-servers=8.8.8.8

Kết quả (Result):

Truy vấn (Query): server.corp.internal → trỏ tới 192.168.1.10 (on-prem)
Truy vấn (Query): api.external.provider.com → trỏ tới 8.8.8.8 (external)
Truy vấn (Query): service.example.com → trỏ về public DNS mặc định

Mô hình 2: Chuyển tiếp dạng chuỗi nhiều chặng (Pattern 2: Chained Forwarding - Multi-Hop) ​

Máy chủ A forward tới B, sau đó B tiếp tục forward tới C:

Cloud DNS (GCP):
  Zone corp.internal → Forward tới địa chỉ 192.168.1.10

On-Prem BIND (192.168.1.10):
  Zone corp.internal
  Zone legacy.corp → Forward tới địa chỉ 192.168.1.20

Firewall (192.168.1.20):
  Zone legacy.corp

Đường truyền truy vấn (Query Path):

Truy vấn gửi tới Cloud DNS: server.legacy.corp
  → Forward tới 192.168.1.10 (BIND trên on-prem)
  → BIND tiếp nhận truy vấn: server.legacy.corp
  → BIND khớp với Zone legacy.corp → Tiếp tục forward tới 192.168.1.20
  → Firewall phản hồi kết quả: 192.168.1.200
  → Kết quả phản hồi truyền ngược lại theo chuỗi
  
Tổng số chặng (Total hops): 3
Tổng độ trễ (Total latency): ~20-30ms (mức chấp nhận được)

Khuyến nghị: Hãy giới hạn tối đa chỉ từ 2-3 chặng (để tránh lỗi dây chuyền cascading failures).

Mô hình 3: Cân bằng tải giữa các Forwarders (Pattern 3) ​

Sử dụng nhiều forwarders, GCP sẽ tự động cân bằng tải (load-balances):

bash
gcloud dns managed-zones create balanced-forward \
  --dns-name=distributed.internal \
  --visibility=private \
  --networks=projects/PROJECT_ID/global/networks/default

gcloud dns managed-zones update balanced-forward \
  --inbound-forwarding-servers=192.168.1.10,192.168.1.11,192.168.1.12

GCP phân phối các truy vấn (queries):

Tổng 100 truy vấn (queries)
  → 33 truy vấn gửi tới 192.168.1.10
  → 33 truy vấn gửi tới 192.168.1.11
  → 34 truy vấn gửi tới 192.168.1.12

Lợi ích: Tải lượng được phân bổ đều, tránh việc một DNS server duy nhất trở thành điểm nghẽn (bottleneck).

Tích hợp đồng thời Peering và Forwarding ​

Hub-Spoke + On-Prem ​

Hub VPC:
├── Zone corp.internal (forwarding) → trỏ tới 192.168.1.10 (on-prem)
└── Zone gcp.services (local)

Spoke VPC:
├── Truy vấn corp.internal
  → Khớp với cấu hình forwarding zone
  → Forward tới hub (thông qua peering)
  → Hub tiếp tục forward tới on-prem
  → Câu trả lời được trả ngược lại cho spoke
  
Kết quả: Spoke có thể phân giải thành công các domain của on-prem thông qua hub.

Mã Terraform: Cấu hình hoàn chỉnh Hub-Spoke và On-Prem ​

hcl
# Hub Project
resource "google_dns_managed_zone" "hub_onprem" {
  project  = "hub-project"
  name     = "hub-onprem"
  dns_name = "corp.internal."
  
  private_visibility_config {
    networks_list {
      network_url = google_compute_network.hub_vpc.id
    }
  }
  
  forwarding_config {
    target_nameservers {
      ipv4_address = "192.168.1.10"
    }
  }
}

resource "google_dns_inbound_forwarding_policy" "hub" {
  project = "hub-project"
  name    = "hub-inbound"
  
  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_onprem_peered" {
  project  = "spoke-project"
  name     = "spoke-onprem-peered"
  dns_name = "corp.internal."
  
  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"
    }
  }
}

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

Sự cố 1: Hết thời gian chờ (Timeout) khi phân giải Forwarded Domain ​

bash
# From GCP VM:
nslookup server.corp.internal
# Kết quả: hết thời gian chờ (timeout)

# Các bước gỡ lỗi (Debug):
1. Kiểm tra xem forwarding zone đã được tạo chưa
   gcloud dns managed-zones describe onprem-corp

2. Kiểm tra xem IP của forwarder có thể kết nối được không
   gcloud compute ssh VM --zone=us-central1-a --tunnel-through-iap
   nc -zv 192.168.1.10 53  # Kết quả phải thành công

3. Kiểm tra xem tường lửa có cho phép gửi DNS ra ngoài (outbound DNS)
   gcloud compute firewall-rules list --filter="direction:EGRESS"

4. Xác minh xem máy chủ DNS của on-prem có đang lắng nghe không
   On-prem console: netstat -an | grep 53
   Kết quả phải hiển thị trạng thái lắng nghe: 0.0.0.0:53 LISTEN

5. Thực hiện kiểm tra trực tiếp từ VM
   dig @192.168.1.10 server.corp.internal

Sự cố 2: Vòng lặp vô hạn (Infinite Loop - Forwarder trỏ ngược lại) ​

Cấu hình (SAI - WRONG):
  Cloud DNS: corp.internal → forward tới địa chỉ 192.168.1.10
  DNS của on-prem (192.168.1.10): corp.internal → forward ngược về Cloud DNS
  
Hệ quả:
  Truy vấn liên tục lặp vòng giữa Cloud DNS và on-prem

Gỡ lỗi (Debug):
  tcpdump -i eth0 -nn 'udp port 53'
  Bạn sẽ thấy các truy vấn đi qua đi lại liên tục không ngừng
  
Giải pháp:
  Thay đổi đích đến forwarding HOẶC thay đổi cấu hình phía on-prem
  Đảm bảo: Forwarder không được phép trỏ ngược lại chính nó

Sự cố 3: Máy chủ Forwarder bị sập, các truy vấn bị treo ​

Cấu hình:
  corp.internal → forward tới 192.168.1.10 (đây là đích đến duy nhất)
  
Nếu máy chủ 192.168.1.10 bị sập:
  → Toàn bộ truy vấn gửi tới corp.internal sẽ bị hết thời gian chờ (timeout)
  → Các ứng dụng sẽ bị treo do phải đợi phản hồi DNS
  
Giải pháp:
  1. Thêm nhiều forwarders dự phòng
     gcloud dns managed-zones update onprem-corp \
       --inbound-forwarding-servers=192.168.1.10,192.168.1.11
  
  2. Giám sát tình trạng sức khỏe (health) của forwarder
     Thiết lập các kịch bản kiểm tra sức khỏe và gửi cảnh báo (alerting)
  
  3. Chuyển vùng sang trình phân giải thay thế khác
     Nếu tất cả forwarder đều bị sập, hệ thống nên chuyển hướng về public DNS mặc định

Hiệu năng và Khả năng mở rộng (Performance & Scalability) ​

Ảnh hưởng đến độ trễ (Latency Impact) ​

Phân giải tại Local zone (không chuyển tiếp): ~2ms
Phân giải qua Forwarded zone (ở khoảng cách gần): ~5-10ms
Phân giải qua Forwarded zone (ở khoảng cách xa): ~20-50ms
Phân giải dạng Chained forwarding (qua 2-3 chặng): ~50-100ms

Quy tắc kinh nghiệm (Rule of thumb): Nếu độ trễ của forwarder vượt quá 100ms, hãy cân nhắc sử dụng local caching hoặc sao chép zone (zone replication).

Giới hạn tốc độ truy vấn (Query Rate Limits) ​

Nếu có tới 10,000 truy vấn/giây được forward tới BIND của on-prem:
  → Hệ thống BIND có thể bị quá tải (overwhelmed)
  
Các chiến lược mở rộng (Scaling strategies):
  1. Sử dụng nhiều forwarders dự phòng để cân bằng tải
  2. Sử dụng bộ nhớ đệm nội bộ (local caching) để giảm tải cho upstream
  3. Nâng cấp cấu hình phần cứng của forwarder
  4. Cân nhắc cấu hình sao chép zone thay vì sử dụng forwarding

Cơ chế hoạt động của Cache (Cache Behavior) ​

Query: server.corp.internal (TTL=300)

Truy vấn đầu tiên (First query):
  Cloud DNS → forward tới on-prem → lưu kết quả vào cache (trong 300 giây)

Các truy vấn tiếp theo (trong vòng 300 giây):
  Cloud DNS → trả về ngay kết quả từ bộ nhớ đệm (không cần forward nữa)

Sau 300 giây:
  Bộ nhớ đệm hết hạn → thực hiện forward lại

Hệ quả (Implication): Ảnh hưởng của việc forwarding chỉ xảy ra một lần cho mỗi bản ghi duy nhất trong mỗi chu kỳ TTL, chứ không phải xảy ra trên mọi truy vấn.

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

DNSSEC kết hợp với Forwarding ​

Nếu forwarding zone có sử dụng mã hóa bảo mật DNSSEC:
  Quá trình xác thực DNSSEC cần được thực hiện tại máy chủ forwarder (ở phía on-prem)
  Cloud DNS chỉ đóng vai trò chuyển tiếp trung gian các bản ghi DNSSEC
  
Nếu forwarding zone không được cấu hình sử dụng DNSSEC:
  Rủi ro: Máy chủ forwarder có thể bị chiếm quyền điều khiển (hijacked)
  
Khuyến nghị:
  ✓ Sử dụng kết nối bảo mật VPN/Interconnect (kênh truyền dữ liệu được mã hóa)
  ✓ Tiến hành xác thực chứng chỉ TLS của forwarder (nếu sử dụng HTTPS DNS)

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

bash
# Ai có quyền chỉnh sửa cấu hình các forwarding zone?
gcloud dns managed-zones add-iam-policy-binding onprem-corp \
  --member=group:dns-admins@company.com \
  --role=roles/dns.admin

# Hạn chế quyền truy cập cho một team cụ thể
gcloud dns managed-zones add-iam-policy-binding onprem-corp \
  --member=serviceAccount:automation@project.iam.gserviceaccount.com \
  --role=roles/dns.recordAdmin

Giám sát các truy vấn được chuyển tiếp (Monitoring Forwarded Queries) ​

bash
# Kích hoạt ghi nhật ký (logging)
gcloud dns policies create forward-log \
  --description="Ghi nhật ký các truy vấn" \
  --enable-logging \
  --log-network=projects/PROJECT/global/networks/default

# Xem nhật ký (logs)
gcloud logging read 'resource.type=dns_forward' --limit=50

Các thực hành tốt nhất (Best Practices) ​

  1. Luôn bổ sung các máy chủ forwarders phụ để đảm bảo tính sẵn sàng cao (HA)
  2. Kiểm thử kết nối mạng kỹ lưỡng trước khi đưa vào vận hành production
  3. Giám sát liên tục trạng thái sức khỏe của máy chủ forwarder
  4. Giới hạn số lượng chặng chuyển tiếp (tối đa là 3 chặng)
  5. Sử dụng kết nối bảo mật VPN/Interconnect khi thực hiện chuyển tiếp
  6. Viết tài liệu lưu vết các đích đến forwarder (team nào đang quản lý DNS on-prem?)
  7. Thiết lập cơ chế gửi cảnh báo ngay khi forwarder không thể kết nối
  8. Lên kịch bản dự phòng lỗi (phương án xử lý là gì nếu on-prem bị sập?)

Các thiết kế phản mẫu cần tránh (Anti-Patterns) ​

❌ Chỉ sử dụng một forwarder duy nhất (không có cơ chế dự phòng HA) ❌ Chuyển tiếp vòng lặp (Circular forwarding: A→B→A) ❌ Sử dụng quá nhiều chặng trung gian (gây suy giảm hiệu năng nghiêm trọng) ❌ Không thiết lập hệ thống giám sát (tạo điểm mù khi xảy ra sự cố) ❌ Truyền tiếp không mã hóa (tiềm ẩn rủi ro bảo mật thông tin) ❌ Không tối ưu hóa thời gian sống TTL (làm giảm hiệu năng cache)

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