Как порядок поиска DNS определяется?
Нет Вы не делаете ничего плохого, это просто, что 5.1.6 последний доступный пакет - по крайней мере, в репозиториях CentOS. Можно сделать a yum info php получить более подробную информацию включая то, какой номер версии находится в репозиториях.
К сожалению, ответ здесь - «это зависит от обстоятельств». Факторы, от которых это зависит, будут зависеть от домена и того, как настроены серверы-владельцы, а также от того, как настроен ваш собственный локальный DNS.
Во-первых, например, в отношении возвращаемых записей NS: вполне допускается случайный порядок, в котором эти записи возвращаются, поэтому порядок может отличаться каждый раз, когда вы его запрашиваете. С другой стороны, это делается не всеми реализациями DNS, поэтому вы вполне можете получить статически упорядоченный список. Дело в том, что вы не можете быть уверены.
Затем некоторые реализации DNS будут запрашивать каждый NS параллельно и использовать тот, который отвечает первым. Другие будут попадать в каждый, определять самый быстрый из некоторого количества запросов и использовать его. Или это может быть просто циклический перебор.
Существует несколько RFC для DNS,
Наиболее распространенная реализация, которую я видел на уровне клиента, например у интернет-провайдеров по всему миру, выглядит следующим образом:
- Кто-то (например, широкополосный абонент) запрашивает DNS-серверы провайдера для разрешения записи A для foo.example.com.
- Интернет-провайдер проверяет свой собственный кеш, и, если эта запись кэшируется и все еще считается «свежей», она немедленно возвращается через кеш. ( Так работают все кэши DNS, чтобы они не перегружали DNS-серверы рассматриваемого сайта. )
- Если у них не было этой записи в кеше, или если кеш считается "устаревшим / устаревшим", провайдер знает, что ему нужно снова разрешить последнюю запись.
- Теперь провайдеру нужно знать, какие серверы имен запрашивать о последней записи.
- Интернет-провайдер начинает с проверки кэшированного списка авторитетных серверов имен для домена (это ns1.example.com, ns2.example.com и т. Д., А также их IP-адреса). Если эти записи все еще считаются свежими, он переходит к шагу 8.
- Если кэшированные записи сервера имен считались просроченными или если у них не было кэшированных записей для этого домена, ISP запрашивает корневые серверы имен этого домена. TLD (например, реестр .com, если это домен .com), чтобы получить самые последние пары имя / IP-адрес сервера имен для example.com. ( Вы можете попробовать это сами через "dig @ b.gtld-servers.net example.com", чтобы узнать, что корневые серверы имен вашего TLD знают о вашем домене - если ваш домен принадлежит обычному com / net / etc ДВУ. Другие ДВУ должны будут запросить соответствующие корневые серверы. )
- Корневые серверы имен для TLD всегда возвращают серверы имен в точном порядке , который они были указаны вами; никакой рандомизации не происходит. Они также возвращают IP-адреса для каждого сервера имен; это известно как «КЛЕЙ», и это то, что позволяет Интернету решить проблему «курицы и яйца» о том, как преобразовать имя хоста сервера имен в IP-адрес до того, как что-либо узнает о домене. Более того, большинство из них (например, реестры com / net / etc, которые являются самыми большими) используют время кеширования в 2 дня, чтобы их не забивали постоянно вопросом «каков список серверов имен для домена X?» Запросы. Это источник общеизвестной информации о том, что вы ДОЛЖНЫ подождать 2 дня, пока не сможете с уверенностью сказать, что ваши новые серверы имен известны во всем мире после того, как вы » Мы редактировали ваш список серверов имен.
- Когда интернет-провайдер знает серверы имен example.com и их IP-адреса, такие как ns1.example.com, ns2.example.com, ns3.example.com, теперь он выбирает случайный сервер из этого списка и отправляет запрос. ( Это хорошо с их стороны, они не бесполезно забивают все DNS-серверы рассматриваемого сайта и дополнительно помогают с балансировкой нагрузки, не всегда запрашивая первый указанный сервер имен. )
- Если Интернет-провайдер не получает ответа от этого сервера имен в течение указанного периода тайм-аута, он запрашивает другой из списка.
- Когда у него есть ответ, он теперь сохраняет его в собственном локальном кэше. Что касается того, как долго он будет оставаться в кеше; каждая запись, возвращаемая любым DNS-сервером, также имеет связанное с ней время «мягкого истечения» (в секундах), это время, в течение которого запрашивающему клиенту (например, DNS-серверу интернет-провайдера) разрешено кэшировать эту запись, прежде чем она будет считаться «все еще пригодной для использования, но, возможно, устаревшей, теперь должен выполняться новый запрос, ЕСЛИ ВОЗМОЖНО, просто чтобы убедиться, что он не изменилось ". Также существует время "окончательного истечения", которое указывается в записи "SOA" (начало полномочий) каждого отдельного сервера имен (вы можете увидеть свой через "dig @ ns1.example.com example.com -t soa"), который определяет глобальный «жесткий предел» для всех записей, возвращаемых этим сервером, после чего любой кеш ДОЛЖЕН УДАЛИТЬ свою кэшированную запись, ДАЖЕ ЕСЛИ серверы имен не работают и невозможно снова найти записи. Обычно мягкий срок годности составляет от 30 минут до 5 часов, а жесткий срок годности составляет 1-3 недели.
- После этой кропотливой работы провайдер, наконец, имеет последнюю запись DNS и может вернуть ее запрашивающему широкополосному абоненту, который не понимает, какая огромная работа была проделана за кулисами!
Это процесс. повторяется для КАЖДОГО поиска записи. Однако только первый запрос выполняет всю работу; IP-адреса серверов имен будут кэшироваться после этого, и последующие запросы к кэширующему DNS-серверу провайдера смогут быстро перейти к шагу 8.
Теперь, что касается рандомизации шага 8, он работает на уровне записи. Допустим, абонент широкополосного доступа этого интернет-провайдера спросил о следующих записях:
- A foo.example.com
- A example.com
- A www.example.com
- MX example.com (клиент ISP не следует запрашивать эту запись, это всего лишь пример)
Каждая запись будет обрабатываться как отдельная " идеальное зеркальное отображение каждой записи DNS на каждом сервере. Вы никогда никогда не знаете, к какому серверу будет подключаться DNS-клиент, и вы не можете полагаться ни на какой порядок. Такой вещи не существует.
Кроме того, как упомянул Адам C, серверы DNS уровня сервера (example.com) сами могут возвращать записи NS и рандомизировать их порядок. Обычные DNS-серверы часто рандомизируют свои NS-записи с небольшой вероятностью, что плохая реализация DNS всегда выбирает первый возвращенный namserver. Однако серверы имен ROOT TLD (упомянутые ранее) никогда не будут рандомизировать список, и их список - это то, что действительно важно, когда дело доходит до разрешения домена. Вот почему большинство реализаций выбирают случайный сервер из списков серверов имен, чтобы избежать постоянного обращения к одному и тому же серверу и его перегрузки.
Хорошо, это ваше руководство по тому, как работает DNS, и что вы должны помнить.
- Вкратце: относитесь ко всем своим DNS-серверам так, как если бы они были одним сервером, делая ваша высшая цель в жизни - убедиться, что все они одинаково способны ответить на любой запрос, который может быть им брошен.
Отказ от ответственности: более высокие цели в жизни, чем управление DNS, могут быть доступны, но продаются отдельно используйте свое воображение. ; -)