Bản ghi AAAA chết: lỗi DNS âm thầm cộng 0,21 giây vào mỗi lần khách vào web

Lê Quốc Huy Digi 01/09/2026 0

Biểu đồ thời gian mở kết nối của 6 tên miền: ba site có AAAA chết mất 0,271 đến 0,289 giây, ba site đối chứng cùng dải IP chỉ mất 0,060 đến 0,082 giây

Đăng 01/09/2026Cách chúng tôi đánh giá

Sáng 01/09/2026 tôi đo ba tên miền mình có quyền quản trị DNS và tìm ra một thứ đã nằm đó rất lâu mà không ai nhìn thấy: cả ba đều có một bản ghi DNS trỏ tới một địa chỉ không hề trả lời.

Trình duyệt vẫn mở được web. Không có thông báo lỗi nào. Không có gì trong bảng điều khiển hosting báo động. Chỉ có một điều: mỗi lần có khách vào, máy của họ gõ cửa một địa chỉ chết, đợi hết giờ, rồi mới quay sang địa chỉ đúng.

Cái giá của việc đó, đo được, là 0,21 giây mỗi lần kết nối.

Và với những phần mềm không biết quay đầu — một số trình thu thập dữ liệu, thư viện lập trình, công cụ kiểm tra — cái giá không phải là 0,21 giây. Là không vào được.

Bản ghi AAAA là gì

Tên miền của bạn cần được dịch thành địa chỉ máy chủ. Có hai loại bản ghi làm việc đó:

Bản ghi	Trỏ tới	Ví dụ
A	địa chỉ IPv4 — kiểu cũ, bốn số	`185.146.167.193`
AAAA	địa chỉ IPv6 — kiểu mới, dài hơn	`2a07:7800::193`

Đọc là “quad-A”, tức bốn chữ A. Nó không phải thứ gì cao siêu: chỉ là bản ghi A phiên bản mới.

Vấn đề nằm ở chỗ hầu như không ai tự tay tạo bản ghi AAAA. Nhà cung cấp hosting thêm nó giùm bạn khi họ bật IPv6 cho hạ tầng. Bạn không yêu cầu, bạn không biết nó tồn tại, nên bạn cũng không bao giờ kiểm tra xem nó còn đúng hay không.

Điều gì xảy ra khi bản ghi AAAA chết

Trình duyệt hiện đại dùng một chiến thuật tên là Happy Eyeballs: khi tên miền có cả A lẫn AAAA, nó thử IPv6 trước, và nếu sau khoảng một phần tư giây chưa thấy trả lời thì nó lặng lẽ quay sang IPv4.

Chiến thuật này rất tốt — nó khiến web vẫn chạy khi IPv6 hỏng. Nhưng nó cũng chính là lý do lỗi này sống dai đến vậy: nó không bao giờ hiện ra thành một thông báo lỗi. Nó chỉ hiện ra thành một khoảng chờ, và khoảng chờ thì không ai để ý.

Số đo: ba site hỏng, ba site đối chứng

Tôi đo sáu tên miền, mỗi tên miền 5 lần, ở hai chế độ:

mặc định — để curl tự chọn đường, đúng như trình duyệt làm;
ép IPv4 — thêm cờ -4, tức bỏ qua hoàn toàn bản ghi AAAA.

Nếu bản ghi AAAA lành, hai chế độ phải cho cùng một kết quả. Nếu nó chết, chế độ mặc định sẽ phải trả thêm tiền chờ.

Cột quan trọng nhất là thời gian bắt tay (time_connect) — thời gian để mở được kết nối tới máy chủ. Tôi tách riêng cột này vì nó gần như không dao động theo tải máy chủ, nên chênh lệch ở đây là chênh lệch thật.

Tên miền	AAAA trỏ tới	Bắt tay (mặc định)	Bắt tay (ép IPv4)	Chênh
Site A	`2a07:7800:1::203`	0,275s	0,066s	+0,209s
Site B	`2a07:7800:1::204`	0,271s	0,060s	+0,211s
Site C	`2a07:7800:1::204`	0,289s	0,078s	+0,211s
Đối chứng 1	`2a07:7800::193`	0,082s	0,070s	+0,012s
Đối chứng 2	`2a07:7800::213`	0,060s	0,078s	−0,018s
Đối chứng 3	`2a07:7800::215`	0,062s	0,062s	0,000s

Ba site đầu: +0,209 / +0,211 / +0,211 giây. Ba con số gần như trùng khít nhau.

Ba site đối chứng: +0,012 / −0,018 / 0,000 giây. Tức là bằng không, trong phạm vi nhiễu.

