Чому записи NS не містять IP-адреси?

Суть запису NS полягає в тому, щоб повідомити клієнту, який сервер імен точно буде знати фактичну IP-адресу для доменного імені. Так, наприклад, наступний запит повідомляє, що якщо ви хочете отримати авторитетну відповідь про facebook.comвас, ви повинні запитати 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

Це здається крутим і корисним, але мені цікаво, чому в ANSWERрозділі міститься ім'я хоста, а не IP авторитетного джерела? Чи не було б простіше клієнту отримати фактичну IP-адресу авторитетного джерела, а не ім'я хоста?

Я маю на увазі, якщо він отримає ім'я хоста, йому доведеться зробити ще один запит, щоб вирішити це ім'я хоста в IP, а потім запитати цей новий IP про початковий facebook.comдомен, який він шукав. Хіба це неефективно?

Мені буде цікаво відповісти, що вказує на деякі пункти в деяких RFC, що пояснює цю проблему.

Вирішення проблеми - записи DNS-клею, які описані у розділі Що таке запис клею? .

RFC 1035 Розділ 3.3.11 зазначає

"... Зауважте, що клас може не вказувати сімейство протоколів, які слід використовувати для зв'язку" з хостом, хоча це, як правило, сильний натяк. "

Повернення IP-адреси було б рівнозначним для того, щоб вказати метод, за допомогою якого можна зв’язатися з хостом, що суперечить RFC.

Джейсон надав механізм DNS, який працює навколо описаної вами проблеми, але ми все ще не розглядали, чому все робиться таким чином.

Скажімо, що я є власником example.com, і я підписав частину контенту свого веб-сайту на компанію з доставки вмісту на ім’я Contoso . Їх платформа вимагає від нас делегувати sub.example.comїх серверам імен, щоб вони могли контролювати, які відповіді повертаються.

; 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

Як ви зазначали, ми не вказали IP-адреси серверів імен Contoso. Все, що знає наш сервер, - це сказати в Інтернеті "ми не керуємо sub.example.com, запитуйте замість Contoso" . Це дуже важливо, оскільки:

• У нас немає Contoso.com.
• Ми не можемо очікувати, що Contoso координує зміну IP-адрес їх сервера з усіма клієнтами. Саме це повинно відбутися, якби наш сервер надав ці IP-адреси.

Все йде нормально. Минає рік, і невідомий нам Contoso змінює IP-адреси своїх серверів імен CDN. Оскільки DNS працює так , що він робить, всі вони повинні зробити , це обновити Aзаписи , які вони повертають для ns1.cdnі ns2.cdn.contoso.com..

Це підводить нас до важливого питання: записи клей , описані Джейсоном існує , щоб мати справу зі сценаріями «курки і яйця» в DNS, наприклад, google.comсказати світові , що їх сервери імен ns1.google.comі ns2.google.com. Ніколи не слід створювати записи клею, що вказують на інфраструктуру, якою ви не володієте, якщо вони не існують для вирішення такої проблеми:

@           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

Це дозволяє уникнути сценарію з курками та яйцями, але також робить його таким, що Contoso повинен координувати кожну зміну IP серверів цих імен із нами. Це дуже схильне до ризику та небажано.