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