Đây là lý do tôi tin kết quả này chứ không cho là ngẫu nhiên: nhóm đối chứng nằm trên đúng cùng một nhà cung cấp, cùng một dải IP với ba site hỏng. Cùng phần cứng, cùng đường truyền, cùng thời điểm đo, cùng một máy đo. Thứ duy nhất khác nhau là bản ghi AAAA trỏ đi đâu.

Nhìn kỹ hai địa chỉ

Site hỏng      :  2a07:7800:1::203
Site đối chứng :  2a07:7800::193
                          ↑
                     thừa một cụm ":1"

Cùng một nhà cung cấp, cùng một khối địa chỉ 2a07:7800. Nhưng nhóm chạy được nằm ở 2a07:7800::, còn nhóm hỏng nằm ở 2a07:7800:1:: — một nhánh con không có gì trả lời.

Tôi không biết vì sao có sự khác nhau đó: có thể là hạ tầng cũ đã dời đi, có thể là bản ghi được tạo tự động rồi để lại. Tôi chỉ đo được rằng một bên trả lời và một bên thì không, và tôi sẽ không đoán nguyên nhân mình không kiểm chứng được.

Ép đi bằng IPv6: hỏng hẳn, không phải chậm

Chênh lệch 0,21 giây ở trên là kịch bản may mắn — kịch bản mà phần mềm biết quay đầu.

Khi tôi ép curl chỉ được dùng IPv6 (cờ -6), cả ba site đều không vào được:

curl: (28) Failed to connect to ivi.vn port 443 after 12513 ms: Timed out

12,5 giây rồi bỏ cuộc. Ba site, ba lần, cùng một kết quả.

Ba site đối chứng, cùng lệnh đó, trả về bình thường trong 0,06 – 0,08 giây.

Đây mới là phần đáng lo. Trình duyệt của khách thì biết quay đầu. Nhưng rất nhiều thứ khác không, hoặc quay đầu chậm hơn nhiều: bộ thu thập dữ liệu của mạng xã hội khi bóc thẻ xem trước lúc bạn dán link, thư viện gọi API trong một ứng dụng khác, công cụ giám sát, một số dịch vụ kiểm tra tốc độ. Với chúng, tên miền của bạn có thể đơn giản là không tồn tại.

Nếu bạn từng dán link web của mình vào một khung chat và nó không hiện ảnh xem trước, trong khi mở bằng trình duyệt thì hoàn toàn bình thường — đây là một trong những nguyên nhân đáng kiểm tra.

Tự kiểm tra trong 30 giây

Cần đúng hai lệnh. Không phải cài gì.

Bước 1 — Xem mình có bản ghi AAAA không:

nslookup -type=AAAA tenmiencuaban.com 1.1.1.1

Nếu kết quả không có dòng Address nào chứa dấu hai chấm, bạn không có bản ghi AAAA. Dừng ở đây, bạn không dính lỗi này.

Bước 2 — Nếu có, thử xem nó còn sống không:

curl -6 -sS -o nul -w "Bat tay: %{time_connect}s | Ma: %{http_code}\n" https://tenmiencuaban.com/

Trên macOS/Linux đổi nul thành /dev/null.

Đọc kết quả:

Ra một con số và mã 200/301/403 → bản ghi AAAA của bạn lành. Xong.
Báo Failed to connect ... Timed out → bản ghi AAAA của bạn đang trỏ vào hư không.

Lưu ý một trường hợp dễ đọc nhầm: nếu ra mã 403 thì bản ghi AAAA vẫn lành. 403 nghĩa là máy chủ đã nhận được kết nối rồi mới từ chối — thường là tường lửa chặn curl vì nó không phải trình duyệt. Kết nối thành công mới là thứ ta đang kiểm tra ở bước này.

Bước 3 — Đo cái giá bạn đang trả:

curl -sS -o nul -w "mac dinh: %{time_connect}s\n" https://tenmiencuaban.com/
curl -4 -sS -o nul -w "ep IPv4 : %{time_connect}s\n" https://tenmiencuaban.com/

Chạy mỗi lệnh 5 lần. Nếu dòng trên đều đặn cao hơn dòng dưới khoảng 0,2 giây, bạn đang trả đúng cái giá mà tôi đo được ở trên.

Sửa thế nào

Có đúng hai đường, và đường nào cũng được — miễn đừng để nguyên trạng.

Cách 1 — Xoá bản ghi AAAA. Vào nơi quản lý DNS của tên miền, xoá các bản ghi loại AAAA. Website của bạn quay về chạy thuần IPv4, đúng như 18 trong 20 tên miền phổ biến ở Việt Nam mà tôi khảo sát bên dưới. Đây là cách nhanh nhất và ít rủi ro nhất.

