Как известно, NS записи — это основная настройка, которая может быть у домена, и от того, какие NS указаны у домена, зависит, что будет отображать и вообще как будет вести себя домен.
Как узнать какие NS у домена
Чтобы узнать, какие NS записи прописаны у домена, мы воспользуемся 2-мя бесплатными сервисами.
1. Сайт регистратора nic.ru
2. Сервис dnswatch.info
И так, например у нас есть сайт (домен) mysite.ru
Заходим на первый сервис, а именно на страницу — https://www.nic.ru/whois/ , затем указываем наш домен в текстовое поле и нажимаем на кнопку "показать".
Ниже будет отображена информация о домене. Среди прочих параметров, нам нужно найти строчку nserver
Рисунок 1.
На рисунке видно какие NS записи у домена сейчас прописаны.
Особенность сервиса niс, что он показывает какие NS прописаны у домена, а не какие реально сейчас есть.
Т.е. может быть ситуация, когда вы указали новые NS, и они уже отображаются на сайте nic.ru, но домен всё ещё не работает или показывает старый сайт.
Для проверки этого момента мы и воспользуемся вторым сервисом.
И так, по аналогии, переходим по ссылке — http://www.dnswatch.info/, указываем домен и нажимаем кнопку "resolve".
Далее, внизу, нам будет показана информация по домену, легко находим строку NS.
Рисунок 2.
Особенность сервиса dnswatch.info, в том что он показывает реально используемые NS у домена на данный момент. Удобство в том что вы можете периодически проверять не обновились ли NS записи через этот сервис.
После обновления NS домен все ещё на заработал
Обратите внимание, что обновление NS записей у домена занимает от 2х до 72х часов.
- Проверьте какие NS у домена на сайте nic.ru
- Проверьте какие NS у домена на сайте dnswatch.info
Если записи отличаются, значит записи ещё не обновились, необходимо дождаться обновления.
www.advantshop.net
Запись A
Запись A (address) — адресная запись, необходима для связи домена и IP-адреса сервера. Проще говоря, для работы вашего сайта и всех поддоменов.
Когда вы вводите название сайта в адресную строку браузера, именно по записи A служба доменных имён определяет, с какого сервера нужно открывать ваш сайт.
Примеры записи A:
Прописать А-запись вы можете по инструкции Как добавить запись А (поддомен)
Запись CNAME
CNAME (Canonical name) — каноническое имя для псевдонима. Запись CNAME чаще всего используется для переадресации поддомена на другой домен. Добавить запись можно по инструкции Как добавить запись CNAME.
Примеры записи CNAME:
В данном примере, если вы введете доменное имя webmail.site.ru в строку браузера, вы будете переадресованы на сайт webmail.hosting.reg.ru.
Одновременно добавить запись CNAME и запись A для одного и того же поддомена невозможно, т.е. нельзя добавить и запись A и запись CNAME для поддомена webmail.site.ru.
Запись MX
MX (Mail Exchanger) — адрес почтового шлюза для домена. Состоит из двух частей — приоритета и адреса узла. Записи MX критически важны для работы почты. Благодаря им отправляющая сторона «понимает» на какой сервер нужно отправлять почту для вашего домена.
Пример записи MX:
Записей MX может быть несколько. Делается это для того, чтобы в случае недоступности одного из почтовых серверов, почта была все же отправлена на другой. Приоритет записи определяет, на какой сервер нужно отправлять почту в первую очередь. Если приоритет одинаковый, сервер выбирается случайным образом. Чтобы добавить MX-запись, воспользуйтесь инструкцией Как добавить запись MX.
Запись NS
NS (Authoritative name server) — адрес узла, отвечающего за доменную зону. Проще говоря, запись NS указывает, какие DNS-серверы хранят информацию о домене. Критически важна для работы службы DNS.
Запись PTR
Обратная DNS-запись — связывает IP-адрес сервера с его каноническим именем (доменом). PTR-запись широко применяется в фильтрации почты. Для всех серверов виртуального хостинга REG.RU обратные DNS-записи уже прописаны. Если у вас виртуальный сервер VPS или выделенный сервер, прописать PTR-запись можно по инструкции Как настроить PTR-запись.
Запись SOA
SOA (Start of Authority) — указывает, на каком сервере хранится эталонная информация о доменном имени. Критически важна для работы службы DNS. Подробнее о том, что такое SOA-запись и как ее проверить, вы можете ознакомиться в инструкции
Запись SPF
SPF (Sender Policy Framework) — указывает сервера, которые могут отправлять почту от имени домена. Запись SPF вносят в TXT-запись домена.
Пример записи SPF:
В данном примере:
- v=spf1 — определяет версию используемой записи SPF;
- include:_spf.hosting.reg.ru — включает в запись SPF значение SPF-записи другого домена. Т.е. для домена будут действовать в том числе все значения записи SPF для домена «_spf.hosting.reg.ru»;
- ip4:37.140.192.92 — разрешает прием почты с IP-адреса 37.140.192.92;
- a — разрешает приём почты с сервера, IP-адрес которого стоит в ресурсной A-записи домена. Проще говоря с сервера, где размещен сайт;
- mx — разрешает приём почты, если отправляющий сервер указан в одной из записей MX для домена;
- ~all — если письмо пришло с сервера, который не входит в вышеперечисленный список, его стоит проанализировать более тщательно. Также иногда используется -all — в этом случае письмо не проходит дополнительных проверок и сразу отвергается.
Подробнее о настройке записи SPF читайте в инструкции Как настроить SPF-запись.
Запись TXT
TXT (Text string) — содержит любую текстовую запись. Широко применяется для проверок на право владения доменом при подключении дополнительных сервисов, а также для записи SPF и ключа DKIM.
Записей TXT может быть сколько угодно. Вам может потребоваться добавить записи TXT при подключении бесплатной Яндекс.Почты и при получении бесплатного SSL-сертификата, и они не будут друг другу мешать, так как необходимы для подтверждения владения доменом в разных сервисах, в первом случае — в Яндекс, во втором — в сертификационном центре Global Sign.
Добавить TXT-запись вы можете по инструкции Как добавить запись TXT.
www.reg.ru
Данная статья не является каким-то конкретным и детальным руководством по всем нюансам с NS серверами, я лишь расскажу о небольшом личном опыте с решением вопросов на конкретных примерах. Каждый вебмастер сталкивается с подобными ситуациями, когда нужно было прописывать NS, создавать, изменять и т.п. — это часть работы с доменам и хостингами. Опытным уже все дается достаточно просто, а вот для начинающих разобраться порой не так легко. Поэтому приготовил парочку историй из жизни, так сказать.
Итак, для начала немного терминов. Вообще DNS — система доменных имен, грубо говоря задает соответствие между доменным именем и реальным IP адресом сайта, вы вводите домен и попадаете по нужному адресу. Для каждого домена после регистрации вы можете указывать различные DNS записей, которые помогают сайту быть найденным в глобальной паутине:
- Запись A (запись адреса) — указывает IP адрес хостинга, где находится наш сайт.
- Запись MX (адрес посты) — определяет IP адрес постового сервера для домена, как правило, совпадает с записью A.
- Запись NS (name server) — указывает на DNS-сервер для конкретного домена.
Рассмотрим данные нюансы на примере работы с регистратором доменов Webnames. Для любого домена у нас есть 2 варианта задания соответствия между доменом и хостингом:
1. Указание записей A и MX, которые будут содержать IP хостинга с нашим сайтом:
При этом данное соответствие будет «храниться» в NS записях регистратора (webnames). Поэтому при создании хостинг аккаунтов вы можете использовать NS регистратора — в данном случае это ns1.nameself.com и ns2.nameself.com. При этом во вкладке DNS сервера в вашей учетной записи найдете:
2. В том же разделе меню управление DNS для домена вы также можете указать NS сервера хостера, например:
Теперь, по сути, вся ответственность по заданию соответствия между IP адресом и вашим доменом лежит на компании, которая эти DNS предоставляет. В данном случае это хостинг CoolVDS. Там, кстати, можно прикупить выделенный сервер в США, что хорошо подойдет по MFA сайты. Для того чтобы там «подключить» домен нужно обратиться в тех.поддежку на почту support@coolvds.com: в теме письма пишите «домен для ваш_сервер.coolvds.com», где в тексте указываете домен, ip и опять имя сервера, например:
mydomain.com:193.333.555.777:ваше_имя.coolvds.com
Может слегка запутано, но только в первый раз. Другие хостинги могут при покупке хостинга спрашивать какие DNS использовать. Например, так делается в Hostpro, и если вы выберете использовать их DNS, тогда просто для своего домена нужно будет указать их NS сервера — master.hostsila.com и slave.hostsila.net без всяких A и MX записей.
Точно также 2 варианта, о которых я сказал выше есть у большинства нормальных регистраторов доменов. Еще один пример — Getnic.name. Здесь вы можете воспользоваться услугой бесплатного управления DNS или указать сторонние NS сервера.
Для этого выбираете домен и заходите в его учетную запись — здесь можете указать существующие NS другого хостера либо кликнуть по ссылке «управление DNS». Во втором случае сможете задать A, MX и все необходимые записи для домена и использовать бесплатные NS от getnic.name.
tods-blog.com.ua
Я новичок в webservices, я пытаюсь вызвать webservice с soapClient() и генерирует XML-запрос запроса, который не находится в ожидаемом формате
Ниже представлен формат запроса XML
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <ns2:EndUserRequest xmlns:ns2="http://www.example.net/EndUserRequest"> <ns2:companyCode>MD</ns2:companyCode> <ns2:customerBranch>60</ns2:customerBranch> <ns2:customerNumber>112946</ns2:customerNumber> <ns2:endUserName>Some Name</ns2:endUserName> <ns2:ContactName /> <ns2:address /> <ns2:city /> <ns2:state /> <ns2:postalCode /> <ns2:email /> <ns2:phoneNumber /> <ns2:countryCode>US</ns2:countryCode> </ns2:EndUserRequest> </soapenv:Body> </soapenv:Envelope>
Ниже представлен XML-запрос, генерирующий мой код
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://www.emaple.com/EndUserRequest"> <SOAP-ENV:Body> <ns1:EndUserRequest xmlns:ns1="http://www.example.net/EndUserRequest"> <companyCode>MD</companyCode> <customerBranchNumber>360</customerBranchNumber> <customerNumber>53494711</customerNumber> <endUserName>ABCED</endUserName> <ContactName></ContactName> <address></address> <city></city> <state></state> <postalCode></postalCode> <email></email> <phoneNumber></phoneNumber> <countryCode>US</countryCode> </ns1:EndUserRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Ниже мой код
$client = new SoapClient('https://api-beta.example.com:443/enduser/v1/enduserlist?wsdl', array( "trace" => 1, "stream_context" => stream_context_create($streamContext), 'cache_wsdl' => WSDL_CACHE_NONE )); $endUserRequest = new stdClass; $endUserRequest->companyCode = 'MD'; $endUserRequest->customerBranchNumber = '560'; $endUserRequest->customerNumber = '59471321'; $endUserRequest->endUserName = 'Somename'; $endUserRequest->ContactName = ''; $endUserRequest->address = ''; $endUserRequest->city = ''; $endUserRequest->state = ''; $endUserRequest->postalCode = ''; $endUserRequest->email = ''; $endUserRequest->phoneNumber = ''; $endUserRequest->countryCode = 'US'; $requestSoapVar = new SoapVar($endUserRequest, SOAP_ENC_OBJECT,null,null,'EndUserRequest','http://www.example.com/EndUserRequest'); $res = $client->GetEndUsers($requestSoapVar); echo '<textarea style="width:600px;height:500px">'; echo "n-------Request Header------n"; echo $client->__getLastRequestHeaders(); echo "n-------Request------n"; echo $client->__getLastRequest(); echo "n-------Response Header------n"; echo $client->__getLastResponseHeaders(); echo "n-------Response------n"; echo $client->__getLastResponse(); echo '</textarea>'; echo '<textarea style="width:600px;height:500px">'; print_r($res); echo '</textarea>'; qaru.site
Во время регистрации доменного имени Вам будет предложено прописать адреса DNS серверов посредством NS записей для регистрируемого домена. Эти адреса Вы получите у своего хостинг-провайдера при покупке хостинга. Если вы еще этого не сделали, то Вы можете либо пропустить этот шаг и прописать адреса позже, либо прописать адреса DNS серверов, предоставляемых регистратором. Например, для домена test.ua NS записи могут выглядеть следующим образом: ns1.test.ua., ns2.test.ua. (обязательно ставьте точку в конце неймсервера).
Обратите внимание, что регистрация домена UA невозможна без заранее прописанных NS записей.
Записей NS должно быть минимум две, первая запись будет ссылаться на первичный DNS сервер (Primary), где будет расположен мастер-файл зоны, а остальные — на вторичный сервер (secondary), где будут храниться копии DNS записей.
Важно чтобы первичный и вторичный DNS сервера не находились на одном физическом сервере, а еще лучше чтобы сервера были разнесены территориально по странам (например, первичный — в США, вторичный — в Украине). Это необходимо для обеспечения надежной работы вашего сайта. Если вдруг первичный сервер выйдет из строя, то ваш сайт будет доступен пользователям благодаря резервным записям на вторичном сервере.
Рассмотрим пример, когда клиент заказывает у нас услугу регистрации домена test.ua. При этом у него уже есть необходимый сайт, который захостен на сервере в США, использоваться будет почтовый сервер Google, а субдомен forum.test.ua захостен на сервере в Голландии.
Во время регистрации домена ему присваиваются две NS записи для наших серверов (если другого не пожелает клиент): ns1.skydns.net и ns2.skydns.net.
В панели управления доменом это выглядит следующим образом:
Каждая из этих записей ссылается на разные NS сервера. Например, запись ns1.skydns.net ссылается на сервер в США, ns2.skydns.net — на сервер Великобритании. Такое расположение серверов практически полностью исключает возможность взлома Ваших DNS записей, если злоумышленнику удастся взломать один сервер (что маловероятно), то Ваш сайт по-прежнему будет функционировать.
Большой плюс также в том, что DNS записи не расположены на том же сервере, где находится сайт клиента. Это значит, что, если клиенту понадобится переместить сайт на другой хостинг, ему не придется переносить записи на новый DNS сервер, достаточно будет только изменить IP адрес в существующих DNS записях. Все записи легко редактируются через панель управления в личном кабинете пользователя.
Допустим, что сервер в США, где находиться сайт клиента, имеет IP адрес 1.1.1.1, сервер с субдоменом forum.test.ua имеет IP адрес 2.2.2.2, почтовый сервер зарегистрирован в Google (все интересующие Вас данные можно узнать у выбранного Вами хостинг-провайдера).
Для правильной работы следует настроить DNS записи на каждом DNS сервере следующим образом.
- A-запись:
- MX-запись: цифрой обозначен приоритет, чем меньше значение, тем большее приоритет
Такой способ расположения ресурсов служит для увеличения безопасности. Если злоумышленнику удастся взломать сервер, где расположен Ваш сайт, Вы не потеряете контроль над почтой и субдоменами, c помощью которых без проблем сможете предупредить своих посетителей и/или клиентов, о том что Ваш сайт взломали, но вскоре он будет восстановлен. Для возможности восстановления Ваших данных надежные хостинг-провайдеры, как мы предоставляют, услугу бэкапа (резервирования) информации.
unihost.com
Контра, кстрайк, КС, CS — сокращенные названия игры Counter Strike.
Config (Конфиг) — набор параметров, который позволяет оптимально настроить cs для комфортной игры; предполагает использование переменных вместе с алиасами;
индивидуален для каждого игрока.
Сonnect (коннект) — соединение с сервером.
Ping (Пинг) — скорость обмена (задержка) информации с сервером (чем меньше пинг, тем лучше связь).
TT, Теры — Terrorists (команда террористов).
CT, КТ, Менты, контры — Counter-Terrorists (команда контр-террористов).
Spectrator (Спектатор) — наблюдение за игрой без участия в ней.
Enemy (Энеми) — Противник.
Teamplay (тимплей) — командная игра.
Фраг — убитый вами враг, количество фрагов и смертей записывается в таблицу и определяется ваше место в команде.
Консоль — командная строка, вызываемая в игре клавишей тильда "~".
Мап, Мапа, Map — карта в Counter Strike.
Demo (Демка) — записанный в специальный файл игровой процесс отдельного игрока или всей игры, с ее помощью можно разоблачать читеров.
Resp, Respawn, респа — место появления команд террористов и контр-террористов.
Отец, папа, ♥♥♥♥♥♥♥♥♥♥♥♥ — крутой игрок.
Clan (клан) — команда, состоящая из 2х и более игроков (максимум для игры 5).
Clan War (клан вар), cw — война кланов, играют одна команда против другой.
Skill (Скилл) — игровое умение игрока, включающее в себя все характеристики, свойственные профессиональному игроку, такие как: скорость реакции, высокий уровень владения оружием, быстрая оценка ситуации и многое другое.
Aim — характеристика игрока, позволяющая ему быстро и безошибочно целиться в любое требуемое место на теле противника (по умолчанию – в голову) и наносить максимально-возможный урон за минимально-возможное время.
Cheater (читер) — игрок, использующие специализированные программы, которые дают ему явные преимущества перед другими игроками.
Aimbot (Aim) — чит, наделяющий вас невероятной точностью (по умолчанию – в голову).
WH, Wallhack — чит, который позволяет смотреть через стены, палится многими серверами и античитами, использовать не рекомендуется, чтобы не испортить себе репутацию.
Anti-Cheats (Античит) — программа, отслеживающая (запрещающая) использование читов.
Headshot (хэдшот) — попадание в голову насмерть.
Camper (кемпер) — игрок, отсутствующий в зоне активных действий вне связи с выполнением командного задания,играющий сам за себя, никому не помогает, прячется за ящиками, стенами и других местах и убивает врагов.
Уши — наушники.
Leaver, Ливер — Игрок, покидающий игру до её логичного завершения. Обычно так называют людей, которые специально выходят из игры, когда начинают проигрывать.
LS (Low Skill) — низкий уровень игры.
MS (Middle Skill) — средний уровень игры.
HS (Hight Skill) — высокий уровень игры.
PS (Pro Skill) — уровень игры Pro.
Bots (боты) — компьютерные игроки.
Noob (Нуб), lamer(Ламер) — начинающий игрок, играющий плохо.
Meat, Bot, Farsh, bomj (мясо, бот, фарш, бомж) — синонимы к слову Noob, но более оскорбительные для игрока.
Random (рандом) — ситуация, когда человек, зажимающий спуск при стрельбе, т.е. стреляющий зажимом очень длинными очередями практически наугад, случайно попадает в голову противника.
Чекать — кратковременное проглядывание территории на присутствие врага.
Rush (раш) — быстрое перемещение с респа до заданной точки. Характеризуется полным игнорированием действий противника.
Аркадник — игрок, играющий на внезапность, т.е. один выбегает в опасную зону, которая контролируется врагами.
Def / Hold — защита указанного участка карты, тактика игры "от обороны" / убийство аркадников.
Lag (Лаг) / Баг — плохой коннект / ошибки игры(карты).
Splash (сплеш) — непрямое повреждение, когда снаряд наносит повреждение взрывной волной.
Strafe (стрейф), стрейфится — перемещаться боком, удерживая цель перед "глазами".
Up — подсадка
Device (девайс) — одно из принятых обозначений оружия в Counter-Strike.
Burst — стрельба по несколько патронов.
Plant (Плэнт), bmb (Бомба) — взрывное устройство, которое должно быть доставлено на бомб-плейс террористами.
Bomb Place (Бомб-плэйс), plant (плэнт) — место для закладки бомбы террористами на картах типа "de_".
HE, ХаЕ — осколочная граната.
Fb (флеш, флешка) — ослепляющая граната.
Smoke (смок), дым — дымовая граната.
steamcommunity.com
Здесь мы обсуждаем вопросы применения записи описания ресурсов NS (Name Server). Подробно разбираем вопрос некорректного делегирования зон, а также алгоритм выбора наиболее подходящего авторитативного сервера для обслуживания запросов к зоне.
Запись NS используется для обозначения сервера, который поддерживает описание зоны. Собственно, когда resolver обращается к системе доменных имен за IP-адресом или доменным именем, то, скорее всего, он получит для начала NS-запись, которая будет указывать на сервер доменных имен, который знает где можно получить необходимую информацию. Именно этот отклик и называют рефералом или отсылкой.
Кроме того, запись NS позволяет делегировать поддомены, поддерживая тем самым иерархию доменов системы доменных имен Internet. Для того, чтобы домен был виден в сети в зоне описания домена старшего уровня должна быть указана запись типа NS для этого поддомена. Формат записи NS можно записать в виде:
[domain][ttl] IN NS [server]
В поле domain указывается имя домена, для которого сервер, указанный последним аргументом записи NS, поддерживает описание зоны. Значение поля ttl обычно оставляют пустым, тем самым, заставляя named устанавливать значение по умолчанию (поле minimum из записи SOA для данной зоны в старых версиях BIND или значение директивы управления $TTL).
При указании имени сервера следует иметь в виду следующие обстоятельства: если в качестве сервера указывается сервер из текущей зоны, то можно обойтись только неполным именем хоста, не указывая полное доменное имя, т.к. имя может быть расширено именем домена, но это скорее исключение, чем правило.
Записи NS указывают как на master, так и на slave серверы. Последние, обычно, принадлежат другим зонам, и для них следует указывать полное доменное имя сервера с указанием имени машины и имени зоны. Например, для сервера из домена polyn.kiae.su c именем ns следует писать полностью ns.polyn.kiae.su. Для того чтобы придерживаться какого-то единого стиля и во избежание ошибок, рекомендуется писать всегда полное имя сервера.
Какой либо разницы между master и slave в NS не указывается. Обычно primary master записывают первым, а резервные серверы указывают вслед за ним.
Приведем пример записи описывающей сервер доменных имен для поддомена:
$ORIGIN vega.ru.
zone1 IN NS ns.zone1.vega.ru.
В данном примере в качестве первой строки используется команда $ORIGIN, которая определяет имя текущей зоны (см. материал «Файлы описания зоны. Директивы управления»). Здесь она введена только для того, чтобы определить текущую зону.
В поле имени зоны указано имя zone1 без точки на конце. В данном контексте это означает делегирование зоны в домене vega.ru, полное имя которой будет zone1.vega.ru.
В качестве имени сервера, который управляет делегированной зоной указано имя ns.zone.vega.ru, т.е. полное имя машины в делегированном домене. В принципе, в данном случае можно было бы написать и по другому:
$ORIGIN vega.ru.
zone1 IN NS ns.zone1
т.к. имя принадлежит текущему домену и может быть расширено его именем.
В этом месте, видимо, следует обратить внимание на тот факт, что для записи доменных имен и имен зон существуют не только синтаксические ограничения, о которых упоминалось в материале «Правила именования хостов», а также при описании записи SOA, но и численные ограничения.
Длина метки узла дерева доменных имен должна находится в пределах от 1 до 63 октетов (RFC 2181). Любопытно, что написано не «символов», а октетов, то бишь байтов.
При этом длина полного имени (Full Qualified Doman Name -FQDN) не должна превышать 255 октетов, включая разделители ( те самые символы «.», которые ставятся между именами меток узлов). Полное имя узла — это имя от узла до корня дерева доменных имен.
Таким образом, максимальное имя корпоративного домена в зоне ru (что-то типа «corporative-name.ru») не может быть больше 63 символов, а вместе с двумя точками и «ru» не должно превышать 67 символов.
Теперь вернемся к NS записям. NS-записи обычно следуют сразу за записью SOA в файле описания зоны и указывают на серверы, которые ответственны за эту зону:
$ORIGIN ru.
Webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. (
1 3600 600 86400 3600 )
3600 IN NS ns.webstatistics.ru.
3600 IN NS ns4.nic.ru.
В данном случае описана зона webstatistics.ru и для нее вслед за SOA указано два сервера доменных имен: ns.webstatistics.ru — primary master и ns4.nic.ru — slave.
Такого простого указания на серверы доменных имен зоны для нормальной работы недостаточно. Нужно еще знать IP-адреса этих серверов. Для slave его можно найти в зоне nic.ru, а вот для ns.webstatistics.ru нужно использовать «приклеенную» адресную запись (см. подробнее материал «Адресная запись «Address». Балансировка нагрузки. Round Robin. Учет топологии сетей.»).
Рассмотрим еще одну причину использования NS-записей в описаниях зон — делегирование зоны.
До сих пор мы рассматривали NS запись только для объявления сервера доменных имен для той зоны, которую описываем, например, zone.ru:
@ IN SOA ns.zone.ru. hostmaster.zone.ru. (
2002092602 1d 3h 4w 3h )
IN NS ns.zone.ru.
IN NS ns.provider.ru.
Но это только часть функций NS записи. Теперь делегируем право ответственности за часть зоны другому администратору и выделяем в домене zone.ru зону subzone1. Этот факт мы должны отобразить в описании зоны zone.ru:
@ IN SOA ns.zone.ru. hostmaster.zone.ru. (
2002092602 1d 3h 4w 3h )
IN NS ns.zone.ru.
IN NS ns.provider.ru.
ns IN A 192.168.0.1
;
subzone1 IN NS ns.subzone1.zone.ru.
IN NS ns.zone.ru.
ns.subzone1 IN A 192.168.1.1
В данном случае имя subzone1 будет расширено именем текущей зоны (zone.ru), т.к. оно не завершается символом «.», а текущим является zone.ru, которое берется из файла конфигурации named потому, что указан символ «@» в записи SOA описания зоны.
На то, что subzone1 — это имя поддомена, указывает запись NS, потому, как у нее первое поле принимает значение имени домена (зоны).
При этом для зоны subzone1.zone.ru определено два авторитативных сервера: ns.subzone1.zone.ru и ns.zone.ru. Теперь, если к нашему серверу обратятся за адресом хоста из subzone1.zone.ru, то отошлем их к другим серверам, которые ответственны за эту зону.
Фраза «отошлем к другим серверам» означает то, что наш сервер вернет запрашивающему его клиенту или серверу, который выполняет рекурсивный запрос, имена и, если в зоне они прописаны, IP-адреса серверов доменных имен, ответственных за зону, где находится хост с заданным клиентом именем или адресом.
Понятно, что кроме нас адреса сервера домена, расположенного ниже в иерархии доменных имен, чем наш домен, никто не знает, поэтому в нашей зоне и содержится «приклеенная» адресная запись для соответствующего сервера:
ns.subzone1 IN A 192.168.1.1
Если внимательно присмотреться к описанию этого примера, то становится ясно, что наш сервер никуда никого отправлять не будет, т.к. он сам является авторитативным для зоны subzone1.zone.ru. Скорее всего, он является slave-ом, а ns.subzone1.zone.ru — это master.
Просто мы имеем еще один файл описания зоны, который копируем с ns.subzone1.zone.ru, и где находится описание зоны subzone1.zone.ru.
Подобная ситуация довольно типична, если клиенты провайдера используют его же сервер доменных имен в качестве slave, или если внутри организации происходит делегирование зон отдельным подразделениям. В первом случае выполняется условие независимого подключения, а во втором, т.к. домен находится ниже второго (корпоративного уровня), требования независимого подключения соблюдать хоть и желательно, но вовсе необязательно.
Теперь, когда понятна процедура делегирования зоны, вернемся к NS записям, описывающим серверы нашей зоны в нашем же описании зоны, а не там, где нам эту зону (нашу зону) делегировали.
С нашим сервером проблем не возникает. Мы сами его администрируем. А вот с администраторами серверов, которые (серверы) мы прописываем в зоне в качестве авторитативных, следует сначала договориться. Не нужно прописывать имена серверов «от балды». Эти серверы должны быть действительно slave для вашей зоны. Как правило, при регистрации домена проверяются все серверы, указанные в заявке.
Вообще говоря, по идее, неправильное указание имени сервера авторитативного за зону внутри описания самой этой зоны не должно влиять на работу других серверов. BIND не проверяет соответствие серверов в родительской зоне и в зоне-потомке. Другое дело неправильное делегирование (lame delegation), когда сервер родительской зоны перенаправляет клиента к серверу, который не является авторитативным для зоны-потомка.
В нашем случае, например, сервер ns.zone.ru может быть не настроен в качестве slave для зоны subzone1.zone.ru. Тогда ряд запросов может быть отвергнут, что, конечно, плохо.
Еще раз подитожим, что под некорректным делегированием понимают:
- наличие NS-записи, в которой указано имя сервера доменных имен, чей адрес невозможно найти;
- наличие NS-записи, в которой указано имя сервера доменных имен, не отвечающего на запросы;
- наличие NS-записи, в которой указано имя сервера доменных имен, негативно отвечающего на запросы.
На самом деле проблема некорректного делегирования достаточно серьезна. Так, например, Men&Mice в августе 2002 провела исследование 5000 случайно выбранных доменов в зоне com. Некорректное делегирование зоны было выявлено в 20% случаев. Это на один процент лучше, чем было в мае 2002 года, но все равно достаточно много. Любопытно, что в 14% случаев информация о делегировании зоны не совпадала с данными, указанными в самой зоне, а 17% случаев не удалось найти авторитативных серверов зоны.
Вообще говоря, проблема некорректного делегирования имеет решение, если сервер родительской зоны поддерживает механизм зон-заглушек (stub zone). Этот реализован в современных версиях BIND. Он позволяет серверу родительской зоны отслеживать изменения NS-записей делегированной зоны.
Для создания stub зоны следует в файл конфигурации named добавить:
zone «webstatistics.ru» {
type stub;
file «webstatistics.ru»;
masters {144.206.192.60;};
}
В этом случае сервер, на котором организована stub зона будет срисовывать в соответствующий файл запись SOA и NS-записи описания зоны.
Пусть описание зоны будет иметь вид:
$ORIGIN ru.
Webstatistics 3600 IN SOA webstatistics.ru. paul.webstatistics.ru. (
1 3600 600 86400 3600 )
3600 IN NS ns.webstatistics.ru.
3600 IN NS ns4.nic.ru.
IN A 144.206.192.60
$ORIGIN webstatistics.ru.
ns 3600 IN A 144.206.192.60
$ORIGIN nic.ru.
ns4 IN A 194.226.96.8
$ORIGIN webstatistics.ru.
www 3 IN A 144.206.192.60
3 IN A 144.206.192.61
3 IN A 144.206.192.62
3 IN A 144.206.160.32
Содержание файла типа stub на для зоны webstatistics.ru будет иметь следующий вид:
; BIND version named 8.2.2-P5-NOESW Mon Mar 20 20:39:05 GMT 2000
; BIND version root@monster.cdrom.com:/usr/obj/usr/src/libexec/named-xfer
; zone ‘webstatistics.ru’ first transfer
; from 144.206.192.60:53 (local 144.206.160.32) using AXFR at Mon Oct 7 19:31:1
; 7 2002
$ORIGIN ru.
Webstatistics 3600 IN SOA ns.webstatistics.ru. paul.webstatistics.ru. (
1 3600 600 86400 3600 )
3600 IN NS ns.webstatistics.ru.
3600 IN NS ns4.nic.ru.
$ORIGIN webstatistics.ru.
ns 3600 IN A 144.206.192.60
; Ignoring info about ns4.nic.ru, not in zone webstatistics.ru.
; $ORIGIN nic.ru.
; ns4 60575 IN A 194.226.96.8
Из этого примера хорошо видно, что в зону были скопированы записи SOA, NS и «приклеенные» адресные записи. При этом адресная запись для slave сервера была проигнорирована, т.к. она принадлежит другой зоне и в ней нет необходимости (подробнее см. материал «Адресная запись «Address». Балансировка нагрузки. Round Robin. Учет топологии сетей.»).
На самом деле есть одна загвоздка, которая делает указанный выше метод не достаточно удобным. Дело в том, что серийный номер родительской зоны не изменяется и, следовательно, slave-ы родительской зоны об изменениях в делегировании ничего знать не будут, если на них не настроить поддержку stub зоны.
В документации по BIND версии 9 не рекомендовано использовать зоны-заглушки для вновь создаваемых зон. Разработчики BIND советуют просто строго следовать правилам делегирования зоны.
При делегировании зоны нужно четко отдавать себе отчет в том, что администраторы делегированного домена не обязаны сообщать нам адрес primary master, т.е. того сервера, на котором происходит реальное редактирование информации о зоне. Они (администраторы) могут просто сообщить нам адреса своих slave серверов, которые тоже являются авторитативными для зоны. В этом случае мы будем иметь невидимый primary master сервер. Делается это, главным образом, из соображений безопасности.
На самом деле, остался не выясненным еще один вопрос, который тесно увязан с авторитативными серверами доменных имен. Это вопрос о порядке их опроса локальным сервером доменных имен, который выполняет рекурсивный запрос resolver-а.
На самом деле все достаточно просто. Когда сервер получает рекурсивный запрос, и в итоге опроса серверов доменных имен в конце концов получает список авторитативных серверов требуемой зоны, он для каждого из них включает метрику RRT (round trip time). Эта метрика в миллисекундах измеряет время отклика от каждого из серверов. В начальный момент времени, т.е. при первом запросе, она устанавливается в 0.
Сначала берется первый сервер, и отклик получается от него. Метрика этого сервера увеличивается, следовательно при повторном обращении к авторитативным серверам зоны наш сервер, который выполняет рекурсивный запрос, обратится уже к другому серверу зоны. После опроса всех серверов, наш сервер будет обращаться к тому, у которого метрика RTT меньше.
Наиболее эффективен этот алгоритм при работе с корневыми серверами,т.к. к ним приходится обращаться постоянно.
Следует заметить, что серверы, отличные от BIND могу реализовывать другие алгоритмы выбора сервера, т.к. в спецификации DNS этот вопрос не прояснен.
Любопытно, что измерения RTT для корневых серверов проведенные в 2000 году, хорошо совпали с RTT команды ping. Не обобщая этот вывод на все случае жизни, тем не менее можно сказать, что доступность DNS сервера можно оценивать по скорости отклика ping.
Вообще говоря, описанный алгоритм выбора аторитативного сервера на основе RTT не догма и его эффективность постоянно подвергается оценке. Основной вопрос, на который хотят получить ответ службы поддержки корневых серверов- это почему основная нагрузка падает на A сервер, в то время как ближайший к нему M сервер имеет нагрузку почти на четверть меньшую.
Рекомендованная литература:
- P. Mockapetris. RFC-1034. DOMAIN NAMES — CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
- P. Mockapetris. RFC-1035. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
- Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.
- Документация по BIND 9. Справочное руководство системного администратора. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
- 5. R. Elz, R. Bush. RFC-2181. Clarifications to the DNS Specification. 1997. (http://www.ietf.org/rfc/rfc2181.txt?number=2181)
Полезные ссылки:
- http://www.menandmice.com/6000/61_recent_survey.html — результаты исследования Men&Mice по проблемам делегирования зон. Август 2002 года.
- http://www.dns.net/dnsrd/trick.html#which-server-queried — FAQ. Описание алгоритма выбора сервера среди авторитативных серверов зоны на основе RTT.
- http://www.caida.org/projects/dns-analysis/#logfile — анализ нагрузки корневых серверов и исследование эффективности алгоритма выбора сервера.
- http://www2.auckland.ac.nz/net/Internet/rtfm/meetings/47-adelaide/pp-dist/ — материал 2000 года, в котором подмечено совпадение RTT DNS и ping.
info.nic.ru
Как это работает система DNS?
Когда вы набираете в браузере доменное имя MYDOMAIN.COM, ваш компьютер для первым делом обращается к DNS-серверу, указанному в настройках вашего соединения с интернетом. DNS-сервер нужен для того, чтобы преобразовать запрошенное доменное имя в IP-адрес.
DNS-сервер обращается к одному из корневых NS-серверов интернета, ip-адреса которых жестко заданы и известны и в ответ Корневой сервер отдает DNS-серверу список ip-адресов серверов, на которых расположена зона .COM Выглядит этот список примерно так:
a.gtld-servers.net. 160060 IN A 192.5.6.30 a.gtld-servers.net. 160060 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 160060 IN A 192.33.14.30 b.gtld-servers.net. 160060 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 160060 IN A 192.26.92.30 d.gtld-servers.net. 160060 IN A 192.31.80.30 e.gtld-servers.net. 160060 IN A 192.12.94.30 f.gtld-servers.net. 160060 IN A 192.35.51.30 g.gtld-servers.net. 160060 IN A 192.42.93.30 h.gtld-servers.net. 160060 IN A 192.54.112.30 i.gtld-servers.net. 160060 IN A 192.43.172.30 j.gtld-servers.net. 160060 IN A 192.48.79.30 k.gtld-servers.net. 160060 IN A 192.52.178.30 l.gtld-servers.net. 160060 IN A 192.41.162.30 m.gtld-servers.net. 160060 IN A 192.55.83.30
DNS-сервер обращается к одному из NS-серверов зоны .COM (Допустим, a.gtld-servers.net — 192.5.6.30) и запрашивает список NS-серверов для домена MYDOMAIN.COM. Эти NS-сервера называются NS-серверами, на которые делегирован домен.
ns1.mydomain.com. 172800 IN A 66.96.142.148 ns2.mydomain.com. 172800 IN A 65.254.254.172 ns3.mydomain.com. 172800 IN A 66.96.142.146 ns4.mydomain.com. 172800 IN A 65.254.254.170
После чего обращается к одному из полученного списка NS-серверов и запрашивает уже информацию относительно домена MYDOMAIN.COM. Пример ответа:
mydomain.com. 3248 IN MX 0 mail.mydomain.com. mydomain.com. 86048 IN TXT "v=spf1 ip4:38.113.1.0/24 ip4:38.113.20.0/24 ip4:12.45.243.128/26 ip4:65.254.224.0/19 ?all" mydomain.com. 2208 IN SOA ns1.mydomain.com. hostmaster.mydomain.com. 1335787408 16384 2048 1048576 2560 mydomain.com. 248 IN A 65.254.242.180 mydomain.com. 1448 IN NS ns3.mydomain.com. mydomain.com. 1448 IN NS ns2.mydomain.com. mydomain.com. 1448 IN NS ns4.mydomain.com. mydomain.com. 1448 IN NS ns1.mydomain.com. ;; AUTHORITY SECTION: mydomain.com. 1448 IN NS ns3.mydomain.com. mydomain.com. 1448 IN NS ns4.mydomain.com. mydomain.com. 1448 IN NS ns2.mydomain.com. mydomain.com. 1448 IN NS ns1.mydomain.com. ;; ADDITIONAL SECTION: ns1.mydomain.com. 167564 IN A 66.96.142.148 ns2.mydomain.com. 167564 IN A 65.254.254.172 ns3.mydomain.com. 126551 IN A 66.96.142.146 ns4.mydomain.com. 126551 IN A 65.254.254.170
DNS-сервер отдает вашему компьютеру полученную информацию и он обращается к нужному IP-адресу. Но, как мы видим, здесь достаточно много разнообразной информации. Рассмотрим все подробнее.
Что такое делегирование домена
Делегированием домена называется передача корневым сервером зоны права размещения домена на определенном NS-сервере. Для примера, корневые сервера ДЕЛЕГИРУЮТ зону .COM на серверы, которые будут за нее отвечать, а серверы зоны .COM ДЕЛЕГИРУЮТ домен MYDOMAIN.COM на NS-сервера хостинг-провайдера или на какие-либо другие. Само делегирование означает, что на корневом сервере для домена присутствуют записи IN NS, указывающие на NS-сервер, на котором размещена информация по домену. Обратите внимание, делегирование предполагает наличие ТОЛЬКО записей IN NS и никаких других. Поэтому домену второго уровня нельзя прописать, к примеру, запись CNAME.
Что такое дочерние NS-серверы
Иногда NS-серверы для домена находятся на его поддоменах. В вышеприведенном примере домен MYDOMAIN.COM делегирован на NS-серверы ns1.mydomain.com, ns2.mydomain.com и т.д. Как же это возможно? Ведь чтобы обратиться к этим NS-серверам нужно узнать их ip-адрес. Все просто — корневой сервер зоны .COM при таком варианте требует указания не только доменных имен NS-серверов, но и их ip-адресов. Поэтому DNS-сервер знает, куда обратиться за подробностями. Рассмотрим пример двух доменов — с дочерним NS-сервером и без: NS-запись у домена diphost.ru
;; ANSWER SECTION: diphost.ru. 292 IN NS ns1.bz8.ru.
NS-запись у домена bz8.ru
;; ANSWER SECTION: bz8.ru. 300 IN NS ns1.bz8.ru. ;; ADDITIONAL SECTION: ns1.bz8.ru. 95617 IN A 185.35.220.5 ns1.bz8.ru. 95617 IN AAAA 2a00:e460:2a00:c01d::9:aaaa
Как видите, все просто. Такая настройка у зарубежных регистраторов называется Child NameServers
Какие бывают NS-записи для домена
NS-запись — указывает, на каких NS-серверах находится домен. Эта запись должна повторять значения для домена, находящиеся на корневых серверах зоны. Только в этом случае домен будет ДЕЛЕГИРОВАН.
mydomain.com. 1448 IN NS ns3.mydomain.com.
A-запись — указывает IPv4 адрес сервера, к которому нужно обратиться по доменному имени. A-записей у домена может быть несколько. В этом случае выбирается случайный.
mydomain.com. 248 IN A 65.254.242.180
AAAA-запись — указывает на IPv6 адрес сервера. Также, эта запись иногда упоминается как Квадра-А (четыре А)
MX-запись — указывает на ip-адрес или доменное имя сервера, отвечающего за прием почты на этот домен (MX-сервер). В нашем примере, вся почта на любой адрес домена MYDOMAIN.COM будет поступать на сервер mail.mydomain.com.
mydomain.com. 3248 IN MX 0 mail.mydomain.com.
MX-записей тоже может быть несколько. MX-запись кроме имени сервера также имеет поле «Приоритет». Оно указывает, в каком порядке нужно обращаться к MX-серверам домена. Чем меньше значение приоритета, тем приоритетнее сервер.
TXT-запись — Сюда записывают различную служебную информацию, для которой нет выделенных полей. Можно записать контактные данные администратора, или что угодно. TXT-записи также используются для хранения SPF и DKIM записей, использующихся для защиты от спама.
mydomain.com. 86048 IN TXT "v=spf1 ip4:38.113.1.0/24 ip4:38.113.20.0/24 ip4:12.45.243.128/26 ip4:65.254.224.0/19 ?all"
CNAME-запись — служит для указания, что домен является синонимом (алиасом) другого домена. По этой же причине, у домена с записью CNAME не может быть никаких других записей.
SOA-запись — генерируется автоматически NS-сервером и содержит служебную информацию: адрес электронной почты ответственного за NS-сервер, дату и время последнего обновления домена, предельное время кеширования зоны (TTL) и т.д.
SRV-запись — служит для хранения адресов различных серверов, обслуживающих домен. Обычно они не совпадают с адресом web-сервера, указанного в A-записи и, как и MX-сервер, расположены на других адресах. В эту запись можно добавить адреса JABBER, TeamSpeak серверов и т.д.
Общие правила оформления записей на NS-сервере
Если в записи указано доменное имя, оно должно заканчиваться точкой, иначе к нему будет приклеено имя основного домена. Т.е. если указать запись
mydomain.com. IN MX 10 mx.mail.ru
то MX-сервер домена будет определяться как mx.mail.ru.mydomain.com. Поэтому правильный вариант записи:
mydomain.com. IN MX 10 mx.mail.ru.
wiki.diphost.ru