Tại sao hồ sơ NS không chứa địa chỉ IP?

Điểm của bản ghi NS là cho khách hàng biết máy chủ tên nào sẽ biết chắc chắn địa chỉ IP thực tế cho một tên miền. Vì vậy, ví dụ, truy vấn sau đây cho bạn biết rằng nếu bạn muốn nhận được câu trả lời có thẩm quyền về facebook.combạn phải hỏi a.ns.facebook.com:

> dig ns facebook.com                                                                                                                                       19:58:27

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> ns facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32063
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;facebook.com.          IN  NS

;; ANSWER SECTION:
facebook.com.       65000   IN  NS  a.ns.facebook.com.
facebook.com.       65000   IN  NS  b.ns.facebook.com.

;; Query time: 13 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Mar 20 19:58:40 CET 2016
;; MSG SIZE  rcvd: 65

Điều này có vẻ hay và hữu ích nhưng tôi tự hỏi tại sao ANSWERphần này chứa tên máy chủ và không phải IP của nguồn có thẩm quyền? Không phải khách hàng sẽ dễ dàng lấy địa chỉ IP thực của nguồn có thẩm quyền chứ không phải tên máy chủ?

Ý tôi là nếu nó có được tên máy chủ thì nó sẽ phải thực hiện một truy vấn khác để phân giải tên máy chủ này thành IP và sau đó hỏi IP mới này về facebook.comtên miền ban đầu mà nó đang tìm kiếm. Đây có phải là không hiệu quả?

Tôi muốn được trả lời chỉ cho tôi một số đoạn trong một số RFC giải thích vấn đề này.

Giải pháp cho vấn đề là bản ghi keo DNS, được mô tả tại Bản ghi keo là gì? .

RFC 1035 Mục 3.3.11 trạng thái

"... Lưu ý rằng lớp có thể không chỉ ra họ giao thức nên được sử dụng để giao tiếp" với máy chủ, mặc dù đó thường là một gợi ý mạnh mẽ. "

Trả lại một địa chỉ IP sẽ tương đương với việc nêu rõ phương thức mà máy chủ có thể được liên lạc, điều này đi ngược lại với RFC.

Jason cung cấp cơ chế DNS hoạt động xung quanh vấn đề bạn mô tả, nhưng chúng tôi vẫn chưa xem tại sao mọi việc được thực hiện theo cách này.

Giả sử tôi sở hữu example.comvà tôi đã ký hợp đồng một số nội dung trang web của mình với một công ty phân phối nội dung có tên là Contoso . Nền tảng của họ yêu cầu chúng tôi ủy quyền sub.example.comcho máy chủ tên của họ để họ có thể kiểm soát những phản hồi được trả về.

; SOA and MX omitted from this example
$ORIGIN example.com.

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to Contoso's nameservers
sub         IN      NS            ns1.cdn.contoso.com.
sub         IN      NS            ns2.cdn.contoso.com.

; this is ours, not Contoso's
www         IN      A             198.51.100.1

Như bạn đã lưu ý, chúng tôi chưa chỉ định địa chỉ IP của máy chủ tên của Contoso. Tất cả các máy chủ của chúng tôi biết là nói với internet "chúng tôi không quản lý sub.example.com, thay vào đó hãy hỏi Contoso" . Điều này rất quan trọng, bởi vì:

• Chúng tôi không sở hữu Contoso.com.
• Chúng tôi không thể mong đợi Contoso phối hợp thay đổi IP máy chủ tên của họ với tất cả khách hàng của họ. Đó chính xác là những gì sẽ xảy ra nếu máy chủ của chúng tôi cung cấp các IP đó.

Càng xa càng tốt. Một năm trôi qua, và chúng tôi không biết rằng Contoso đang thay đổi địa chỉ IP của máy chủ tên CDN của họ. Bởi vì DNS hoạt động theo cách nó làm, tất cả những gì họ phải làm là cập nhật các Abản ghi mà họ trả lại ns1.cdnvà ns2.cdn.contoso.com..

Điều này đưa chúng ta đến một điểm quan trọng: các bản ghi keo được Jason mô tả tồn tại để xử lý các tình huống "gà và trứng" trong DNS, chẳng hạn như google.comnói với thế giới rằng máy chủ tên của chúng là ns1.google.comvà ns2.google.com. Bạn không bao giờ nên tạo hồ sơ keo chỉ vào cơ sở hạ tầng mà bạn không sở hữu trừ khi chúng tồn tại để giải quyết vấn đề như thế này:

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to ns1 and ns2.sub.example.com
sub         IN      NS            ns1.sub
sub         IN      NS            ns2.sub

; provide the IP addresses of ns1 and ns2 so that nameservers
; on the internet can find them.
;
; these IP addresses are owned by Contoso, not us, and they must
; coordinate changes to these IPs with us
ns1.sub     IN       A            203.0.113.10
ns1.sub     IN       A            203.1.113.10

Điều này tránh được kịch bản gà và trứng, nhưng cũng khiến cho Contoso phải phối hợp mọi thay đổi IP của các máy chủ tên đó với chúng tôi. Điều này rất dễ bị rủi ro và không mong muốn.