Мой вопрос, например ,.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-распознаватель разбирает FQDN (полное доменное имя) справа налево.
Первый запрос будет искоренять DNS - сервера спрашивая, кто является авторитетным DNS - сервер в домене для .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
верхнего уровня :
# 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 можно установить на несколько дней.