admin 08/01/2026

DNS & AD/Domain trong môi trường Dual-WAN/SD-WAN

Fortigate NAMHI | Giai đoạn 3 | Bài 17 (Kết series cơ bản)

🧠 DNS & AD/Domain trong môi trường Dual-WAN/SD-WAN – Split DNS, Forwarder

Trong thực tế triển khai, rất nhiều case “đổ lỗi cho WAN/SD-WAN” nhưng gốc lại là DNS. Kết quả thường thấy: login domain chậm, join domain lỗi, ERP truy cập lúc được lúc không, hoặc truy cập theo FQDN thì “nhảy” ra IP public. Bài này giúp anh dựng mô hình DNS đúng chuẩn doanh nghiệp: client dùng DNS nội bộ (DC) và DNS nội bộ forward ra Internet theo SD-WAN.

⏱️ 45–70 phút 🎯 Level: Cơ bản → Trung cấp 🧰 Dành cho: IT triển khai / IT hệ thống

⬅️ Bài 16: Publish đa WAN (VIP/DNAT) ✅ Tổng kết series cơ bản

🧭 DNS đúng trong doanh nghiệp: 1 câu nhớ cả đời

Trong môi trường Active Directory, DNS là xương sống. Nếu client trỏ DNS public (8.8.8.8/1.1.1.1) thay vì DNS nội bộ, bạn sẽ gặp đủ lỗi “khó hiểu”.

⚠️ Quy tắc NAMHI: Client nội bộ phải trỏ DNS về Domain Controller (DNS nội bộ). DNS public chỉ là upstream/forwarder, không phải DNS chính cho client AD.

🎯 Dấu hiệu nhận biết “lỗi DNS đội lốt lỗi WAN”

🧑‍💻 Domain

Login/Join domain chậm

Đổi WAN hoặc giờ cao điểm là user login cực lâu, Group Policy apply chập chờn.

Nguyên nhân thường là resolve DC/DNS sai hoặc forwarder timeout.

🏢 ERP/Apps

ERP lúc vào được lúc không

Vào bằng IP thì ok, nhưng vào bằng tên (FQDN) thì lỗi hoặc vòng ra Internet.

Gặp nhiều khi ERP dùng cùng domain với public.

🌍 Internet

“Mạng có nhưng app không chạy”

Ping IP public ok, nhưng truy cập dịch vụ theo tên lại lỗi.

Vấn đề nằm ở DNS/resolve, không phải đường truyền.

1️⃣ Mô hình DNS chuẩn trong Dual-WAN/SD-WAN (NAMHI khuyến nghị)

✅ Mô hình chuẩn

Client → DNS: DC1, DC2
DC → Forward Internet DNS (qua FortiGate/SD-WAN)
FortiGate quyết định đường ra Internet, nhưng không thay DNS AD

❌ Mô hình hay gây lỗi

Client trỏ DNS public trực tiếp
Client dùng “DC + public” (lúc resolve theo DC, lúc theo public)
FQDN nội bộ bị resolve ra IP public

💡 Nếu bắt buộc “2 DNS” trên client: hãy dùng DC1 + DC2. Đừng mix DC với DNS public.

2️⃣ Cấp DNS cho client: chốt tại DHCP để khỏi “trôi cấu hình”

Thực chiến NAMHI: muốn hệ thống ổn định thì đừng cấu hình DNS thủ công từng máy. Hãy chốt DNS ở DHCP (FortiGate hoặc Windows DHCP) và đảm bảo DNS cấp xuống là DC.

✅ Nếu FortiGate làm DHCP

DHCP option DNS servers: DC1, DC2
Default gateway: FortiGate (VLAN interface)
Không đẩy DNS public xuống client

✅ Nếu Windows DHCP

Scope option DNS: DC1, DC2
Kiểm tra không có option “thừa” trỏ DNS public

⚠️ “2 DNS: DC + public” là nguyên nhân phổ biến nhất gây lỗi resolve ngẫu nhiên (lúc đúng lúc sai).

3️⃣ DNS Forwarding: để DC “ra Internet” đúng cách khi có SD-WAN

DC cần resolve tên Internet (Microsoft/Teams/CRM/SaaS). Cách đúng: DC forward query Internet ra upstream. Khi có SD-WAN, FortiGate sẽ chọn WAN tối ưu, nên forward theo hướng “ra FortiGate” là rất hợp lý.

