Khắc phục sự cố 14 phút đọc

Khắc phục sự cố DNS và DHCP trên Windows Server cho IT Helpdesk

Hướng dẫn thực tế cho IT Helpdesk về cách chẩn đoán và sửa lỗi DNS, DHCP trên Windows Server 2022/2025. Bao gồm quy trình xử lý lỗi DNS không phản hồi, DHCP scope cạn kiệt, cấu hình failover và các lệnh PowerShell sẵn dùng.

Editorial Team

Tại sao IT Helpdesk cần nắm vững DNS và DHCP?

Nếu bạn đang làm IT Helpdesk, chắc hẳn bạn đã từng nghe câu kinh điển: "Mạng không vào được anh/chị ơi!" Và thực tế thì — phần lớn thời gian, thủ phạm nằm ở DNS hoặc DHCP.

DNS (Domain Name System) chuyển đổi tên miền thành địa chỉ IP, còn DHCP (Dynamic Host Configuration Protocol) tự động cấp phát IP và thông số mạng cho thiết bị. Hai dịch vụ này nghe có vẻ đơn giản, nhưng theo nghiên cứu từ Enterprise Management Associates, cấu hình DNS và DHCP sai là nguyên nhân của khoảng 40% các sự cố ngắt mạng trong doanh nghiệp. Con số đó không hề nhỏ.

Bài viết này sẽ đi thẳng vào quy trình chẩn đoán và xử lý có hệ thống trên Windows Server 2022/2025 — từ những bước cơ bản nhất đến các tình huống phức tạp hơn. Mình đã tổng hợp lại từ kinh nghiệm thực tế xử lý sự cố, nên hy vọng sẽ hữu ích cho bạn.

Phần 1: Khắc phục sự cố DNS

1.1. Nhận biết lỗi DNS — nhìn vào đâu trước?

Trước khi mò mẫm, hãy xác định xem có thật sự là lỗi DNS không đã. Dưới đây là các triệu chứng điển hình:

  • Người dùng không truy cập được website nhưng vẫn ping được địa chỉ IP — dấu hiệu rõ ràng nhất của lỗi phân giải tên miền
  • Lỗi "DNS server isn't responding" khi chạy trình khắc phục sự cố mạng trên Windows
  • Ứng dụng nội bộ không kết nối được — đặc biệt khi dùng FQDN thay vì IP trực tiếp
  • Lỗi đăng nhập Active Directory — domain controller phụ thuộc vào bản ghi SRV trong DNS để quảng bá dịch vụ Kerberos KDC và LDAP, nên mất DNS là mất cả AD

1.2. Quy trình chẩn đoán DNS từng bước

Bước 1: Kiểm tra cấu hình DNS trên máy client

Đây là bước đầu tiên và cũng đơn giản nhất. Mở Command Prompt với quyền Administrator:

ipconfig /all

Nhìn vào phần DNS Servers — đảm bảo địa chỉ DNS trỏ đúng về domain controller hoặc DNS server nội bộ. Nếu thấy 127.0.0.1 hoặc một IP lạ không phải DNS server nội bộ, bạn đã tìm ra vấn đề rồi đấy.

Bước 2: Kiểm tra phân giải tên bằng nslookup

nslookup google.com
nslookup tenserver.domain.local
nslookup -type=SRV _ldap._tcp.dc._msdcs.domain.local

Lệnh đầu kiểm tra phân giải bên ngoài, lệnh thứ hai kiểm tra nội bộ, lệnh thứ ba kiểm tra bản ghi SRV của Active Directory. Kết quả trả về sẽ cho bạn biết vấn đề nằm ở đâu:

  • SERVFAIL — DNS server phản hồi nhưng có lỗi upstream (kiểm tra forwarders)
  • Timeout — không kết nối được đến DNS server, đây là vấn đề mạng chứ không phải DNS thuần túy

Bước 3: Xóa cache DNS và đăng ký lại

ipconfig /flushdns
ipconfig /registerdns

Bạn sẽ ngạc nhiên khi biết bao nhiêu lần lệnh đơn giản này giải quyết được vấn đề. Cache DNS lỗi thời có thể trỏ thiết bị đến IP cũ hoặc không còn tồn tại. Nếu flush xong mà chạy ngon, thì chỉ là cache cũ thôi — không cần lo lắng gì thêm.

Bước 4: Thử DNS server khác để cô lập vấn đề

Nếu DNS nội bộ không phản hồi, thử tạm chuyển sang DNS công cộng để xem vấn đề nằm ở đâu:

nslookup google.com 8.8.8.8
nslookup google.com 1.1.1.1

DNS công cộng chạy được mà nội bộ thì không? Vấn đề ở DNS server nội bộ. Cả hai đều lỗi? Kiểm tra kết nối mạng và firewall — đặc biệt port 53 UDP/TCP.

