Khi DNS Google Public không thể phân giải miền, điều này thường do sự cố với miền đó hoặc máy chủ định danh có thẩm quyền của miền đó. Các bước sau đây có thể giúp xác định nguyên nhân gây ra sự cố để quản trị viên miền có thể tự khắc phục.
Trước khi bắt đầu các bước này, hãy kiểm tra miền tại dns.google như mô tả trên trang khắc phục sự cố chung. Trang này có thể dẫn bạn đến một bước chẩn đoán cụ thể bên dưới. Nếu không, hãy thử tất cả các bước sau cho đến khi bạn tìm thấy nguyên nhân.
Bước 1: Kiểm tra các vấn đề về xác thực DNSSEC
Nếu tra cứu web dns.google cho miền hiển thị "Status": 2 (SERVJCT) và truy vấn không có DNSSEC thành công, thì có thể đã xảy ra sự cố DNSSSEC với máy chủ định danh của miền hoặc tổ chức quản lý tên miền cấp cao nhất (TLD) của miền đó (xuất bản bản ghi DS để xác thực DNSSEC đã đăng ký đối với các miền).
- Thay đổi về nhà đăng ký tên miền hoặc dịch vụ DNS
Các sự cố về DNSSEC có thể xảy ra sau khi một miền chuyển từ nhà đăng ký tên miền hoặc dịch vụ DNS hỗ trợ DNSSEC sang một miền không có chức năng này. Nếu dịch vụ trước đó để lại các bản ghi
DScũ trong sổ đăng ký TLD và dịch vụ mới không tạo các bản ghiDNSKEYmới với các bản ghiDSphù hợp trong sổ đăng ký TLD, thì các trình phân giải xác thực như DNS công khai của Google không thể phân giải miền.Nếu điều này xảy ra, hãy yêu cầu nhà đăng ký tên miền của bạn xóa các bản ghi DS cũ khỏi sổ đăng ký TLD.
- Phản hồi DNSSEC quá lớn
Một nguyên nhân khác của DNSSEC, có thể là do các phản hồi DNSSEC quá lớn không thể đưa vào một gói IP, tạo ra các phản hồi phân mảnh có thể bị bỏ qua. Nếu DNSViz hiển thị "không nhận được phản hồi nào cho đến khi kích thước trọng tải UDP bị giảm" lỗi, lỗi DNSSEC có thể do các phản hồi rất lớn. Bạn có thể giảm kích thước phản hồi bằng một hoặc nhiều hành động sau:
- Định cấu hình "phản hồi tối thiểu" cho máy chủ định danh đáng tin cậy
- Giảm số lượng bản ghi
DNSKEYđang hoạt động xuống còn hai hoặc ba - Sử dụng bản ghi
DNSKEY1280 hoặc 2048 bit (RFC 6781, StackExchange) - Chuyển từ chữ ký RSA sang chữ ký ECDSA nhỏ hơn (RFC 8624)
Ngoài ra, hãy kiểm tra xem có bất kỳ sự cố DNSSEC nào khác được báo cáo bởi các công cụ trong bước 2 hay không. Ví dụ: các bản ghi không tồn tại NSEC hoặc NSEC3 không chính xác chứng minh rằng không có miền con nào (PowerDNS có các vùng được lưu trữ trong cơ sở dữ liệu bên ngoài có thể có những miền con này) hoặc chữ ký RRSIG đã hết hạn (có cấu hình quy trình ký thủ công bị hỏng).
Bước 2: Kiểm tra máy chủ định danh có thẩm quyền
Nếu DNS Google Public (hoặc bất kỳ trình phân giải mở) nào gặp sự cố khi phân giải miền, thì DNSViz sẽ hiển thị các vấn đề về miền và máy chủ định danh gây ra lỗi đó. Truy cập vào trang web DNSViz và nhập tên miền có vấn đề. Nếu DNSViz không có dữ liệu trong quá khứ hoặc chỉ có dữ liệu cách đây hơn một ngày (chẳng hạn như hiển thị trên trang ở đây), hãy nhấp vào nút Phân tích lớn để hiển thị nút Phân tích nhỏ hơn bên dưới (nếu chưa hiển thị) rồi nhấp vào đó. Khi phân tích hoàn tất, hãy nhấp vào "Tiếp tục" để hiển thị kết quả. Nhấp vào các lỗi màu đỏ và cảnh báo màu vàng trên thanh bên trái để hiển thị thông tin chi tiết hoặc giữ con trỏ trên các đối tượng trong sơ đồ để làm bật thông tin đó trong ngữ cảnh.
Nếu chẩn đoán trước đó cho thấy các vấn đề về DNSSEC có thể xảy ra với miền, hãy chuyển đến trang web của Trình phân tích DNSSEC rồi nhập tên miền. Nếu trình phân tích này báo cáo các lỗi hoặc cảnh báo DNSSEC,
hãy giữ con trỏ lên biểu tượng
Trang web intoDNS báo cáo các vấn đề không phải DNSSEC với miền được nhập trên trang chính, đồng thời hiển thị các đề xuất để khắc phục vấn đề.
Quản trị viên miền nên khắc phục hầu hết lỗi mà các công cụ này báo cáo, vì các lỗi đó có thể gây ra vấn đề không chỉ cho DNS công khai của Google mà còn cả các trình phân giải khác.
Bước 3: Kiểm tra các vấn đề về việc ủy quyền
DNS công khai của Google là trình phân giải "dành cho cha mẹ" chỉ sử dụng các máy chủ định danh được trả về trong các đường liên kết giới thiệu từ miền gốc. Nếu tên máy chủ định danh và địa chỉ keo trong TLD đã cũ hoặc không chính xác, việc này có thể gây ra sự cố ủy quyền.
Nếu DNSViz hoặc enterDNS báo cáo sự không thống nhất giữa các máy chủ định danh được ủy quyền trong TLD và các máy chủ hiện diện trong chính miền con, thì có thể bạn cần phải giải quyết các cảnh báo đó trước khi DNS Google Public có thể phân giải miền. Nếu những công cụ này báo cáo rằng miền đã đăng ký không tồn tại (NXDOMAIN), hãy kiểm tra để đảm bảo miền chưa hết hạn hoặc bị tạm ngưng đăng ký vì bất kỳ lý do gì.
Vấn đề ủy quyền cũng có thể xảy ra do việc không phân giải được
tên của máy chủ định danh cho một miền. Hãy kiểm tra bản ghi A và AAAA cho các máy chủ định danh
trên dns.google để xem có vấn đề gì với các máy chủ định danh\39; miền hay không.
Bước 4: Kiểm tra những phản hồi lớn
DNS sử dụng UDP để chuyển phần lớn lưu lượng truy cập. Các biểu đồ dữ liệu UDP lớn có thể bị phân mảnh và UDP bị phân mảnh sẽ bị phân phối không đáng tin cậy. Đây là tâm điểm của Ngày gắn cờ DNS năm 2020 – một nỗ lực nhằm cải thiện độ tin cậy của DNS trên toàn cầu. DNS Google Public đã tham gia nỗ lực này và giới hạn kích thước của các phản hồi UDP sẽ chấp nhận qua UDP. Hãy thử một truy vấn như bên dưới, kèm theo lời nhắc lệnh của bạn hoặc Google Cloud Shell:
$ dig +short example.com NS ns1.example.com ns2.example.com $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY ...
Những truy vấn này dành cho nhiều loại bản ghi đang chỉ định:
+dnssec- Bật DNSSEC, đặc biệt là trả về các bản ghi bắt buộc để xác thực DNSSEC khi có sẵn. Các phần mở rộng này có thể mở rộng đáng kể kích thước của kết quả. Phần này mô phỏng hành vi DNS của Google Public.
+bufsize=1400- Giới hạn kích thước vùng đệm UDP được phép. Hành vi này mô phỏng hành vi của DNS Công khai của Google, tính đến nỗ lực Ngày gắn cờ DNS năm 2020.
+timeout=1- Đặt thời gian chờ thành 1 giây. Phần này mô phỏng hành vi DNS của Google Public.
@ns1.example.com- Máy chủ có thẩm quyền cần truy vấn – giữ ký hiệu
@nhưng thay thế bằng máy chủ xác thực của riêng bạn, như được trình bày trong lệnh đầu tiên.
Quan sát kết quả; bạn sẽ thấy một dòng như:
;; Truncated, retrying in TCP mode.- Điều này cho thấy rằng phản hồi lớn hơn kích thước vùng đệm UDP được yêu cầu, vì vậy phản hồi đã bị cắt bớt và phản hồi là ứng dụng chuyển sang TCP. Các máy chủ đáng tin cậy phải có khả năng xử lý lưu lượng truy cập DNS trên cổng TCP 53. (Xem RFC 7766 yêu cầu rằng "triển khai PHẢI hỗ trợ cả truyền tải UDP và TCP".)
;; MSG SIZE rcvd: 2198- Đối với bất kỳ số nào trên 1400? Việc này một lần nữa cho thấy phản hồi lớn.
;; Query time: 727 msec- Đối với bất kỳ số nào trên 500? Phản hồi chậm (đặc biệt là những phản hồi gần 1 giây hoặc trên 1 giây) có thể bị DNS công khai của Google loại bỏ. Điều này đặc biệt có thể xảy ra nếu một khoảng thời gian dành cho một lần thử UDP sau đó là một lần thử TCP. Vị trí địa lý của máy chủ và ứng dụng khách có thể ảnh hưởng đáng kể đến độ trễ.
;; connection timed out; no servers could be reached- đặc biệt là khi chỉ đối với một số truy vấn, máy chủ sẽ không thể trả lời các truy vấn DNS kịp thời, gây ra vấn đề.
Bạn có thể thử các biến thể truy vấn sau:
- Thêm tham số
+tcp. - Thao tác này buộc
digsử dụng TCP ngay lập tức. Bạn có thể kiểm tra xem máy chủ ủy quyền có xử lý truy vấn TCP trực tiếp theo cách này hay không. - Đang xoá thông số
+bufsize=1400. - Thao tác này sẽ khôi phục hành vi mặc định của
dig(kích thước 4096). Nếu truy vấn của bạn không thành công với chế độ cài đặt này nhưng không hoạt động, thì đây là gợi ý cho biết máy chủ của bạn không xử lý quá trình chuyển đổi dự phòng TCP. Sử dụng UDP để mang theo phản hồi lớn chỉ hoạt động đôi khi. Cách tốt nhất là hỗ trợ truyền tải TCP cho DNS. - Lặp lại ở mỗi máy chủ định danh.
- Ví dụ trên có hai máy chủ định danh đáng tin cậy (
ns1vàns2). Một số vấn đề là do các máy chủ khác nhau trả về các câu trả lời khác nhau. Hãy kiểm tra để đảm bảo tất cả người dùng đều trả lời một cách nhất quán bằng cách lặp lại các truy vấn giống nhau tại tất cả các máy chủ có thẩm quyền.
Nếu tất cả các truy vấn\39; phản hồi nhỏ (1400 byte trở xuống), nhanh (tốt nhất là 500 mili giây trở lên) và đáng tin cậy (hoạt động nhất quán qua TCP và UDP), thì kích thước phản hồi không phải là vấn đề bạn cần quan tâm; hãy đọc các phần khắc phục sự cố khác. Ngay cả khi phản hồi của bạn nhanh, các cụm từ tìm kiếm từ xa về mặt địa lý có thể sẽ chậm hơn.
Nếu bất kỳ bước kiểm tra nào không thực hiện được (lớn? chậm? không đáng tin cậy?) thì hành động chính là để A) đảm bảo rằng máy chủ phản hồi bằng lệnh cắt ngắn UDP, khi phản hồi của máy vượt quá kích thước vùng đệm UDP yêu cầu và B) có thể xử lý thử lại truy vấn TCP. Một số công cụ có thể giúp bạn chẩn đoán các vấn đề về độ tin cậy của DNS:
- DNSViz
- Trình gỡ lỗi DNSSEC
- Trình kiểm tra tuân thủ EDNS
- Trình kiểm tra DNS -- hãy nhớ bỏ chọn hộp "CD" (tắt tính năng kiểm tra DNSSEC)
Hãy đảm bảo xử lý mọi lỗi hoặc cảnh báo bằng các công cụ này. Ngoài ra, hãy nhớ đọc tất cả các hướng dẫn khắc phục sự cố khác trên trang web này.
Bước 5: Kiểm tra xem các trình phân giải công khai khác có phân giải được miền hay không
Nếu bạn không tìm thấy nguyên nhân của vấn đề sau khi làm theo các bước ở trên,
hãy chạy các lệnh sau tại lời nhắc lệnh, thay thế example.test. bằng
miền được đề cập (và giữ nguyên các dấu chấm ở cuối):
Windows
nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.
macOS hoặc Linux
dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'
Các lệnh này sử dụng trình phân giải DNS của OpenDNS, Quad9 và Cloudflare 1.1.1.1. Nếu bạn gặp sự cố về độ phân giải từ hai lỗi này cũng như DNS Google Public, thì vấn đề có thể là do miền hoặc máy chủ định danh của miền.
Nếu bạn nhận được kết quả thành công từ nhiều trình phân giải công khai khác, thì có thể đã xảy ra sự cố với DNS Google Public. Nếu không có báo cáo tương tự nào được báo cáo cho miền (hoặc TLD của miền đó) trên trình theo dõi vấn đề, bạn nên báo cáo vấn đề cho chúng tôi, bao gồm đầu ra lệnh và văn bản trang chẩn đoán hoặc ảnh chụp màn hình trong báo cáo của bạn.