Tìm kiếm DNS

Cách thức hoạt động

1. Nhập một tên miền: nhập một tên miền, bao gồm các sub-domain, vào trường.
2. Chọn các loại bản ghi: chọn các loại bản ghi DNS để truy vấn: A, AAAA, MX, CNAME, TXT, NS, SOA hoặc tất cả.
3. Xem kết quả: các kết quả được lấy từ một nhà cung cấp DNS-over-HTTPS công cộng và được hiển thị với các giá trị TTL và dữ liệu.
4. Chẩn đoán: so sánh các kết quả giữa các loại bản ghi để xác định một cấu hình sai, sự chậm trễ truyền bá hoặc các bản ghi bị thiếu.

Tại sao sử dụng tìm kiếm DNS?

Các vấn đề về DNS là một trong những nguyên nhân phổ biến nhất gây ra sự không khả dụng của các trang web, sự thất bại trong việc giao thư và các vấn đề về di chuyển tên miền. Có thể truy vấn các bản ghi DNS trực tiếp từ trình duyệt, mà không cần đến các công cụ dòng lệnh như dig hoặc nslookup, là quý báu cho các nhà phát triển, DevOps và quản trị viên hệ thống. Công cụ này truy vấn các bản ghi qua DNS-over-HTTPS để bảo mật và bỏ qua tường lửa. Sử dụng nó để xác minh các bản ghi MX sau khi thay đổi nhà cung cấp email, xác nhận các bản ghi A/CNAME sau khi di chuyển DNS, kiểm tra các bản ghi TXT cho xác thực SPF/DKIM và chẩn đoán các sự chậm trễ truyền bá.

Các loại bản ghi DNS

• A, địa chỉ IPv4 của một tên miền
• AAAA, địa chỉ IPv6 của một tên miền
• MX, các bản ghi máy chủ thư cho định tuyến email
• CNAME, alias tên chuẩn trỏ đến một tên miền khác
• TXT, các bản ghi văn bản cho SPF, DKIM, xác minh tên miền
• NS, các máy chủ tên có thẩm quyền cho tên miền

40 năm DNS: từ RFC 882 đến DNS over QUIC

Domain Name System được thiết kế bởi Paul Mockapetris tại USC/ISI và được chỉ định trong RFC 882 và RFC 883 (tháng 11 năm 1983), thay thế tệp phẳng HOSTS.TXT mà ARPANET đã vượt qua. Hệ thống đã được đại tu và chính thức hóa trong RFC 1034 và RFC 1035 (tháng 11 năm 1987), các tài liệu vẫn được trích dẫn ngày nay. Jon Postel đã điều phối việc gán 13 máy chủ tên gốc ban đầu, được gắn nhãn từ a.root-servers.net đến m.root-servers.net, một số lượng được cố định không phải bởi dung lượng mà bởi giới hạn kích thước gói UDP 512 byte của thời đó. Hai cú sốc lớn đã định hình lại DNS trong thế kỷ này. Vào tháng 7 năm 2008, Dan Kaminsky đã tiết lộ một cuộc tấn công đầu độc bộ đệm cho phép kẻ tấn công tiêm các bản ghi giả mạo vào trình phân giải trong vài giây. Ngành công nghiệp đã phản ứng với một bản vá phối hợp (ngẫu nhiên hóa cổng nguồn) và quan tâm trở lại đến DNSSEC (RFC 4033-4035, tháng 3 năm 2005), ký các bản ghi bằng mật mã. Cú sốc thứ hai là quyền riêng tư: các truy vấn đi trong văn bản thuần trên cổng UDP 53 trong 35 năm. DNS over TLS (DoT, RFC 7858, tháng 5 năm 2016) gói các truy vấn trong TLS trên cổng 853. DNS over HTTPS (DoH, RFC 8484, tháng 10 năm 2018) đào hầm các truy vấn qua HTTPS trên cổng 443, che giấu cả việc DNS đang xảy ra. DNS over QUIC (RFC 9250, tháng 5 năm 2022) là mới nhất, sử dụng cùng phương tiện vận chuyển hỗ trợ HTTP/3. Các trình phân giải công cộng 1.1.1.1 (Cloudflare, ra mắt ngày 1 tháng 4 năm 2018), 8.8.8.8 (Google Public DNS, tháng 12 năm 2009) và 9.9.9.9 (Quad9, tháng 11 năm 2017) đều hỗ trợ DoH và DoT ngày nay.

Các loại bản ghi chi tiết