Cách 2 — Sửa cho nó đúng. Hỏi nhà cung cấp hosting địa chỉ IPv6 thật của máy chủ bạn đang nằm, rồi sửa bản ghi AAAA trỏ đúng vào đó. Cách này giữ được IPv6, nhưng chỉ nên làm khi nhà cung cấp xác nhận rõ địa chỉ — đừng tự suy ra từ địa chỉ của một site khác.

Sau khi sửa, đợi hết thời gian TTL của bản ghi rồi đo lại bằng đúng lệnh ở bước 3. Đừng tin là đã xong chỉ vì đã bấm lưu.

Lỗi này phổ biến tới đâu?

Tôi khảo sát 20 tên miền phổ biến ở Việt Nam — báo điện tử, thương mại điện tử, ngân hàng, cơ quan nhà nước — xem có bao nhiêu tên miền dùng IPv6:

Kết quả	Số tên miền
Không có bản ghi AAAA	18 / 20
Có AAAA, và AAAA trả lời bình thường	2 / 20
Có AAAA nhưng AAAA chết	0 / 20

Hai tên miền có IPv6 là nguyenkim.com và batdongsan.com.vn, cả hai đều nhận IPv6 từ Cloudflare và cả hai đều trả lời bình thường.

Bảng 20 tên miền Việt Nam: chỉ nguyenkim.com và batdongsan.com.vn có bản ghi AAAA, 18 tên miền còn lại không có — Khảo sát ngày 01/09/2026: chỉ 2 trong 20 tên miền phổ biến ở Việt Nam có bản ghi AAAA, và cả hai đều nhận IPv6 từ Cloudflare.

Máy đo có hỏng không? Con số 18/20 quá tròn nên tôi phải tự kiểm tra chính công cụ của mình trước khi tin. Tôi chạy đúng phép đo đó trên 6 tên miền chắc chắn có IPv6 — google.com, cloudflare.com, facebook.com, youtube.com, wikipedia.org và một site đối chứng của tôi. Cả 6/6 đều được phát hiện có AAAA và cả 6 đều trả lời. Máy đo hoạt động đúng; 18/20 là con số thật.

Kết luận rút ra: IPv6 còn rất hiếm ở Việt Nam. Và chính vì hiếm nên gần như không ai nghĩ tới việc kiểm tra nó. Nếu nhà cung cấp của bạn có bật IPv6 — như nhà cung cấp của ba site trong bài này — bạn đang có một bản ghi mình chưa từng nhìn tới bao giờ.

Bảng chốt

Tình huống của bạn	Việc cần làm
`nslookup -type=AAAA` không ra địa chỉ nào	Không dính lỗi này. Bỏ qua.
Có AAAA, `curl -6` trả về mã 200/301/403	Lành. Không cần làm gì.
Có AAAA, `curl -6` báo `Timed out`	Xoá bản ghi AAAA, hoặc hỏi nhà cung cấp địa chỉ đúng.
Không biết chỗ nào sửa DNS	Nơi bạn mua tên miền, mục “Quản lý DNS” hoặc “Bản ghi tên miền”.

Những gì bài này KHÔNG nói

Tôi giữ nguyên tắc: không đo được thì không viết.

Bao nhiêu phần trăm khách của bạn đi bằng IPv6. Con số này phụ thuộc nhà mạng và thiết bị của từng người, tôi không có dữ liệu đó và sẽ không ước lượng.
Lỗi này ảnh hưởng thứ hạng tìm kiếm bao nhiêu. Tôi đo được thời gian kết nối, không đo được thứ hạng. Ai nói với bạn một con số cụ thể ở đây là đang đoán.
Vì sao nhà cung cấp lại tạo bản ghi trỏ sai. Tôi chỉ đo được là nó sai. Nguyên nhân thì phải hỏi chính họ.
Con số 0,21 giây có đúng với mọi người không. Đó là số đo từ một máy, một đường truyền ở Việt Nam, sáng 01/09/2026. Khoảng chờ này do phần mềm phía khách quyết định nên nó sẽ khác nhau đôi chút. Hãy đo trên chính máy bạn bằng lệnh ở bước 3.

Tóm lại

Chạy nslookup -type=AAAA tenmiencuaban.com 1.1.1.1.
Không có kết quả → bạn không dính lỗi này.
Có kết quả → chạy curl -6 xem nó có trả lời không.
Không trả lời → xoá bản ghi AAAA, hoặc xin nhà cung cấp địa chỉ đúng.

Ba mươi giây kiểm tra. Và nếu bạn thuộc nhóm dính lỗi, bạn lấy lại được 0,21 giây trên mọi lần khách kết nối — nhiều hơn phần lớn những gì người ta bán cho bạn dưới tên “gói tăng tốc”.

