Check DNS: tra bản ghi DNS, SPF, DKIM, MX, CNAME
Nhập tên miền để tra toàn bộ bản ghi DNS hoặc kiểm tra propagation qua 3 resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9). Dùng khi set DNS cho website mới, kiểm tra SPF/DKIM cho email, hoặc phát hiện DNS chưa propagate đồng bộ sau khi đổi bản ghi.
Vì sao phải hỏi ba máy chủ phân giải cùng lúc
Công cụ này hỏi những đâu
Cùng một câu hỏi về một loại bản ghi được gửi song song tới ba máy chủ phân giải công cộng qua giao thức DNS trên HTTPS: Cloudflare tại 1.1.1.1, Google tại 8.8.8.8 và Quad9 tại 9.9.9.9. Thời gian phản hồi của từng nơi được đo riêng, kết quả đặt cạnh nhau để nhìn ra chỗ lệch.
Lúc nào cần soi nhiều nơi cùng lúc
Ngay sau khi đổi bản ghi A để chuyển máy chủ và muốn biết thay đổi đã lan tới đâu. Khi khách nói vào được website còn máy bạn thì không, hoặc ngược lại. Khi thư gửi đi rơi vào hộp thư rác và cần soi bản ghi TXT chứa SPF cùng DMARC. Khi chờ bản ghi CNAME xác thực để nhà cung cấp cấp chứng chỉ.
Đọc kết quả so sánh
Ba nơi trả về cùng dữ liệu nghĩa là thay đổi đã đồng bộ ở tầng phân giải công cộng. Lệch nhau nghĩa là ít nhất một nơi còn giữ bản ghi cũ trong bộ nhớ đệm và bạn phải chờ hết thời gian sống của bản ghi. Nhìn giá trị thời gian sống trả về để ước lượng phải chờ bao lâu; mẹo chuẩn là hạ giá trị đó xuống thấp vài giờ trước khi tiến hành đổi.
Điều kết quả này chưa nói hết
Ba máy chủ này không đại diện cho máy chủ phân giải của nhà mạng trong nước, vốn thường giữ bộ nhớ đệm lâu hơn nhiều; khách hàng của bạn có thể vẫn thấy trang cũ trong khi cả ba nơi ở đây đã cập nhật. Bản ghi TXT dài bị chia thành nhiều chuỗi trong ngoặc kép, phải ghép lại mới ra đúng một câu SPF. Kết quả rỗng thường chỉ có nghĩa tên miền không khai loại bản ghi đó, không phải hệ thống hỏng.
Ba truy vấn đi thẳng từ trình duyệt bạn. Trình duyệt gọi thẳng tới ba nhà cung cấp phân giải, máy chủ ALODEV không nhìn thấy tên miền bạn tra. Ba nhà cung cấp đó thì có ghi nhật ký truy vấn theo chính sách riêng của họ.
Các loại bản ghi DNS thường tra khi setup website và email
DNS dịch tên miền dễ đọc sang địa chỉ máy chủ và các chỉ dẫn khác mà máy tính dùng để định tuyến website, email. Mỗi loại bản ghi (record type) đảm nhận một việc riêng: dưới đây là những loại hay phải tra khi chuyển tên miền, đổi hosting hoặc set email doanh nghiệp.
- A - trỏ tên miền tới một địa chỉ IPv4.
- AAAA - trỏ tên miền tới một địa chỉ IPv6.
- MX - chỉ định máy chủ nhận email thay mặt tên miền, bắt buộc khi setup email doanh nghiệp.
- TXT - chứa văn bản tự do, dùng phổ biến nhất cho SPF, DKIM, DMARC và xác thực quyền sở hữu tên miền.
- NS - khai máy chủ tên miền (nameserver) chịu trách nhiệm phân giải cho toàn bộ tên miền.
- CNAME - trỏ một tên miền con tới một tên miền khác, hay dùng cho subdomain trỏ dịch vụ bên thứ ba.
- SOA - ghi thông tin quản trị vùng DNS: máy chủ chính, email quản trị, số phiên bản.
- CAA - khai tổ chức cấp chứng chỉ SSL nào được phép cấp chứng chỉ cho tên miền.
Vì sao email hay rơi vào rác nếu thiếu SPF, DKIM, DMARC
SPF, DKIM, DMARC đều nằm trong bản ghi TXT và cùng phục vụ một việc: chứng minh email gửi đi từ tên miền của bạn là thật. Thiếu một trong ba, các máy chủ nhận thư lớn như Gmail dễ đánh dấu email là rác hoặc từ chối thẳng, đặc biệt sau khi Gmail và Yahoo siết yêu cầu xác thực người gửi. Đây là lý do bản ghi TXT thường là nơi cần tra kỹ nhất khi chẩn đoán sự cố email không tới nơi.
Câu hỏi thường gặp
Bản ghi SPF, DKIM, DMARC dùng để làm gì?
Cả ba đều là bản ghi TXT giúp máy chủ nhận thư xác minh email gửi đi từ tên miền của bạn là thật, không phải giả mạo. SPF liệt kê những máy chủ được phép gửi email thay mặt tên miền. DKIM gắn chữ ký số vào mỗi email để chứng minh nội dung không bị sửa trên đường đi. DMARC nói cho máy chủ nhận biết phải làm gì khi một email không qua được SPF hoặc DKIM, ví dụ đưa vào rác hoặc từ chối thẳng. Thiếu một trong ba, email gửi từ tên miền dễ rơi vào hộp thư rác hoặc bị từ chối, đặc biệt sau các thay đổi của Gmail và Yahoo về xác thực người gửi.
MX record kiểm soát điều gì?
MX (Mail Exchange) record chỉ định máy chủ nào sẽ nhận email gửi tới tên miền, ví dụ trỏ về Google Workspace, Zoho Mail hay máy chủ mail riêng của công ty. Đổi MX record là bước bắt buộc khi chuyển nhà cung cấp email; đổi sai hoặc quên đổi khiến email gửi tới tên miền không tới được hộp thư nào cả.
CNAME record khác gì so với A record?
A record trỏ một tên miền thẳng tới một địa chỉ IP. CNAME record trỏ một tên miền tới một tên miền khác, để tên đó dùng chung địa chỉ IP của tên miền kia và tự động cập nhật theo nếu IP gốc đổi. CNAME hay dùng cho tên miền con (subdomain) trỏ tới dịch vụ bên thứ ba như CDN, nền tảng landing page, hoặc để xác thực quyền sở hữu tên miền khi đăng ký chứng chỉ SSL.
Sau khi đổi DNS thì mất bao lâu để lan truyền (propagation) xong?
Thường từ vài phút đến 24 đến 48 giờ, tuỳ thời gian sống (TTL) của bản ghi cũ và việc máy chủ phân giải của từng nhà mạng còn giữ bản ghi đó trong bộ nhớ đệm bao lâu. Bản ghi có TTL càng thấp thì cập nhật càng nhanh. Mẹo thường dùng là hạ TTL xuống vài phút trước khi đổi để giảm thời gian chờ, rồi tăng lại sau khi đã đổi xong và ổn định.
Vì sao ba resolver Cloudflare, Google, Quad9 trả kết quả khác nhau?
Đó là dấu hiệu DNS chưa lan truyền đồng bộ: một hoặc nhiều resolver vẫn còn giữ bản ghi cũ trong bộ nhớ đệm cho tới khi hết thời gian sống (TTL) của bản ghi đó, trong khi resolver khác đã lấy được bản ghi mới. Tình trạng này tự hết theo thời gian, không cần can thiệp gì thêm ngoài việc chờ.
Kết quả rỗng (không có record) nghĩa là gì?
Thường chỉ có nghĩa tên miền chưa khai loại bản ghi đó, không phải hệ thống DNS đang gặp lỗi. Ví dụ một tên miền chỉ dùng để hiển thị website có thể không có MX record vì không nhận email; một tên miền chưa cấu hình gửi mail thay mặt bên thứ ba nào thì cũng không có SPF.