Bước 5: Kiểm tra DNS server trên Windows Server

Lên thẳng DNS server, mở DNS Manager và kiểm tra lần lượt:

  • Dịch vụ DNS có đang chạy không — vào Services.msc hoặc chạy Get-Service DNS trong PowerShell
  • Forward và Reverse Lookup Zones đã cấu hình đúng chưa
  • DNS Forwarders hoạt động — kiểm tra tab Forwarders trong Properties
  • Event Viewer → Applications and Services Logs → DNS Server — tìm Event ID 4010 (lỗi tích hợp AD) và Event ID 4000 (lỗi dịch vụ)

1.3. Xử lý lỗi "Unknown DNS Server"

Cái lỗi này hay gặp lắm. Khi chạy nslookup mà thấy "DNS server: unknown", nguyên nhân thường là thiếu bản ghi PTR (Pointer Record) cho DNS server. Cách khắc phục khá đơn giản:

  1. Mở DNS Manager trên DNS server
  2. Nhấp chuột phải vào Reverse Lookup Zones → New Zone → nhập Network ID
  3. Nhấp chuột phải vào zone vừa tạo → New Pointer (PTR)
  4. Tạo PTR record trỏ IP của DNS server về tên FQDN của nó

Xong. Lỗi "unknown" sẽ biến mất.

Phần 2: Khắc phục sự cố DHCP

2.1. Dấu hiệu nhận biết lỗi DHCP

Dấu hiệu rõ ràng nhất: thiết bị nhận được địa chỉ IP bắt đầu bằng 169.254.x.x. Đây là địa chỉ APIPA (Automatic Private IP Addressing) — khi DHCP server không phản hồi, Windows tự gán một IP tạm, và thiết bị chỉ giao tiếp được với các máy cũng có APIPA trên cùng subnet. Nói cách khác, nó gần như bị cô lập.

Nguyên nhân phổ biến:

  • DHCP server ngừng hoạt động hoặc dịch vụ bị dừng
  • DHCP scope đã hết IP khả dụng (scope exhaustion) — thường gặp ở mạng có nhiều thiết bị
  • Kết nối mạng đến DHCP server bị gián đoạn
  • DHCP relay agent (IP Helper) cấu hình sai trên router/switch
  • Lọc MAC address được bật mà thiết bị mới chưa nằm trong danh sách cho phép

2.2. Quy trình chẩn đoán DHCP từng bước

Bước 1: Kiểm tra trạng thái IP trên client

ipconfig /all

Xác nhận máy client đang dùng DHCP (DHCP Enabled: Yes). Nếu thấy 169.254.x.x, thử renew ngay:

ipconfig /release
ipconfig /renew

Lệnh renew trả về "Unable to contact your DHCP server"? Vấn đề nằm ở phía server hoặc đường truyền mạng — tiếp tục điều tra.

Bước 2: Kiểm tra dịch vụ DHCP Server

Lên Windows Server, kiểm tra dịch vụ DHCP:

Get-Service DHCPServer

# Hoặc dùng Command Prompt:
net start | findstr /i "DHCP"

Dịch vụ đã dừng? Khởi động lại:

Restart-Service DHCPServer

Bước 3: Kiểm tra DHCP scope và số IP còn lại

Mở DHCP Management Console (dhcpmgmt.msc) và kiểm tra:

  • Scope đã Activate chưa — nhấp chuột phải vào Scope để xác nhận
  • Address Pool — xem phạm vi IP và exclusion range
  • Address Leases — so sánh số lease đang hoạt động với tổng IP trong scope. Bằng nhau? Scope đã cạn kiệt rồi
  • Scope Options — Default Gateway (option 003), DNS Servers (option 006) phải đúng

Bước 4: Xử lý DHCP Scope cạn kiệt

Đây là tình huống mình gặp khá thường xuyên, nhất là ở các mạng văn phòng có nhiều thiết bị cá nhân kết nối Wi-Fi. Khi scope hết IP, thiết bị mới không nhận được địa chỉ. Giải pháp theo thứ tự ưu tiên:

  1. Xóa các lease cũ — vào Address Leases, tìm và xóa lease của thiết bị đã ngắt kết nối từ lâu
  2. Mở rộng phạm vi IP — tăng End IP Address trong Scope Properties (nhớ không trùng với subnet khác)
  3. Giảm Lease Duration — mặc định 8 ngày, giảm xuống 1-2 ngày cho mạng có nhiều thiết bị ra vào
  4. Loại trừ IP tĩnh — máy in, server, router nên dùng IP tĩnh nằm trong exclusion range

Bước 5: Kiểm tra DHCP Authorization trong Active Directory