Bước 1

DC dùng forwarder (khuyến nghị)

Forwarder chính: FortiGate (IP gateway nội bộ) hoặc DNS resolver nội bộ theo thiết kế
Giữ resolver cho domain nội bộ tại DC

💡 Tư duy: DC giải quyết domain nội bộ; phần Internet thì forward ra ngoài theo SD-WAN.

Bước 2

Nếu FortiGate cần resolve FQDN objects

FortiGate có thể cần DNS cho ISDB/FQDN objects. Đảm bảo DNS FortiGate hoạt động ổn định (tuỳ mô hình có thể trỏ về DC hoặc upstream tin cậy).

⚠️ Đừng nhầm: DNS của FortiGate (thiết bị) không đồng nghĩa với DNS mà client phải dùng trong AD.

4️⃣ Split DNS: xử lý FQDN nội bộ không bị resolve ra IP public

Case kinh điển: ERP dùng tên như erp.company.com. Nếu client resolve ra IP public, truy cập sẽ vòng ra Internet hoặc gặp policy khác, gây lỗi hoặc chậm.

Cách 1

Giải đúng nơi: DNS nội bộ (NAMHI khuyến nghị)

Tạo record nội bộ (A/AAAA/CNAME) trỏ về IP LAN của ERP
Client dùng DNS DC nên sẽ resolve “đúng”
Không phụ thuộc WAN, không phụ thuộc SD-WAN

Cách 2

Trường hợp đặc biệt

Nếu ERP nằm ngoài site hoặc hybrid cloud, có thể cần conditional forwarder hoặc thiết kế DNS riêng. Khi gặp case này, NAMHI khuyến nghị tách thành bài nâng cao để tránh cấu hình “gãy”.

💡 Mục tiêu Split DNS: cùng 1 FQDN, nội bộ đi IP nội bộ, bên ngoài đi IP public.

🔍 Test đúng chuẩn: đổi WAN nhưng domain/ERP vẫn ổn

Test 1

Resolve ERP theo tên

Client resolve FQDN ERP phải ra IP nội bộ (không nhảy ra public).

Test 2

Failover WAN

Ngắt WAN1 → WAN2: login domain và truy cập ERP vẫn ổn. (Đổi đường Internet, không đổi logic DNS nội bộ).

Test 3

Giờ cao điểm

Test giờ nhiều user: DNS vẫn phản hồi ổn định, không timeout, không “lụi” do forwarder yếu.

❌ Lỗi thường gặp & cách xử lý nhanh (accordion)

❌ Login domain chậm sau khi bật SD-WAN

Client trỏ DNS public
Client dùng “DC + public”
DC forwarder timeout hoặc upstream không ổn định

❌ ERP truy cập lúc được lúc không

FQDN ERP resolve ra IP public (thiếu record nội bộ)
DNS cache trên client chưa refresh (cần flush/test)
Client nhận DNS sai từ DHCP (option bị cấu hình nhầm)

❌ Ping IP được nhưng truy cập theo tên (FQDN) lỗi

Nếu ping IP nội bộ ok mà truy cập theo tên lỗi, gần như chắc chắn là vấn đề DNS/resolve. Kiểm tra DNS client và record nội bộ trước khi “blame” WAN.

🧩 Kết luận

Trong hệ thống có AD, cách đúng và bền nhất là: Client trỏ DNS về DC và DC forward ra Internet. Dual-WAN/SD-WAN chỉ thay “đường ra Internet”, không được làm thay đổi logic DNS nội bộ.

✅ Tổng kết

🎉 Kết thúc series Fortigate NAMHI – cơ bản

Đến đây, anh đã có bộ nền tảng đủ triển khai cho đa số doanh nghiệp: bảo mật cơ bản, VPN, SD-WAN, publish đa WAN và DNS/AD. Các chủ đề nâng cao có thể tách bài riêng để đăng sau khi cần.

Xem lại bài trước: Bài 16: Publish đa WAN (VIP/DNAT)

Về trang Series

DNS & AD/Domain trong môi trường Dual-WAN/SD-WAN

🧠 DNS & AD/Domain trong môi trường Dual-WAN/SD-WAN – Split DNS, Forwarder

🧭 DNS đúng trong doanh nghiệp: 1 câu nhớ cả đời