SOA и основная запись NS (DNS)
Основной вопрос заключается в следующем: каковы отношения между основным сервером имен, указанным в SOA запись и имена серверов, указанных в NS записей. Как эти вещи связаны?
Когда я запрашиваю большинство веб-сайтов, я получаю это:
dhamma@sansa:~$ host -t SOA arth.com
arth.com has SOA record ns1.comcastbusiness.net. domreg-tech.comcastbusiness.net. 2009072715 3600 7200 604800 7200
И я ожидаю увидеть ns1.comcastbusiness.net в качестве основного сервера имен, потому что, когда я запрашиваю NS запись для домена я получаю так:
dhamma@sansa:~$ host -t NS arth.com
arth.com name server ns1.comcastbusiness.net.
arth.com name server ns2.comcastbusiness.net.
arth.com name server ns3.comcastbusiness.net.
Это всегда заставляло меня думать, что SOA записи как-то автоматически заполняются первичными NS запись? Это даже отдаленно верно?
Потому что вот где я больше всего смущен:
dhamma@sansa:~$ host -t SOA paulwarnk.com
paulwarnk.com has SOA record a.dns.hostway.net. hostmaster.siteprotect.com. 2009012319 86400 7200 86400 99999
Но мне говорят и используют эти серверы имен:
dhamma@sansa:~$ host -t NS paulwarnk.com
paulwarnk.com name server adns.cs.siteprotect.com.
paulwarnk.com name server bdns.cs.siteprotect.com.
Почему этот сервер имен adns.cs.siteprotect.com не указан в качестве основного сервера имен в SOA запись?
2 ответа
RFC 1035 говорит:
MNAME<Имя-домена> сервера имен, который был исходным или основным источником данных для этой зоны.
хотя на практике это MNAME поле в SOA в основном не используется в эти дни.
Однако, если вы используете динамическое обновление DNS, оно должно ссылаться на имя DNS-сервера, который должен получать сообщения динамического обновления.
Смотрите также этот (просроченный) интернет-проект, в котором говорится о MNAME поле, и то, как сообщение об обновлении DNS является единственным текущим использованием для него.
Записи сервера имен указаны в вашем файле зоны. Запись SOA указывает основной сервер имен для зоны. Между ними нет автоматической связи. Вот хорошее прочтение относительно записей SOA. Короткий ответ: запись SOA - это запись, содержащая имя, TTL и т. Д. Кроме того, я настоятельно рекомендую взять книгу O'Reilly DNS & Bind. Это действительно довольно полезно.
Ваши записи за пределами корневых серверов для paulwarnk.com:
paulwarnk.com. 172800 IN NS adns.cs.siteprotect.com.
paulwarnk.com. 172800 IN NS bdns.cs.siteprotect.com.
;; Received 116 bytes from 192.55.83.30#53(M.GTLD-SERVERS.NET) in 152 ms
paulwarnk.com. 99999 IN A 69.143.69.166
paulwarnk.com. 99999 IN NS adns.cs.siteprotect.com.
paulwarnk.com. 99999 IN NS bdns.cs.siteprotect.com.
;; Received 100 bytes from 64.26.28.8#53(adns.cs.siteprotect.com) in 12 ms
Теперь это означает, что на корневых серверах adns & bdns.cs.siteprotect.com указаны в качестве прав доступа для paulwarnk.com. Затем на этих серверах (adns & bdns) есть запись A для корневой записи, указывающая на 69.143.69.166.
Я думаю, что вы спрашиваете, почему записи NS кажутся разными. Ответ заключается в том, что записи NS были указаны, вероятно, вашим регистратором, чтобы указывать на их серверы, которые являются полномочными для зоны. Однако эти выходные данные могут указывать на проблему, поскольку сервер имен SOA не отвечает на запрос ваших записей:
; <<>> DiG 9.2.4 <<>> @a.dns.hostway.net paulwarnk.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 37849
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;paulwarnk.com. IN A
;; Query time: 10 msec
;; SERVER: 66.113.129.243#53(66.113.129.243)
;; WHEN: Mon Nov 16 23:03:04 2009
;; MSG SIZE rcvd: 31
edit: AUTHORITY: 0 означает, что сервер a.dns.hostway.net не ответил авторитетно. Кажется, это довольно очевидно, когда есть раздел ОТВЕТ: 0, но на самом деле важно различать авторитетный ответ и неавторизованный. Власть в DNS говорит о том, можно ли доверять серверу, с которого вы получили ваш ответ, о том, о чем идет речь.
Что касается того, почему в SOA указан сервер, я не знаю, когда-либо читал причину, по которой они его там поместили, но этот сервер должен быть главным сервером для зоны, следовательно, Start of Authority, или SOA. Это не всегда так, поскольку SOA для всех 1400+ моих доменов перечисляет основной сервер запросов в SOA, но фактическое начало прав доступа находится на скрытом мастере, к которому никто не может получить доступ.