Có giới hạn chính thức cho việc xác định tên máy chủ không?

Các bản ghi keo thường không khả dụng nếu một tên miền và máy chủ tên của nó không chia sẻ TLD và về mặt kỹ thuật không bắt buộc nếu chúng không chia sẻ cùng một tên miền cấp hai, điều này có thể dẫn đến các bước bổ sung để giải quyết một tên miền. Bộ giải quyết trước tiên phải tìm địa chỉ của máy chủ tên trước khi nó có thể tìm thấy địa chỉ cho tên miền của bạn. Nhưng về mặt lý thuyết, bạn có thể thêm nhiều bước trong đó hơn là chỉ hai bước đó.

Câu hỏi ở đây là, chuỗi đó được phép trong bao lâu ?

nếu xyz.comsử dụng máy chủ tên ns1.xyz.info,
và xyz.infosử dụng máy chủ tên ns1.xyz.co,
và xyz.cosử dụng máy chủ tên ns1.xyz.cc,
và xyz.ccsử dụng máy chủ tên ns1.xyz.co.uk, ... và vv

... bạn có thể kết thúc bằng một chuỗi rất dài để trình giải quyết gỡ rối trước khi nó có thể giải quyết tên bạn muốn ban đầu.

Có lẽ có một giới hạn thực tế - BIND chỉ nên sẵn sàng vượt qua rất nhiều liên kết, nếu không thì có khả năng bị từ chối dịch vụ. Nhưng có giới hạn chính thức không? Một số bước vượt quá trình giải quyết chính thức không bắt buộc phải tiến hành?

domain-name-system rfc

— tylerl
nguồn

Phần "giới hạn số lượng công việc" trong tools.ietf.org/html/rfc1035#section-7.1 là những gì tôi nghĩ đến. Nó không thực sự cụ thể về giới hạn nên là gì nhưng tôi không biết có một số quy tắc nhất định liên quan đến việc này.

— Håkan Lindqvist

Ngoài ra, bạn có thể giải thích một số tình huống thực tế mà bạn thấy trước đây là một vấn đề (nó xuất hiện rất khó xảy ra trong thực tế) hoặc là câu hỏi có tính chất học thuật thuần túy?

— Håkan Lindqvist

@ HåkanLindqvist Tôi thực sự đang xây dựng một công cụ tìm kiếm các vấn đề trong cấu hình DNS. Đây là một trong những vấn đề cần tìm kiếm. Câu hỏi là, hệ thống nên tái diễn sâu đến mức nào để tìm kiếm các vấn đề tiếp theo trước khi bỏ cuộc.

— tylerl

@tylerl Bạn có thể muốn xem github.com/dotse/dnscheck .

— Jenny D

@JennyD vâng, có một số dự án ngoài kia như thế. Nhưng tôi đang xây dựng một cái mà hy vọng cung cấp chi tiết tốt hơn và dễ hiểu hơn. Nhưng cảm ơn đã chỉ ra rằng một trong những.

— tylerl

if xyz.com uses nameserver ns1.xyz.info,

Trong trường hợp này, trình phân giải cục bộ của bạn trước tiên sẽ yêu cầu các máy chủ cho .com(ví dụ: a.gtld-servers.net) để tìm máy chủ tên cho tên miền xyz.com. Máy chủ tên miền .com thường sẽ cung cấp các bản ghi keo cho địa chỉ IP của máy chủ tên cho tên miền xyz.com.

ví dụ:

$ dig  gmail.com @a.gtld-servers.net 

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 <<>> gmail.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46893
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gmail.com.         IN  A

;; AUTHORITY SECTION:
gmail.com.      172800  IN  NS  ns2.google.com.
gmail.com.      172800  IN  NS  ns1.google.com.
gmail.com.      172800  IN  NS  ns3.google.com.
gmail.com.      172800  IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     172800  IN  A   216.239.34.10
ns1.google.com.     172800  IN  A   216.239.32.10
ns3.google.com.     172800  IN  A   216.239.36.10
ns4.google.com.     172800  IN  A   216.239.38.10

;; Query time: 375 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Thu Jul 10 01:10:57 EST 2014
;; MSG SIZE  rcvd: 181

Theo kinh nghiệm của tôi, tuyên bố của bạn rằng "Bản ghi keo thường không khả dụng nếu tên miền và máy chủ tên miền không chia sẻ TLD" đơn giản là không đúng. Tuy nhiên, nó phụ thuộc vào dữ liệu được cung cấp bởi nhà đăng ký cho tên miền và chính sách của họ khác nhau. Một số yêu cầu IP phải được chỉ định. Một số để lại cho chủ sở hữu tên miền. Tôi nghĩ rằng tôi nhớ một người ở Úc không hỗ trợ họ. Nếu số lượng đăng ký giao dịch với tên miền của quốc gia bạn ít, thì có lẽ điều này có thể đúng trong phần không gian tên miền đó, nhưng đối với toàn bộ mạng thì điều này là không điển hình.

Chủ sở hữu tên miền chắc chắn sẽ cung cấp các bản ghi Keo, nhưng đôi khi khả năng chỉ định máy chủ DNS theo tên mà không đóng IP được coi là cung cấp tính linh hoạt và nhiều chủ sở hữu tên miền không hiểu vấn đề hiệu suất mà điều này tạo ra.

Nếu bạn đang cung cấp một công cụ báo cáo DNS, nó có thực sự là giới hạn tuyệt đối cho cấu hình sai như vậy mà bạn quan tâm không? Chắc chắn sẽ tốt hơn khi bạn báo cáo các hồ sơ keo bị thiếu như một cảnh báo nếu thậm chí một vấn đề hồ sơ keo bị thiếu như vậy xuất hiện. Bạn có thể muốn theo dõi ít nhất một vài chỉ dẫn như bạn cung cấp, (và báo cáo các hồ sơ keo bị thiếu) nhưng phải có một số giới hạn về khoảng cách bạn nên theo dõi điều này. Tôi sẽ rất vui nếu một công cụ báo cáo DNS đã cảnh báo 3 người đầu tiên hoặc lâu hơn, vì tôi chỉ thực sự quan tâm đến việc thêm các bản ghi keo vào tên miền của mình hoặc chuyển nhà cung cấp DNS sang tên miền có thẩm quyền hơn.

Tôi nghi ngờ về cách tiếp cận DOS được đề xuất của bạn trên BIND, vì BIND sẽ lưu trữ thông tin mà nó thu thập về vị trí của các máy chủ tên. Kẻ tấn công sẽ phải thiết lập rất nhiều tên miền mà không cần keo dán và sau đó thực hiện rất nhiều truy vấn về chúng. Chi phí thiết lập các tên miền có khả năng bị hủy bởi nhà đăng ký sau khi sử dụng có thể khiến điều này không hấp dẫn đối với kẻ tấn công.

— mc0e
nguồn

.com và .net đều có thể xác thực. Họ là ngoại lệ. en.m.wikipedia.org/wiki/Verisign

— tylerl

Các 'trường hợp ngoại lệ' dường như bao trùm hầu hết các TLD mà tôi đã làm việc cùng, nhưng vâng, chắc chắn có những miền mà hồ sơ keo không có mặt.

— mc0e