Dns

Зачастую, в силу того, что информация в сети распространяется не мгновенно, привязанные к серверу домены начинают работать не сразу. Чтобы не тратить время впустую, ожидая обновления кеша DNS, желательно сразу проверить настройку вашего DNS-сервера и убедиться, что по истечении 72 часов (это максимальное время обновления глобального кеша DNS) ваш домен заработает. Первичная диагностика Whois Начать диагностику следует с запроса whois: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [root@dns ~]# whois firstvds.ru % By submitting a query to RIPN's Whois Service % you agree to abide by the following terms of use: % http://www.ripn.net/about/servpol.html#3.2 (in Russian) % http://www.ripn.net/about/en/servpol.html#3.2 (in English). domain: FIRSTVDS.RU nserver: ns1.firstvds.ru. 82.146.43.2 nserver: ns2.firstvds.ru. 94.250.248.160 state: REGISTERED, DELEGATED, VERIFIED org: CJSC "Pervyj" registrar: REGTIME-REG-RIPN admin-contact: http://whois.webnames.ru created: 2002.08.07 paid-till: 2014.08.08 free-date: 2014.09.08 source: TCI Last updated on 2014.03.18 03:36:35 MSK В данном примере мы видим, что домен проделегирован на сервера имен ns1.firstvds.ru. и ns2.firstvds.ru. с указанием IP-адресов (дочерние NS-сервера всегда прописываются с указанием IP). Это корректный вывод whois и примерно так должен выглядеть ответ whois для зарегистрированного и проделегированного домена. Исключение составляет IP, он указывается только для дочерних NS-серверов. ...

Определение DNS (Domain Name System, «система доменных имён») — компьютерная распределённая система для получения информации о доменах. Основная область применения данной системы — преобразование имени хоста в IP-адрес и предоставления данных о маршрутизации почты. Хост — это любой компьютер или сервер, подключенный к локальной сети или интернету. Принцип работы Схематичное представление процесса определения определения IP-адреса по вводимому имени домена Работа DNS достаточно проста, но из-за незнания её основ возникает основная масса проблем и вопросов при переносе существующего доменного имени и регистрации нового. Остановимся немного подробней на описании самой схемы. Когда пользователь запускает веб-браузер и вводит название домена сайта, его ПК отправляет запрос к DNS-серверу интернет-провайдера для получения IP-адреса, на котором находится домен (1). Если DNS-серверы провайдера не обнаруживают в своем кэше информации о запрашиваемом сайте, то отправляют запрос на корневые DNS-серверы (2). Корневой DNS-сервер ищет в своей базе данных информацию о серверах имен хостинг-провайдера, на которых присутствует этот сайт. Далее, он сообщает их кэширующему DNS-серверу провайдера (3). После того, как кэширующий DNS-сервер интернет-провайдера получает информацию о серверах имен хостинг-провайдера он опрашивает любой из них (4) и, в случае получения положительного результата получения IP-адреса (5), помещает в кэш. Кэширование используется для того, чтобы снизить как нагрузку на интернет-каналы, так и для ускорения получения результата запроса. После этого DNS-сервер провайдера передает IP-адрес браузеру пользователя, совершившему запрос сайта (6). И уже после этого браузер, получив IP-адрес запрашиваемого сайта, переходит на сам сайт (7 и 8). Или вот более точное описание процесса. Ваш браузер об IP-адресе test.ru ничего не знает и с запросом IP-адреса через специальную программу — resolver обращается к локальному серверу имен. Локальный DNS-сервер — это сервер имен вашей локальной сети или DNS-сервер вашего интернет-провайдера. «Откуда браузеру известно о существовании этого локального DNS?» — спросите вы. Все предельно просто. При настройках сетевого подключения вы прописываете IP-адреса DNS-серверов (предпочитаемого и/или альтернативного), один из которых будет отвечать на запросы, посылаемые вашим браузером через resolver — это и есть локальный или местный сервер вашей сети. Вы всегда можете посмотреть IP-адрес вашего локального DNS-сервера. Для этого достаточно посмотреть свойства сетевого подключения, используемого на вашем компьютере. Запрос на IP-адрес test.ru доходит до местного сервера имен. Этот сервер о данном IP-адресе ничего не знает и посылает запрос одному из корневых серверов «.» (root). Корневой сервер отдает локальному серверу IP-адрес сервера, который поддерживает зону .RU. Далее по полученному адресу локальный сервер имен обращается к DNS-серверу, который поддерживает .RU. Этот DNS-сервер, в свою очередь, по полученному запросу отдает IP-адрес сервера, который поддерживает зону test.ru. Местный DNS-сервер с запросом IP-адреса test.ru обращается к DNS-серверу зоны test.ru. Локальный сервер имен получает IP-адрес test.ru от DNS-сервера зоны test.ru. Получив адрес test.ru, локальный DNS-сервер сообщает его вашему браузеру. Важно, что обновление информации о сервера имен провайдера происходит не мгновенно, а через некоторое определенное (для каждого DNS-сервера, в зависимости от настроек и провайдера данные значения могут варьироваться) время. ...

Возникла у меня задача делегировать управление обратными зонами для части подсети клиенту. И всё бы ничего, но из-за не знания некоторых моментов я этого не смог сделать быстро. Порывшись по интернету, решил сделать для себя заметку, в которой опишу наиболее важные, как я считаю, моменты. Приступим. Есть у нас большая сеть 100.200.200.0/24. Нам нужно отдать первому клиенту управление диапазоном 100.200.200.192/27 (100.200.200.193 - 100.200.200.222), второму клиенту диапазоном 100.200.200.224/27 (100.200.200.225 - 100.200.200.254). Есть на нашем DNS файл зоны: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 200.200.100.in-addr.arpa IN SOA ns1.host.com. hostmaster.host.com. ( 2016090100 ; serial 36000 ; refresh 3600 ; retry 1728000 ; expire 172800 ; minimum ) NS ns1.host.com. NS ns2.host.com. $ORIGIN 200.200.100.in-addr.arpa. ... 188 IN PTR client188.host.com. 189 IN PTR client189.host.com. 190 IN PTR client190.host.com. ; client1 192/27 IN NS ns1.client1.com. 192/27 IN NS ns2.client1.com. $GENERATE 192-223 $ IN CNAME $.192/27 ; client2 megaclient IN NS ns1.client2.com. megaclient IN NS ns2.client2.com. megaclient IN NS ns3.client2.com. 224 IN CNAME 224.megaclient.200.200.100.in-addr.arpa. 225 IN CNAME 225.megaclient.200.200.100.in-addr.arpa. 226 IN CNAME 226.megaclient.200.200.100.in-addr.arpa. 227 IN CNAME 227.megaclient.200.200.100.in-addr.arpa. 228 IN CNAME 228.megaclient.200.200.100.in-addr.arpa. ... и так далее ... Заметьте, будут работать обе части конфига, касательно client1 и касательно client2. Просто разный формат. В своё время client1 на своих DNS должен завести зону 192/27.200.200.100.in-addr.arpa,а client2 должен завести зону megaclient.200.200.100.in-addr.arpa. Обратите особое внимание, не 200.200.100.in-addr.arpa, а именно с префиксом в начале! ...