Мой вопрос, например ,.com, авторитетный сервер имен будет com-сервер правильно?
Пусть dig
Это:
# dig example.com SOA
;; ANSWER SECTION:
example.com. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2018080109 7200 3600 1209600 3600
;; AUTHORITY SECTION:
example.com. 86400 IN NS a.iana-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
Официальный сервер имен для example.com
является:
a.iana-servers.net.
b.iana-servers.net.
Это серверы, которые держат записи DNS для example.com
Теперь мы можем запросить их напрямую:
dig @a.iana-servers.net example.com A
;; ANSWER SECTION:
example.com. 86400 IN A 93.184.216.34
DNS решатель разобрать Полное доменное имя (Полное доменное имя) справа налево.
Первый запрос к корневым DNS-серверам с вопросом, кто является официальным DNS-сервером в TLD за .com
, а затем конкретный запрос резольвера TLD за example.com
с этих серверов.
# dnstracer -4 -r1 -s. example.com
Tracing to example.com[a] via A.ROOT-SERVERS.NET, maximum of 1 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4)
|\___ d.gtld-servers.net [com] (192.31.80.30)
| |\___ b.iana-servers.net [example.com] (2001:0500:008d:0000:0000:0000:0000:0053) Not queried
| |\___ b.iana-servers.net [example.com] (199.43.133.53) Got authoritative answer
| |\___ a.iana-servers.net [example.com] (2001:0500:008f:0000:0000:0000:0000:0053) Not queried
| \___ a.iana-servers.net [example.com] (199.43.135.53) Got authoritative answer
Давайте попробуем сейчас другой домен в .com
TLD :
# dig google.com SOA
;; AUTHORITY SECTION:
google.com. 345600 IN NS ns3.google.com.
google.com. 345600 IN NS ns4.google.com.
google.com. 345600 IN NS ns1.google.com.
google.com. 345600 IN NS ns2.google.com.
мы увидим, что авторитетные серверы имен для SLD google.com
сейчас другое.
так как это тот, кто дает нам информацию?
Нет, это цепочка авторитетных DNS-серверов.
Корневые DNS-серверы, содержащие только зоны верхнего уровня, также известные как TLD , - такие как .com
, .net
Когда решатель получил авторитетные DNS-серверы, отвечающие за TLD разрешить запрос конкретной зоны для SLD (Домен второго уровня, example
в нашем случае) и когда он нашел авторитетный DNS-сервер для SLD он запрашивает этот сервер для Полное доменное имя (Полное доменное имя), например, www.example.com
Обычно люди, использующие DNS-серверы интернет-провайдеров, которые содержат кешированные разрешенные записи DNS. Такие DNS-серверы называются пересылочными DNS-серверами. Если у них есть записи в кеше, они немедленно отвечают клиенту, не беспокоя всех промежуточных серверов, начиная с root. Если на таких DNS-серверах пересылки нет записей в кеше (или срок действия записи DNS истек), то переадресация разрешается снова и результат кешируется. DNS-запросы клиента отправляются как рекурсивные, это означает, что клиент должен получать от поставщика DNS либо ошибку, либо разрешенную запись. Клиент не должен самостоятельно запрашивать цепочку промежуточных DNS-серверов, это задача пересылки DNS-сервера, который обслуживает запросы клиентов и кэшированные результаты. Таким образом, серверы пересылки уменьшают нагрузку на промежуточные DNS-серверы и отвечают клиентам как можно скорее, поскольку DNS-серверы поставщиков находятся ближе к клиентам.
(Кстати, общедоступный DNS-сервер Google также является пересылкой.)
В DNS-записях есть параметр TTL (время жизни), который устанавливается на авторитетных серверах владельцем домена, поэтому, если вы ожидаете, что ваш IP-адрес будет часто меняться, вы можете установить TTL = 5 минут или если вы не хотите, чтобы его DNS-сервер был надоело слишком часто, тогда TTL можно установить на несколько дней.