Почему записи 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-адресов этих серверов имен. Это очень рискованно и нежелательно.