DNS: phân biệt lỗi phân giải tên với lỗi mạng

Nhân viên truy cập portal bằng tên thì lỗi, nhưng công cụ kiểm tra cổng443 của server vẫn thành công. Có người đề nghị đổi DNS sang một dịch vụ công cộng. Nếu portal là tên nội bộ hoặc VPN dùng split DNS, thay đổi ấy có thể làm lỗi nặng hơn và che mất bằng chứng ban đầu.

DNS trả lời câu hỏi về tên và các bản ghi. Nó không thay việc kiểm tra đường IP, TCP, TLS hay ứng dụng. Bài này dùng một portal nội bộ để phân biệt sai câu trả lời, không có câu trả lời và câu trả lời đúng nhưng dịch vụ vẫn lỗi.

1. Ghi đúng tên, loại bản ghi và resolver đang dùng

Ví dụ biên tập có client10.20.0.120/24, gateway 10.20.0.1 và DNS nội bộ10.99.0.53 được cấp theo lab DHCP. Portal có tên portal.example.test, bản ghi A dự kiến10.30.30.77. Tên thuộc miền dành cho ví dụ, không phải dịch vụ public cần truy cập thật.

Máy dùng Windows11 có PowerShell/DnsClient hoặc Linux có dig. Interface, VPN và ứng dụng có thể chọn resolver khác nhau. Ta giả thiết route tới resolver và server đã được thiết kế, chưa khẳng định chúng đang hoạt động. Không chỉnh DNS adapter, Hosts hay cache trước khi ghi cấu hình hiện tại.

Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.

Ghi FQDN đầy đủ, thời điểm, loại bản ghi A/AAAA và resolver trả lời. “Tên không vào được” chưa đủ để chuyển cho đội DNS. Một tên ngắn portal có thể được nối DNS suffix khác nhau; dùng portal.example.test. với dấu chấm cuối trong phép thử giúp giữ đúng tên tuyệt đối.

2. Recursive, authoritative và cache không cùng vai trò

Stub resolver ở client thường hỏi recursive resolver được cấu hình. Resolver tìm câu trả lời từ cache, forwarder hoặc hệ thống authoritative theo policy. Authoritative server giữ dữ liệu của zone mà nó có thẩm quyền. Recursive resolver không tự trở thành nơi sửa bản ghi gốc chỉ vì client hỏi nó.

Với tên Internet và cache miss, resolver có thể lần theo delegation từ root tới TLD và authoritative của zone. Đây không phải chuỗi bắt buộc diễn ra cho từng lần mở trang: cache và forwarding có thể giảm hoặc thay cách đi. Với example.test nội bộ, không nên vẽ resolver luôn phải hỏi public root; nó có thể có zone/conditional forwarding riêng.

A chứa IPv4, AAAA chứa IPv6, CNAME là bí danh trỏ tới tên khác. Trả về CNAME chưa luôn kết thúc toàn bộ quá trình lấy địa chỉ. Khi ứng dụng có cả A và AAAA, đường IPv6 lỗi có thể tạo hành vi khác với phép thử IPv4 đơn lẻ. Không tắt IPv6 chỉ để tránh đọc bản ghi AAAA.

RFC 1034 cung cấp nền về phân cấp, resolver và caching. Bài tập trung chẩn đoán phía client; thay đổi delegation, zone transfer hoặc DNSSEC key cần quy trình của đội quản trị DNS.

3. Đọc NXDOMAIN, NODATA, SERVFAIL và timeout đúng nghĩa

NXDOMAIN cho biết tên được trả lời là không tồn tại trong context trả lời đó. Nó không có nghĩa cáp mạng đứt; client đã nhận một thông điệp DNS. Nhưng resolver sai, split view hoặc tên gõ sai có thể làm kết quả ấy khác mong đợi. Cần giữ tên chính xác và resolver đã trả lời.

NODATA thường mô tả phản hồi NOERROR nhưng không có RRset loại đang hỏi. Tên có A mà không có AAAA là tình huống có thể hợp lệ, không phải NXDOMAIN của cả tên. Đọc loại câu hỏi, answer, authority và chuỗi CNAME thay vì đếm một bảng trống rồi kết luận domain chết.