Trong môi trường domain, DHCP server bắt buộc phải được ủy quyền trong AD mới cấp phát IP được. Đây là điểm nhiều người quên khi dựng server mới:

# Kiểm tra trạng thái ủy quyền
Get-DhcpServerInDC

# Ủy quyền DHCP server nếu chưa có
Add-DhcpServerInDC -DnsName "dhcpserver.domain.local" -IPAddress 192.168.1.10

Authorization có thể thất bại nếu: mục nhập DHCP bị xóa khỏi AD Configuration container, lỗi kết nối giữa DC và DHCP server, hoặc sự cố AD replication tạo ra CNF object xung đột.

Bước 6: Kiểm tra port và binding

# Kiểm tra port UDP 67/68
netstat -anb | findstr ":67 :68"

Đảm bảo không có dịch vụ khác (WDS, PXE) đang chiếm port 67/68. Cũng nên kiểm tra DHCP server đã bind đúng network interface qua tab Bindings trong DHCP server Properties — mình từng gặp trường hợp server có 2 NIC mà DHCP bind nhầm cái không dùng.

Bước 7: Kiểm tra DHCP Relay Agent trên các subnet khác

Client và DHCP server khác subnet? Router/switch phải có IP Helper Address để chuyển tiếp broadcast DHCP. Kiểm tra cấu hình:

# Ví dụ trên Cisco router
interface GigabitEthernet0/1
  ip helper-address 192.168.1.10

Thiếu IP Helper = client trên subnet đó sẽ không bao giờ nhận được IP. Đơn giản vậy thôi.

Phần 3: Xung đột DNS-DHCP Dynamic Update

3.1. Vấn đề ở đâu?

Trong Active Directory, DHCP server thường tự động cập nhật bản ghi DNS khi cấp hoặc thu hồi IP. Nghe tiện lợi, nhưng xung đột xảy ra khi:

  • Cả client lẫn DHCP server đều cố đăng ký DNS — tạo bản ghi trùng hoặc xung đột quyền sở hữu
  • DHCP server không có quyền cập nhật DNS zone — thường do chưa cấu hình nhóm DnsUpdateProxy
  • Zone đặt "Secure only" nhưng DHCP server hoặc client không có quyền phù hợp

3.2. Cấu hình khuyến nghị

Qua kinh nghiệm thực tế, đây là setup hoạt động ổn định nhất:

  1. Đặt DHCP server trên máy chủ riêng, không phải domain controller — tránh xung đột quyền sở hữu bản ghi DNS
  2. Tạo dedicated service account cho DHCP và thêm vào nhóm DnsUpdateProxy
  3. Cấu hình DNS zone ở chế độ "Secure only" dynamic update
  4. Trên DHCP server → DNS tab: chọn "Dynamically update DNS records only if requested by the DHCP clients"

Kiểm tra Event Viewer trên DHCP server — Event ID 31 (DNS Update Failed) và Event ID 32 (DNS Update Successful) sẽ cho bạn biết mọi thứ có ổn không.

Phần 4: Thiết lập DHCP Failover

Thật lòng mà nói, chạy một DHCP server đơn lẻ là rủi ro lớn. Nếu server đó chết, thiết bị mới không vào được mạng, lease hiện tại không gia hạn được — và bạn sẽ nhận được rất nhiều cuộc gọi.

Windows Server hỗ trợ DHCP Failover với hai chế độ:

  • Hot Standby — một server chính, một dự phòng. Phù hợp cho văn phòng chi nhánh
  • Load Balance — hai server cùng hoạt động, chia tải. Phù hợp cho trụ sở chính hoặc mạng lớn

Cấu hình qua PowerShell:

