Смысл записи 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, который работает с описанной вами проблемой, но мы до сих пор не рассмотрели Зачем все делается так.
Скажем, что я владею 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 меняет 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 этих серверов имен с нами. Это очень рискованно и нежелательно.
Решением проблемы являются связующие записи DNS, которые описаны на Что такое клейкая пластинка?.
RFC 1035, раздел 3.3.11 состояния
«... Обратите внимание, что класс может не указывать семейство протоколов, которое должно использоваться для связи» с хостом, хотя обычно это сильный намек ».
Возврат IP-адреса был бы равносилен указанию метода, с помощью которого можно связаться с хостом, что противоречит RFC.