SERVFAIL báo server không hoàn tất được truy vấn, có thể liên quan upstream, validation DNSSEC, cấu hình hoặc tài nguyên. Timeout nghĩa công cụ chưa nhận câu trả lời đầy đủ trong thời hạn; nguyên nhân có thể ở client, đường truyền, policy hoặc server. Không biến hai kết quả này thành cùng một lỗi “DNS không tồn tại”.

Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.

DNS truyền thống dùng cả UDP 53 và TCP 53; TCP không chỉ dành cho zone transfer. Phản hồi lớn, bị truncated hoặc các hành vi được hỗ trợ có thể cần TCP. RFC 7766 nêu yêu cầu hỗ trợ TCP. Kiểm tra TCP 53 thành công chưa chứng minh UDP 53 đang thông và ngược lại.

4. Hỏi có kiểm soát rồi tách phép thử dịch vụ

Trên Windows có DnsClient và NetTCPIP tương ứng, bắt đầu bằng các lệnh đọc. Địa chỉ/tên là ví dụ, không phải kết quả đã kiểm nghiệm:

ipconfig /all
Get-DnsClientServerAddress
Resolve-DnsName portal.example.test. -Type A -DnsOnly
Resolve-DnsName portal.example.test. -Type A -Server 10.99.0.53 -DnsOnly
Resolve-DnsName portal.example.test. -Type AAAA -Server 10.99.0.53 -DnsOnly
Test-NetConnection 10.30.30.77 -Port 443

Dòng không chỉ định server thể hiện phép thử theo lựa chọn của hệ thống/công cụ, còn dòng có -Server buộc hỏi resolver đã nêu trong phạm vi công cụ. Tài liệu Resolve-DnsName mô tả các tham số. Không coi -DnsOnly là bằng chứng đã tái tạo mọi hành vi của trình duyệt.

Trên hệ có dig, có thể đối chiếu rõ server và transport:

dig @10.99.0.53 portal.example.test. A
dig @10.99.0.53 portal.example.test. AAAA
dig @10.99.0.53 portal.example.test. A +tcp

Giữ status, answer, TTL, server, query time và thời điểm. Kết quả10.30.30.77 đúng dự kiến chỉ chứng minh một câu trả lời DNS. Test-NetConnection tới IP kiểm tra TCP, chưa xác nhận TLS/chứng thư hoặc nội dung HTTPS. Gõ trực tiếp IP vào trình duyệt có thể sai SNI, Host hoặc certificate, nên không dùng cách ấy làm phép thử tương đương portal bằng tên.

Nếu dùng công cụ ánh xạ tên tới IP tạm cho một request để giữ hostname/SNI, phải hiểu proxy, chứng thư và server ảo; không sửa Hosts lâu dài để che lỗi DNS. Đội ứng dụng cần xác minh đúng endpoint/backend trước khi coi kết nối tới một IP bất kỳ là thành công.

5. Theo dõi TTL qua các lớp cache trước khi xóa

TTL giới hạn thời gian một bản ghi được giữ theo cơ chế cache, không phải cam kết mọi người thấy IP mới sau đúng từng ấy giây kể từ khi sửa zone. Resolver có thể đã lấy bản cũ ở thời điểm khác; ứng dụng giữ kết nối hoặc cache riêng; CNAME và địa chỉ đích có TTL riêng. Các tính năng serve-stale/policy cũng cần đọc theo triển khai.

Ví dụ biên tập: resolver lưu A với TTL 300 giây lúc t 0, không refresh hay policy đặc biệt. Sau120 giây, TTL còn 180; không phải ghi lại 300 mỗi lần client hỏi. Một cache khác có thời điểm lấy khác nên TTL khác chưa tự chứng minh server trả sai.

Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.

Kết quả phủ định cũng có thể được cache. RFC 2308 phân biệt caching tên không tồn tại và RRset không tồn tại. Nếu bản ghi vừa được tạo, một resolver còn giữ phản hồi âm có thể tiếp tục trả lời khác cho tới khi điều kiện cache thay đổi.

Trên Windows, thu Get-DnsClientCache trước khi cân nhắc Clear-DnsClientCache hoặc ipconfig /flushdns. Xóa cache bỏ dữ liệu quan sát và buộc các truy vấn sau lấy lại; nó không sửa zone, resolver không tới được hoặc cache ở phía server. Chỉ làm sau khi đã xác định mục đích và giữ output cần thiết.