# Thiết lập DHCP Failover - Load Balance
Add-DhcpServerv4Failover -Name "DHCP-Failover" `
  -PartnerServer "dhcp2.domain.local" `
  -ScopeId 192.168.1.0 `
  -SharedSecret "MatKhauBaoMat123!" `
  -LoadBalancePercent 50 `
  -MaxClientLeadTime 1:00:00 `
  -AutoStateTransition $true `
  -StateSwitchInterval 0:30:00

Phần 5: Công cụ chẩn đoán nâng cao

5.1. DHCP Debug Log

DHCP server lưu debug log tại %windir%\System32\Dhcp. Để bật logging chi tiết:

# Bật DHCP audit logging
Set-DhcpServerAuditLog -Enable $true -Path "C:\Windows\System32\Dhcp"

# Kiểm tra file log
Get-ChildItem C:\Windows\System32\Dhcp\DhcpSrvLog-*.log

Các mã log quan trọng: 10 (New lease), 11 (Renewed), 12 (Released), 15 (Denied — scope full), 20 (BOOTP), 30+ (DNS update events). Mã 15 là cái bạn cần đặc biệt chú ý — nó báo scope đã đầy.

5.2. DNS Diagnostic Logging

# Bật DNS Debug Logging
Set-DnsServerDiagnostics -All $true

# Hoặc chọn lọc hơn (khuyến nghị cho production)
Set-DnsServerDiagnostics -Queries $true -Answers $true -EventLogLevel 2

Lưu ý: bật -All $true sẽ tạo rất nhiều log, chỉ nên dùng khi debug tích cực. Trên production, bật chọn lọc để tránh đầy ổ đĩa.

5.3. Packet Capture khi cần thiết

Đôi khi log không đủ, bạn cần nhìn thẳng vào gói tin mạng. Packet capture hữu ích khi cần phân tích quá trình DHCP DORA (Discover-Offer-Request-Acknowledge) hoặc phát hiện rogue DHCP server:

# Dùng netsh trace trên Windows Server
netsh trace start capture=yes tracefile=C:\Temp\dhcp_trace.etl protocol=UDP

# Dừng capture sau khi tái hiện lỗi
netsh trace stop

Phần 6: Best Practices cho IT Helpdesk

Sau khi đã đi qua toàn bộ quy trình, đây là những điều mình muốn nhấn mạnh:

  • Từ đơn giản đến phức tạp: dịch vụ → cáp mạng → driver → cấu hình IP → DNS/DHCP server. Đừng nhảy thẳng vào packet capture khi chưa kiểm tra cáp mạng
  • Ghi chép cấu hình DNS — khi sự cố xảy ra lúc 2 giờ sáng, tài liệu sẽ cứu bạn. Tin mình đi
  • IPv4 và IPv6 là hai thứ khác nhau — đừng giả định cả hai hoạt động chỉ vì một cái đang chạy
  • Giám sát chủ động với PRTG, Zabbix hoặc Nagios — theo dõi DNS query response time và DHCP scope usage trước khi người dùng gọi điện
  • Dọn dẹp DNS zone định kỳ — bản ghi cũ và CNAME sai gây lỗi âm thầm, đặc biệt trên mạng dùng DHCP nhiều
  • Kiểm tra sau mỗi lần Windows Update — sự cố DHCP sau bản cập nhật tích lũy đã được ghi nhận, luôn kiểm tra dịch vụ cốt lõi sau khi update
  • PowerShell là bạn tốt nhất — khi GUI lag hoặc không phản hồi, PowerShell thường vẫn kết nối được qua API backend

Câu hỏi thường gặp

Máy client nhận IP 169.254.x.x là sao?

Đó là địa chỉ APIPA — Windows tự gán khi không liên lạc được DHCP server. Xử lý theo thứ tự: kiểm tra cáp mạng và switch port → chạy ipconfig /release rồi ipconfig /renew → kiểm tra dịch vụ DHCP Server → kiểm tra scope còn IP không → kiểm tra IP Helper nếu client ở subnet khác.

Phân biệt lỗi DNS và lỗi mạng thế nào?

Cách nhanh nhất: ping 8.8.8.8. Ping được IP nhưng không vào website bằng tên miền? Lỗi DNS. Cả IP lẫn tên miền đều không ping được? Lỗi mạng hoặc routing. Dùng thêm nslookup để kiểm tra phân giải tên và tracert để kiểm tra tuyến đường.

DHCP nên đặt trên Domain Controller hay máy riêng?

Máy riêng. Khi DHCP chạy trên DC, nó dùng tài khoản máy DC để đăng ký DNS — dẫn đến xung đột quyền sở hữu bản ghi. DHCP có thể ghi đè bản ghi tĩnh của dịch vụ khác, và đó là kiểu lỗi rất khó debug. Đặt trên máy riêng với service account chuyên dụng là cách an toàn hơn nhiều.

Khi nào cần dùng packet capture?

Khi nghi có rogue DHCP server cấp IP sai, khi quá trình DORA bị gián đoạn mà log không cho đủ thông tin, hoặc khi DHCP Relay Agent không chuyển tiếp đúng giữa các subnet. Dùng Wireshark hoặc netsh trace trên Windows Server để capture và phân tích.

Giám sát DNS và DHCP chủ động như thế nào?

Dùng PRTG, Zabbix hoặc Nagios để theo dõi: thời gian phản hồi DNS query, tỷ lệ thất bại DNS resolution, phần trăm sử dụng DHCP scope (cảnh báo khi vượt 80%), và trạng thái dịch vụ. Kết hợp kiểm tra Event Viewer định kỳ để phát hiện lỗi trước khi ảnh hưởng người dùng.

Về Tác Giả Editorial Team

Our team of expert writers and editors.

Bài Viết Liên Quan