• A (RFC 1035). Địa chỉ IPv4 32 bit. Một miền có thể có nhiều bản ghi A để cân bằng tải; trình phân giải xoay vòng qua chúng (DNS round-robin).
• AAAA (RFC 3596, 2003). Địa chỉ IPv6 128 bit. Phát âm là «quad-A». Tính đến 2024, khoảng 45% lưu lượng truy cập của Google là IPv6.
• CNAME (RFC 1035). Bí danh: «theo tên này và tra cứu bản ghi của nó thay thế». Không thể cùng tồn tại với bất kỳ bản ghi nào khác ở cùng tên. Đây là lý do tại sao example.com không thể có cả CNAME và MX hoặc A ở đỉnh; các lựa chọn thay thế hiện đại sử dụng ALIAS hoặc ANAME (đặc thù của nhà cung cấp) hoặc các bản ghi HTTPS (RFC 9460, 2023).
• MX (RFC 1035, được cập nhật bởi RFC 7505 «null MX»). Máy chủ trao đổi thư với giá trị ưu tiên. Ưu tiên thấp hơn được ưa thích; các liên kết được ngẫu nhiên hóa. 0 . (RFC 7505, tháng 6 năm 2015) nói rõ ràng «miền này không nhận thư», chặn thư rác đến các miền không hộp thư.
• TXT (RFC 1035). Chuỗi văn bản tự do. Hiện mang xác thực quan trọng: SPF (RFC 7208, 2014), DKIM (RFC 6376, 2011), DMARC (RFC 7489, 2015) và xác minh quyền sở hữu cho Google Search Console, Microsoft 365, các thử thách ACME (Let's Encrypt) DNS-01.
• NS (RFC 1035). Tên của các máy chủ tên có thẩm quyền. Luôn ít nhất hai để dự phòng. Các «bản ghi keo» trong vùng cha cung cấp IP để một trình phân giải đệ quy có thể đạt đến máy chủ tên mà không cần tra cứu vòng.
• SOA (RFC 1035). Start of Authority. Bản ghi đơn cho mỗi vùng liệt kê máy chủ tên chính, email quản trị viên (với . đầu tiên được thay thế bằng @), số sê-ri (tăng lên khi thay đổi), refresh, retry, expire và TTL tối thiểu.
• CAA (RFC 8659, 2019; ban đầu RFC 6844, 2013). Certificate Authority Authorisation. Liệt kê các CA nào được phép cấp chứng chỉ cho miền. Kiểm tra bắt buộc theo yêu cầu cơ sở CA/Browser Forum kể từ tháng 9 năm 2017.
• SRV (RFC 2782, 2000). Vị trí dịch vụ: giao thức, ưu tiên, trọng số, cổng, máy chủ đích. Microsoft Active Directory, XMPP, SIP, liên đoàn Matrix đều sử dụng các bản ghi SRV để khám phá dịch vụ.
• PTR (RFC 1035). DNS ngược. Ánh xạ IP trở lại một miền. Tồn tại trong các vùng in-addr.arpa (IPv4) hoặc ip6.arpa (IPv6). Yêu cầu bởi nhiều máy chủ thư để chấp nhận email; PTR bị thiếu là tín hiệu thư rác phổ biến.
• DNSKEY / DS / RRSIG (RFC 4034-4035). Hệ thống đường ống DNSSEC. DNSKEY xuất bản khóa ký của vùng; DS trong vùng cha là con trỏ mật mã «đây là liên kết tiếp theo trong chuỗi»; RRSIG mang chữ ký thực tế cho mỗi bộ bản ghi.

Nơi DNS lookup thực sự giúp ích

• Thiết lập email trên miền mới. Xác minh các bản ghi MX trỏ đến nhà cung cấp đúng (Google Workspace aspmx.l.google.com, Microsoft 365 example-com.mail.protection.outlook.com, Fastmail, ProtonMail). Kiểm tra SPF (v=spf1 include:_spf.google.com ~all), DKIM (selector._domainkey), DMARC (_dmarc TXT).
• Di chuyển miền và truyền bá. Sau khi cập nhật các máy chủ tên tại nhà đăng ký, truy vấn cả máy chủ có thẩm quyền cũ và mới để xác nhận thay đổi đã được truyền đi toàn cầu. Các trình phân giải khác nhau lưu trữ trong các khoảng thời gian khác nhau (TTL là gợi ý, không phải hợp đồng).
• Khắc phục sự cố chứng chỉ TLS / SSL. Thử thách ACME DNS-01 được sử dụng bởi Let's Encrypt và tương tự yêu cầu đặt một bản ghi TXT tại _acme-challenge.example.com. Kiểm tra giá trị trước khi kích hoạt cấp chứng chỉ để tránh các nỗ lực giới hạn tốc độ lãng phí.
• Phát hiện rủi ro chiếm quyền miền phụ. Một CNAME trỏ đến dịch vụ chưa đăng ký (ứng dụng Heroku đã xóa, bucket S3 đã giải phóng) cho phép kẻ tấn công đăng ký nó và phục vụ nội dung trên miền phụ của bạn. Kiểm toán CNAME nhanh chóng bắt các con trỏ treo lủng lẳng.
• Xác minh CDN và bộ cân bằng tải. Xác nhận rằng một miền CNAME đến điểm cuối Cloudflare, Fastly, Akamai, CloudFront hoặc Vercel chính xác sau khi triển khai. Phát hiện khi staging trỏ vô tình vào sản xuất.
• So sánh DNS địa lý. Một số trang phục vụ các bản ghi A khác nhau theo khu vực (GeoDNS). Truy vấn từ các điểm cuối DoH khác nhau (Cloudflare 1.1.1.1 vs Google 8.8.8.8) gợi ý cách người dùng ở Frankfurt vs Mumbai nhìn thấy trang.
• Bảo mật và phản ứng sự cố. Tìm các bản ghi NS bất ngờ (chiếm đoạt nhà đăng ký), các bản ghi TXT đáng ngờ hoặc các bản ghi MX được thêm gần đây. Sử dụng số sê-ri SOA để theo dõi khi vùng thay đổi lần cuối.

Sai lầm DNS phá vỡ trang web và email

• CNAME tại đỉnh. RFC 1034 cấm đặt CNAME trên example.com chính nó (chỉ trên các miền phụ như www.example.com). Cloudflare, Route 53, DNSimple giải quyết điều này bằng CNAME flattening hoặc bản ghi ALIAS; Vercel, Netlify sử dụng bản ghi liên kết dịch vụ HTTPS (RFC 9460). Thử nó trên bảng điều khiển DNS của nhà đăng ký cơ bản âm thầm phá vỡ email.
• Quên giảm TTL trước khi di chuyển. Nếu bản ghi A của bạn có TTL 86400 (24 giờ) và bạn thay đổi nó vào buổi sáng chuyển đổi, các trình phân giải trên toàn thế giới sẽ tiếp tục phát IP cũ đến một ngày. Giảm TTL xuống 300 giây vài ngày trước khi thay đổi.
• Bản ghi SPF với quá nhiều tra cứu DNS. RFC 7208 giới hạn SPF ở 10 tra cứu DNS mỗi đánh giá. Chuỗi quá nhiều chỉ thị include: và bản ghi SPF của bạn thất bại với permerror, mà DMARC coi là thất bại. Làm phẳng hoặc hợp nhất với các công cụ như SPF Surveyor.
• CNAME treo sau khi tháo dỡ dịch vụ. Đã xóa ứng dụng Heroku nhưng CNAME app.example.com vẫn trỏ đến example.herokuapp.com? Bất kỳ ai cũng có thể đăng ký tên ứng dụng đó và lưu trữ nội dung của họ trên miền phụ của bạn. Kiểm toán và xóa các CNAME mồ côi.
• Không có bản ghi CAA. Không có bản ghi CAA, bất kỳ CA nào trong WebPKI (~50 trên toàn thế giới) có thể cấp chứng chỉ cho miền của bạn. Khóa nó vào một hoặc hai CA đáng tin cậy: 0 issue "letsencrypt.org". Kiểm tra CA bắt buộc kể từ tháng 9 năm 2017.
• Bản ghi wildcard che dấu các mục bị thiếu. Một bản ghi A *.example.com làm cho mỗi miền phụ sai chính tả được giải quyết, ẩn các lỗi cấu hình thực sự. Kết hợp cẩn thận với các quy tắc MX rõ ràng để tránh thư rác đến các địa chỉ sai chính tả.
• Trộn lẫn DNSSEC và các vùng không được ký trong quá trình chuyển đổi. Kích hoạt DNSSEC tại nhà đăng ký trước khi các máy chủ tên mới phục vụ các bản ghi được ký tạo ra SERVFAIL cho mỗi trình phân giải xác thực (Cloudflare 1.1.1.1, Quad9). Luôn ký trước, sau đó công bố bản ghi DS.

Thêm các câu hỏi thường gặp

Công cụ liên quan