6. Khi hệ thống hỏi đúng nhưng trình duyệt hoặc VPN vẫn lỗi

Đối chiếu resolver của adapter/VPN, DNS suffix, policy tên và cơ chế Secure DNS/DoH trong ứng dụng. Một trình duyệt có resolver riêng có thể nhận câu trả lời khác với PowerShell. Không tắt bảo vệ hoặc VPN hàng loạt để “đưa mọi thứ về mặc định”; ghi policy đang áp dụng rồi phối hợp đội quản trị.

Split DNS cho phép cùng tên có dữ liệu khác theo môi trường. DNS công cộng thường không biết zone nội bộ, và không phải resolver thay thế hợp lệ cho máy cần tìm tài nguyên doanh nghiệp. Nếu query trực tiếp10.99.0.53 đúng mà truy vấn mặc định sai, tập trung vào lựa chọn resolver, suffix, Hosts và cache phía client trước khi sửa bản ghi gốc.

Microsoft hướng dẫn kiểm tra client DNS theo cấu hình, Hosts, đường tới server và suffix. Nếu nhiều máy cùng resolver cùng sai một tên còn tên khác tốt, chuyển bằng chứng tới đội DNS. Nếu chỉ một máy sai, so adapter/policy/cache với máy đối chứng trong cùng điều kiện.

Nếu DNS trả đúng A/AAAA nhưng TCP hoặc ứng dụng lỗi, quay lại giao thức và cổng dịch vụ, route, firewall và TLS. Ping không phản hồi không tự chứng minh DNS sai; ping nhận IP sai cũng cần giữ câu trả lời tên trước khi dùng kết quả ICMP để phân tích.

Một phép so có giá trị là cùng tên tuyệt đối, cùng loại A, cùng resolver và thời điểm gần nhau trên hai client ở cùng điều kiện mạng. Nếu kết quả khác, ghi cache, policy và đường truy vấn trước khi quy cho zone. Ngược lại, hai client dùng hai view hoặc hai VPN khác nhau có thể nhận IP khác mà vẫn đúng thiết kế. Bản so sánh cần ghi điều kiện giống và khác, không chỉ chụp hai địa chỉ IP.

Sau sửa bản ghi hoặc resolver policy, quan sát cả phiên kết nối mới. Một tab trình duyệt đang giữ kết nối TCP/TLS cũ có thể tiếp tục dùng backend cũ dù truy vấn DNS mới đã đúng. Đóng một phiên thử có kiểm soát hoặc dùng công cụ tạo kết nối mới giúp tách hai hiện tượng này mà không xóa toàn bộ trạng thái của người dùng.

7. Kết luận có bằng chứng và kiểm tra sau phục hồi

Hồ sơ chuyển đội cần tên đầy đủ, record type, resolver, thời điểm, status/answer/TTL, phạm vi máy bị ảnh hưởng và phép thử TCP/ứng dụng riêng. Nếu có capture theo quyền được cấp, giữ cặp query/response đúng transaction và transport, tránh chia sẻ tên nội bộ nhạy cảm ra ngoài.

• Đã phân biệt FQDN với tên ngắn và ghi resolver thực sự được thử.
• Đọc đúng NXDOMAIN/NODATA/SERVFAIL/timeout, không quy cùng nguyên nhân.
• Đối chiếu A/AAAA/CNAME và giới hạn TCP 53/UDP 53.
• Giữ cache/TTL trước sửa; không đổi sang DNS công cộng để chữa zone nội bộ.
• Thử lại cả phân giải và dịch vụ bằng hostname đúng sau phục hồi.

PDF trang vật lý 74 và phần dịch vụ mạng cuối sách cung cấp nền phân giải tên; chẩn đoán hiện hành trong bài được bổ sung bằng Microsoft/IETF. Tình huống, TTL và sơ đồ là biên tập, không phải quan sát production hay kết quả chạy lệnh. Câu hỏi tự kiểm tra: nếu A đúng nhưng AAAA dẫn tới đường IPv6 lỗi, vì sao chỉ thử TCP tới IPv4 chưa giải thích đầy đủ trải nghiệm của trình duyệt?