Cùng loạt bài đo trên website đang chạy thật: Hosting chậm hay website của bạn chậm? · Đo lại sau 17 tiếng — thứ hạng đảo lộn · Đọc header HTTP bằng một lệnh.

Số liệu trong bài đo bằng curl và nslookup trên một máy tại Việt Nam, ngày 01/09/2026. Mỗi tên miền đo 5 lần ở mỗi chế độ. Nhóm ba site đối chứng nằm cùng nhà cung cấp và cùng dải IP với nhóm ba site hỏng, nên chênh lệch giữa hai nhóm không thể quy cho phần cứng hay đường truyền. Máy đo được kiểm chứng bằng 6 tên miền quốc tế chắc chắn có IPv6 trước khi tin kết quả khảo sát.

{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Bản ghi AAAA là gì?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Bản ghi AAAA là bản ghi DNS trỏ tên miền tới một địa chỉ IPv6, tương tự bản ghi A trỏ tới địa chỉ IPv4. Khi tên miền có cả hai, phần lớn trình duyệt và công cụ sẽ thử IPv6 trước.”}},{“@type”:”Question”,”name”:”Bản ghi AAAA chết làm web chậm bao nhiêu?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Trong phép đo ngày 01/09/2026 trên ba tên miền có AAAA trỏ vào địa chỉ IPv6 không trả lời, thời gian mở kết nối tăng thêm 0,209 đến 0,211 giây so với khi ép dùng IPv4. Ba tên miền đối chứng cùng nhà cung cấp và cùng dải IP chỉ chênh từ âm 0,018 đến 0,012 giây.”}},{“@type”:”Question”,”name”:”Làm sao kiểm tra tên miền của tôi có bản ghi AAAA không?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Chạy lệnh nslookup -type=AAAA tenmiencuaban.com 1.1.1.1. Nếu không ra địa chỉ nào thì tên miền của bạn không có bản ghi AAAA và không dính lỗi này. Nếu ra địa chỉ, chạy tiếp curl -6 -sS -o nul -w \”%{time_connect}\” https://tenmiencuaban.com/ để xem địa chỉ đó có trả lời không.”}},{“@type”:”Question”,”name”:”curl -6 trả về mã 403 thì có phải bản ghi AAAA hỏng không?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Không. Mã 403 nghĩa là máy chủ đã nhận được kết nối rồi mới từ chối, thường do tường lửa chặn công cụ dòng lệnh. Kết nối thành công tức là bản ghi AAAA lành. Chỉ khi báo Timed out hoặc Failed to connect thì bản ghi mới thật sự chết.”}},{“@type”:”Question”,”name”:”Sửa bản ghi AAAA chết bằng cách nào?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Vào nơi quản lý DNS của tên miền, tìm bản ghi loại AAAA của tên miền gốc và của www, rồi xoá đi nếu bạn không dùng IPv6, hoặc hỏi nhà cung cấp hosting địa chỉ IPv6 đúng để thay vào. Xoá bản ghi AAAA không ảnh hưởng gì đến khách đi bằng IPv4, tức là gần như toàn bộ.”}},{“@type”:”Question”,”name”:”Có bao nhiêu website Việt Nam dùng IPv6?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Trong 20 tên miền phổ biến ở Việt Nam mà tôi khảo sát ngày 01/09/2026 gồm báo điện tử, thương mại điện tử, ngân hàng và cơ quan nhà nước, chỉ 2 tên miền có bản ghi AAAA và cả hai đều nhận IPv6 từ Cloudflare. 18 tên miền còn lại không có bản ghi AAAA.”}}]}

Đánh giá bài viết

Người viết: Lê Quốc Huy Digi · 15 bài trên sanphamtop1.vn

Lê Quốc Huy Digi: “Mình thích Công nghệ thông tin, AI, Automation & Marketing.” Anh sống ở Hà Nội, làm việc tại ivi.vn và viết ở huy.ivi.vn. Trên GitHub, anh công khai hai công cụ mã nguồn mở tự viết: VideoWatermarkRemover (Python) và YBMusic (JavaScript). Tại sanphamtop1.vn, các bài trong mục Công nghệ số do anh đứng tên đều ghi rõ số liệu đọc từ đâu, vào ngày nào và từ vị trí nào — chỗ nào không đọc được thì ghi là không đọc được, không điền số thay.

Bài viết có chứa liên kết tiếp thị. Nếu bạn mua hàng qua liên kết, chúng tôi có thể nhận hoa hồng từ nhà bán — giá bạn trả không thay đổi. Giá và tình trạng hàng do nhà bán quyết định và có thể đã khác lúc bài được cập nhật (cách chúng tôi làm việc).