DNS faq

BIND реализация NS-сервера мало-ресурсоемка, поэтому можно прикупить простенькие VDS-ы и там все поднять. Некоторые хостеры выдают несколько IP из разных сеток С-класса. И есть соблазн, на одном серваке сымитировать два NS-а (и тем самым сэкономить на втором VDS-е). Технически это реально (я видел такое), но я настоятельно не рекомендую. Ибо если ляжет VDS/Хостер/Провайдер, то лягут все эти DNS-ы со всеми вытекающими последствиями.

2) Для более стабильной работы желательно не просто из разных подсеток взять IP, а с разной (и качественной) "физикой", а то сетки то могут быть разные, но от одного провайдера и по тем же проводам. Услуга РуЦентра Secondary при большом числе доменов - дорогое удовольствие.

Если DNS-ы записи для всех доменов идентичны, то можно настроить, чтобы любые запросы выдавали идентичные DNS-записи. (Как это обычно сделано на ряде парковкок) .Если я правильно понял вопрос, то список ns-ов для вашего домена с услугой ру-центра будет выглядеть так:

ns1.ваш_домен

ns2.ваш_домен

ns4.nic.ru

ns8.nic.ru

Причем я бы выкинул ns2.ваш_домен так как смысла в нем нет, а

ру-центер дает на самом деле два secondary для вашего домена,

один из которых находится в амстердаме. Т.е. с точки зрения надежности

лучше не придумаешь. Даже если ляжет канал забугор домен будет резолвится.

Доменные Окончания

.ac – Ascension Island

.ad – Andorra

.ae – United Arab Emirates

.af – Afghanistan

.ag – Antigua and Barbuda

.ai – Anguilla

.al – Albania

.am – Armenia

.an – Netherlands Antilles

.ao – Angola

.aq – Antarctica

.ar – Argentina

.as – American Samoa

.at – Austria

.au – Australia

.aw – Aruba

.az – Azerbaijan

.ba – Bosnia and Herzegovina

.bb – Barbados

.bd – Bangladesh

.be – Belgium

.bf – Burkina Faso

.bg – Bulgaria

.bh – Bahrain

.bi – Burundi

.bj – Benin

.bm – Bermuda

.bn – Brunei Darussalam

.bo – Bolivia

.br – Brazil

.bs – Bahamas

.bt – Bhutan

.bv – Bouvet Island

.bw – Botswana

.by – Belarus

.bz – Belize

.ca – Canada

.cc – Cocos (Keeling) Islands

.cd – Congo, Democratic Republic of the

.cf – Central African Republic

.cg – Congo, Republic of

.ch – Switzerland

.ci – Cote d'Ivoire

.ck – Cook Islands

.cl – Chile

.cm – Cameroon

.cn – China

.co – Colombia

.cr – Costa Rica

.cu – Cuba

.cv – Cap Verde

.cx – Christmas Island

.cy – Cyprus

.cz – Czech Republic

.de – Germany

.dj – Djibouti

.dk – Denmark

.dm – Dominica

.do – Dominican Republic

.dz – Algeria

.ec – Ecuador

.ee – Estonia

.eg – Egypt

.eh – Western Sahara

.er – Eritrea

.es – Spain

.et – Ethiopia

.fi – Finland

.fj – Fiji

.fk – Falkland Islands (Malvina)

.fm – Micronesia, Federal State of

.fo – Faroe Islands

.fr – France

.ga – Gabon

.gd – Grenada

.ge – Georgia

.gf – French Guiana

.gg – Guernsey

.gh – Ghana

.gi – Gibraltar

.gl – Greenland

.gm – Gambia

.gn – Guinea

.gp – Guadeloupe

.gq – Equatorial Guinea

.gr – Greece

.gs – South Georgia and the South Sandwich Islands

.gt – Guatemala

.gu – Guam

.gw – Guinea-Bissau

.gy – Guyana

.hk – Hong Kong

.hm – Heard and McDonald Islands

.hn – Honduras

.hr – Croatia/Hrvatska

.ht – Haiti

.hu – Hungary

.id – Indonesia

.ie – Ireland

.il – Israel

.im – Isle of Man

.in – India

.io – British Indian Ocean Territory

.iq – Iraq

.ir – Iran (Islamic Republic of)

.is – Iceland

.it – Italy

.je – Jersey

.jm – Jamaica

.jo – Jordan

.jp – Japan

.ke – Kenya

.kg – Kyrgyzstan

.kh – Cambodia

.ki – Kiribati

.km – Comoros

.kn – Saint Kitts and Nevis

.kp – Korea, Democratic People's Republic

.kr – Korea, Republic of

.kw – Kuwait

.ky – Cayman Islands

.kz – Kazakhstan

.la – Lao People's Democratic Republic

.lb – Lebanon

.lc – Saint Lucia

.li – Liechtenstein

.lk – Sri Lanka

.lr – Liberia

.ls – Lesotho

.lt – Lithuania

.lu – Luxembourg

.lv – Latvia

.ly – Libyan Arab Jamahiriya

ma – Morocco

.mc – Monaco

.md – Moldova, Republic of

.mg – Madagascar

.mh – Marshall Islands

.mk – Macedonia, Former Yugoslav Republic

.ml – Mali

.mm – Myanmar

.mn – Mongolia

.mo – Macau

.mp – Northern Mariana Islands

.mq – Martinique

.mr – Mauritania

.ms – Montserrat

.mt – Malta

.mu – Mauritius

.mv – Maldives

.mw – Malawi

.mx – Mexico

.my – Malaysia

.mz – Mozambique

.na – Namibia

.nc – New Caledonia

.ne – Niger

.nf – Norfolk Island

.ng – Nigeria

.ni – Nicaragua

.nl – Netherlands

.no – Norway

.np – Nepal

.nr – Nauru

.nu – Niue

.nz – New Zealand

.om – Oman

.pa – Panama

.pe – Peru

.pf – French Polynesia

.pg – Papua New Guinea

.ph – Philippines

.pk – Pakistan

.pl – Poland

.pm – St. Pierre and Miquelon

.pn – Pitcairn Island

.pr – Puerto Rico

.ps – Palestinian Territories

.pt – Portugal

.pw – Palau

.py – Paraguay

.qa – Qatar

.re – Reunion Island

.ro – Romania

.ru – Russian Federation

.rw – Rwanda

.sa – Saudi Arabia

.sb – Solomon Islands

.sc – Seychelles

.sd – Sudan

.se – Sweden

.sg – Singapore

.sh – St. Helena

.si – Slovenia

.sj – Svalbard and Jan Mayen Islands

.sk – Slovak Republic

.sl – Sierra Leone

.sm – San Marino

.sn – Senegal

.so – Somalia

.sr – Suriname

.st – Sao Tome and Principe

.sv – El Salvador

.sy – Syrian Arab Republic

.sz – Swaziland

.tc – Turks and Caicos Islands

.td – Chad

.tf – French Southern Territories

.tg – Togo

.th – Thailand

.tj – Tajikistan

.tk – Tokelau

.tm – Turkmenistan

.tn – Tunisia

.to – Tonga

.tp – East Timor

.tr – Turkey

.tt – Trinidad and Tobago

.tv – Tuvalu

.tw – Taiwan

.tz – Tanzania

.ua – Ukraine

.ug – Uganda

.uk – United Kingdom

.um – US Minor Outlying Islands

.us – United States

.uy – Uruguay

.uz – Uzbekistan

.va – Holy See (City Vatican State)

.vc – Saint Vincent and the Grenadines

.ve – Venezuela

.vg – Virgin Islands (British)

.vi – Virgin Islands (USA)

.vn – Vietnam

.vu – Vanuatu

.wf – Wallis and Futuna Islands

.ws – Western Samoa

.ye – Yemen

.yt – Mayotte

.yu – Yugoslavia

.za – South Africa

.zm – Zambia

.zw – Zimbabwe Q.Вместо доменов в поиске присутствуют мои нс сервера - пример, мой сайт site.ru - открывается как сам по себе так и как ns1.server.ru.

В настройках виртуального хоста у вас присутствует звёздочка.
Например: ServerName *.example.com (ServerAlias *.example.com)

Если проблема именно эта, то написать имя хоста без звёздочки: "ServerName example.com".
Если этот виртуальный хост (example.com) у вас самый первых в конфигурации для этого IP-адреса (который общий для NS-а и для самого хоста), нужно добавить ещё один виртуальный хост-пустышку в самое начало конфига:
<VirtualHost IP-адрес:80>

ServerName *

</VirtualHost> Q: Есть сервер и контроллер домена W2KSerRus, в сети три сегмента 75, 77 и 79(сетевые карты на сервере). DNS настроен на контроллере домена, DHCP и маршрутизация настроены на сервере. Контроллер домена в сегменте 75. Из других сегментов его не видно, хотя ping и tracert проходят одинаково хорошо как по его имени, так и по IP-адресу. Соответственно пользователи не могут войти в домен, потому как "пароль не опознается контроллером домена". В сегменте 75 все нормально.

A: Чтобы пользователи из других сегментов могли присоединяться к домену нужно:

1. Адресом DNS у всех должен быть DNS контроллера домена.

2. Запускаешь на клиенте nslookup затем ls твой_домен.ру должны появиться записи «твой_домен.ру А» и «твой_домен.ру NS»

3. По уму нужно чтобы каждая подсеть была в своем пространстве адресов - одна 192.168.0.х, другая 192.168.1.х маска 225.255.255.0 тогда у первого сегмента должен стоять шлюзом адрес сет. карты сервера с их стороны - аналогично для второго сегмента. Q: При отключенном соединении сервера в Интернет половина сервисов Exchange не запускаются, но только при запуске компьютера. После загрузки запускаются вручную без проблем и быстро. Кроме того, не могу запустить оснастку Domain Security Policy, выдаётся что-то наподобие «The remote computer is not available». Эти проблемы пропадают, если для внешней карточки сделать Disable.

A: В настройке сети надо выбрать пункт меню Advanced -> Advanced Settings (Дополнительно-> Дополнительные параметры) и настроить приоритеты обращения к сетевым адаптерам. Q: При установке Win2K, когда пытаюсь добавить свой компьютер в домен ("Network Identification Wizard") выдается сообщение "The network path was not found".

A: Эта ошибка значит, что у тебя неправильно (как и было замечено ранее) определяются имена через ДНС.

Примечание: На самом деле в сети не было ни одного домена. Добавление в домен стало возможным после установки DNS на Windows 2000 Server. Q: Раньше у меня был WinNT40 и вся сеть работала в домене МММ, теперь установил Windows 2000 Server, затем при помощи службы DCPROMO. Создаю Primary Domain Controller, все вроде нормально, но постоянно в событиях ругается... Да и перезагрузка очень медленная стала... Помогите советом как правильно установить DNS?

A: DCPROMO переводит Windows 2000 из обычного сервера в статус доменного контроллера. Для того чтобы просто работала службы DNS это не обязательно ставить AD, но AD не может функционировать без DNS поэтому, если до установки AD не была установлена DNS, то она будет автоматически установлена. Можно ее не устанавливать, но тогда на другом доступном сервере сети все равно должна быть установлена служба DNS, причем она должна поддерживает динамическое обновление. Перезагрузка стала медленной из-за AD, однако что конкретно делает Windows 2000 после его назначения контролером домена остаётся загадкой. Q: Проблема в следующем, я получил доменное имя в своей зоне (kz), сканирую свой ИП, но эта зараза показывает только имя компьютера, да и то не всегда... А если сначала сканирую доменное имя, а потом ИП, все нормально срабатывает, в чем прикол не пойму, вроде все работает, кто встречался с подобным, поделитесь пожалуйста.

A: В DNS сервере неправильно настроена обратная зона. Q: Есть одна сеть физически, которая разделена логически на две сети. Первая 192.168.1.х - имеет свой контроллер домена Win2000Serv, DHCP, DNS. Все работает прекрасно. Вторая 192.168.10.х была одноранговая, с жёстко прописанными IP. После поднятия во второй сети контроллера домена Win2000Serv, DHCP, DNS все компьютеры (пользователи) первой сети стали получать с DHCP второй сети адреса второй сети при этом все они были нормально авторизированы контроллером 1-го домена. Вопрос сделать так что б раздача адресов с DHCP проходила только пользователям того домена к которому принадлежит пользователь и сам DHCP.

A: На DHCP сервере можно прописать "резервирование" для определенных MAC адресов карточек. а делается это примерно так:

1. на сервере создаешь диапазон адресов, который будешь выделять своим клиентам;

2. создаешь резервирование (для определенного МАС адреса прописываешь IP адрес);

3. остальные адреса, которые не используются - просто блокируй. Q: В Domain Security Policy поставил сервису computer browser - Disabled Дал Full Control только Domain Admins. Однако у всех пользователей он как стартовал так и стартует.

A: То что ты написал - это политика для контроллеров домена. А чтобы отключить определенные сервисы, в частности этот, на клиентских машинах воспользуйся групповой политикой - раздел USER. Q: Ситуация следующая: жил да был контроллер домена, все вроде было хорошо, но в один прекрасный момент он умер. Ну не то чтобы совсем, но грузиться не хочет - и восстановление не помогает - зависает на «Preparing network connections». Ну и на фиг его, слава богу другие есть - так ведь память о нем осталась. Помнят его другие жители домена. Так вот как бы так память о нем искоренить?

A: Детали - Q270842,Q266132 , а что самое вероятное - Q272262. Причем фикса нет пока (с ноября месяца)!!! А если вообще удалить - то просто:

1. Долой его из списка контроллеров в соответствующей оснастке.

2. Проверить не был ли он Master Operation? Если был, то надо сделать чтобы не был.

3. Ну и для очистки совести DNS почистить (в последнюю очередь). Q: Каким образом Win98 добавить в домен 2000?

A: Если в Win2K, то создать пользователя для Win98. Если в Win98, то нажать <свойства> "Клиент для сетей Microsoft", поставить галочку "входить в домен WinNT" и написать имя этого домена. Q: У меня вопрос следующего характера: Как на сервере под Windows 2000 Server завести типа локального пользователя, которому отрубить все возможности лазить по серверу, единственное что нужно предоставить право запускать антивирус и как положено завершать работу сервера, остального он нечего не должен видеть. Сервер стоит как контроллер домена, посмотрел в доках, создал пользователя как "оператора печати" стал ужимать его в правах на локальном компьютере, сам как администратор этого не вижу, при локальном входе система не пускает говорит интерактивный вход запрещен, короче не чего не понимаю, выходит на контроллере домена могут быть только одни администраторы и операторы? Разбираться на это нет времени ухожу в отпуск а сервер только что настроенный не охота оставлять - раздолбаем, в связи с чем SOS!!!

A: На контроллере домена НЕТ локальных пользователей и групп. Входить на него могут ТОЛЬКО доменные администраторы и операторы сервера. Если нет времени на разбирательства с политиками безопасности, то вот тебе мой совет включи возможность отключения сервера без регистрации в системе:

1. запускаешь MMC.exe

2. Open c:\winnt\system32\gpedit

3. Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Allow system to be shutdown without having to logon -> Enabled Антивирус запрограммируй на сканирование по расписанию. Q: Жили-были две локальных сети в разных концах города. И было у них по Win2k Advanced серверу у каждого. И AD тоже у каждого свое. И вот пробросили им туннель от одной локальной сети в другую. Все бы хорошо, но в сетевом окружении видно только компьютеры собственной локальной сети. А как сделать чтобы было видно обе сетки? Речь идет как раз об том, чтобы в сетевом окружении я видел DOMAIN1 и DOMAIN2 и если надо еще сто сорок три домена...

A: Скорее всего надо делать реструктуризацию доменов... То бишь один домен на двух контроллерах. Для реструктуризации доменов используется Active Directory Migration Tool (ADMT). Перенос происходит в три этапа:

1. Создание целевого домена обязательно в естественном режиме (так понимаю что этот домен уже есть).

2. Перенос объектов из исходного домена в целевой с помощью ADMT.

3. Уничтожение исходного домена. Q: У меня есть домен luxe-home.ru, одинаковый и для Интернета и для локальной сети. Как сделать домен типа temp.luxe-home.ru, чтобы он был виден из Интернета (из локальной сети проблем нет)?

A: Разумеется прописать домен на ns.rost.ru. или ns.rt.ru., смотря на котором из них primary зона. Зона для Интернета, находится на этих серверах прописанных в RIPN, соответственно на них и менять надо. Q: Подключил компьютер к домену, и на локальном компьютере создался новый профиль..., все те программы и настройки которые были у пользователя потерялись (то бишь остались на его профили с локальным подключением), как сделать так чтобы настроить его доменный профиль с определёнными настройками и программами? Так чтобы с любого другого компьютера он входил на свой доменный профиль и работал в окружении своих настроек и программ.

A: Если хочешь настройки со старого профиля перенести в новый, то просто скопируй содержимое старого профиля в новый (только для локального компьютера): c:\Documents and Settings\vasy\(all folders) -> c:\Documents and Settings\vasy.domain_1\(all folders) включая все скрытые папки типа Local Settings.

А вот работать с любого компьютера пользователю со всеми своими программами можно только в том случае, если ВСЕ компьютеры сети одинаковы (одно программное обеспечение). Но даже в этом случае остаётся такая проблема как личные файлы/настройки пользователя. В данном случае могу посоветовать вынести всё программное окружение пользователя в сеть, прописать конфигурационные файлы так, чтобы они сохранялись (и читались) тоже с сетевых папок (в случае массового выноса программ пользователей в сеть надо настроить, чтобы каждый пользователь работал скажем с диском М – но каждый раз там были только его программы – делается через winlogon.bat). Q: Я у себя дома на сетке (пока из 3 компьютеров) поставил Windows 2000 Server в качестве сервера. После объявления сервера как контроллера домена, установки DHCP, DNS, и т.д. При загрузке "инициализация сетевых компонентов" идет около 5 минут... Это нормально?

A: Данная ситуация вполне нормальна (все таки контроллеры домена нужно перезагружать не часто). Вот когда рядом стоят два контроллера, оба грузятся мгновенно, если только их обоих не перезагружаешь одновременно. Q: Такая вот проблема: есть Windows 2000 Server, есть AD. Есть домен - машины из Windows 98 заходят отлично - а вот из Windows 2000 Professional – ни в какую! В логах пишет, что сервер отклонил динамическую регистрацию DNS. Помогите не могу больше - как включить гостевой вход - пишет мол интерактивный вход запрещен - локальной политикой.

A: Гостевой вход включается элементарно: «Мой компьютер -> Управление -> Локальные пользователи и группы -> Пользователи -> Гость» где убери галочку «Учётная запись отключена» Но вместо того, что бы включать гостевой вход, лучше завести на компьютере пользователей твоей сети, и самому назначить их права на компьютере:

1. Сначала проверь что имеется в сетевых настройках «Клиент Microsoft» и «Протокол TCP/IP».

2. На сервере в DNS разрешаешь автоматическое обновление для всех.

3. На сервере прописываешь пользователей и включаешь их в группу «Пользователи домена». В управлении компьютером на сервере локальные пользователи естественно будут недоступны.

4. На клиенте ставишь в свойствах компьютера что этот компьютер состоит в домене. При этом потребуются имя и пароль Администратора. Запись автоматически занесется в раздел компьютера. Если там он уже есть, а компьютер не в домене - удали сам, а потом добавляй компьютер в домен. Q: Был создан дочерний домен, после различных экспериментов его убили. В Active Directory Doman and Trust осталась запись этого домена. Как эту запись убить?

A: Можно воспользоваться утилитой ntdsutil (metadata cleanup). Q: Стоял обычный сервер w2000RUS. Установил на него Active-Directory - и сделал Primary Domain Controller. После этого все нормально работает, кроме того, что с сервера не могу войти в распределённые ресурсы пользователей (win9X, WIN-NT). Говорит «не могу найти путь».

A: Вся проблема из-за DNS. Ты когда ставил AD, который DNS указал? Если тебе надо было создать контроллер домена только для локальной сети, тебе надо было указывать в AD адрес DNS 127.0.0.1, в этом случае сервер после запроса клиента будет смотреть у себя запись в DNS на имя клиента. А если ты указал какой-то внешний DNS, то, понятное дело, там таких клиентов нет, поэтому твой сервер и не отвечает клиентам. Попробуй в настройках сетевой карты убрать все DNS, он тебе скажет что DNS будет установлен локально (т.е. 127.0.0.1), затем выполнить такую команду «ipconfig /registerdns» после этого в DNS-консоли прописать все узлы. Ну а потом прописать всех в AD. Q: Помогите залогинить Win2KPro на Win2KServer Пишет , то что пользователь не доступен и нет какой то общей папки, показывает, что в домене нет такого логина.

A: Чтобы была возможность войти в домен нужно чтобы был доступен сервер DNS этого домена, т.е. клиентский компьютер мог распознать список IP адресов контроллера домена. Таким образом лучше всего прописать в настойках DNS компьютер, на котором установлена AD. Q: Проинсталлировал Win2K Advanced Server + SP2 и сделал его контроллером домена. Сервер находится в большой сети и смотрит в Интернет через местный шлюз. Все DNS сервера для него со внешними адресами. Поднял DNS на сервере локально с абсолютно "левым" именем зоны. Теперь при любом обращении к службам AD компьютер тормозит по минуте. Такое впечатление, что пытается постоянно разрешить DNS имена и у него это не получается. Поставил у него в DNS Properties переадресацию запросов на внешние сервера, но это не помогло.

A: То что входит в сеть долго - это потому что у тебя единственный контроллер домена, что неправильно - поставь второй будет входить быстро. То что открывается долго сетевое окружение… моя рекомендация – сделать следующее:

1. остановить соответствующий сервис на Windows 2000 Server, т.е. сделать запуск вручную;

2. сделать любой компьютер, который не выключается обозревателем сети - подправить реестр и перезагрузиться (как это сделать уже обсуждалось неоднократно).

Тестов DHCP не бывает, бывают тесты DNS. Если тесты DNS не проходят - значит она некорректно поставлена. Я рекомендую вообще самим DNS не ставить, а устанавливать ее во время установки AD после установки AD и перезагрузки нужно запустить ipconfig /registerdns. Q: Как перейти с рабочих групп на домены?

A: Во-первых конечно настроить контролер домена - это будет твой сервер. Войди в консоль настройка сервера, там тебе предложит настроить службы необходимые для функционирования домена(например AD), следуй инструкциям установщика. Q: Стоит ли покупать себе домен в Интернете и на его основе делать домен в организации? Вообще я хочу перейти с рабочих групп на домен потому, что мне объяснили, что так намного удобнее администрировать... мне надоело прописывать пользователей на каждой WinNT машине и бороться с правами доступа из 98-й к WinNT.

A: Стоит или нет покупать домен в Интернете, твое сугубо личное дело, если он тебе не нужен можешь и не покупать, тогда свой домен можешь обозвать как угодно. А переходить на доменную систему все равно надо – администрировать так действительно проще – и меньше вероятности сделать ошибку.

Q.Kак снять ограничениена одновременно закачиваемые файлы в WIN98SE(4.10.2222 A) IE6.0

A.Если вам часто приходится загружать файлы с одних и тех же Web-серверов, то вы наверняка сталкивались с досадным ограничением на количество одновременных закачек в Internet Explorer. Следуя рекомендациям протокола HTTP 1.1, браузер не позволяет производить более двух одновременных подключений к серверу, работающему по данной версии протокола (для Web-серверов, поддерживающих уже несколько устаревший стандарт HTTP 1.0, ограничение на одновременное число сессий, принятое в Internet Explorer, равно четырем). Таким образом, все попытки одновременно сохранить более чем 2 (4 в случае использования сервером HTTP версии 1.0) файла с одного и того же сайта будут обречены на неудачу - придется терпеливо ждать высвобождения места в потоке загрузок. Однако, если это необходимо, данное ограничение можно легко обойти: перейдите к разделу HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings (если настройки необходимо изменить для всех пользователей ПК - то к разделу с аналогичным названием в ветви HKU\.Default). Создайте в нем два новых DWORD-параметра с именами MaxConnectionsPerServer и MaxConnectionsPerl_OServer. Они и будут определять новые максимально допустимые значения для количества одновременных закачек - для серверов, работающих по HTTP 1.1 и HTTP 1.0 соответственно. Чтобы задать их, дважды кликните на каждом из параметров, в появившемся окне установите переключатель Система исчисления в положение Десятичная и в поле Значение введите нужные значения. После закрытия редактора реестра можно опробовать изменения.

29.05.2003 Европейский союз вводит новый домен.

В скором будущем в интернете появится новый домен. Европейский союз принял решение ввести к концу текущего года домен .eu. Пользоваться им смогут как организации, так и частные лица, проживающие на территории Евросоюза.

На данный момент существуют два разных типа доменов: общие (так называемые домены верхнего уровня), такие как .com или .gov, и национальные, указывающие на принадлежность стране (.ru, .ua, .uk). Самым распространённым доменом верхнего уровня является .com. Адреса, заканчивающиеся таким суффиксом, есть у более чем 20 млн. сайтов по всему миру. Крупнейший национальный домен - у Германии: суффикс .de используют свыше 6 млн. сайтов.

Европейская комиссия собирается сделать .eu доменом верхнего уровня и создала Европейский реестр интернет-доменов EURID (European Registry for Internet Domains). "Домен .eu должен стать отличительным признаком европейских сайтов или почтовых адресов", - отмечается в заявлении Европейского союза.

Примечательно, что в отличие от США, которые давали имена общим доменам верхнего уровня в соответствии с их назначением (.biz - для бизнеса, .pro - для профессионалов, .org - для организаций), Евросоюз дал имя новому домену по географическому признаку. Вряд ли это пойдёт домену на пользу.

Домен для профессионалов.

В ближайшее время в Сети появится новый домен .PRO. Идея этого домена состоит в том, чтобы создать сектор интернета, предназначенный для людей вполне определенных профессий, а именно - врачей, юристов и бухгалтеров. Соответственно и ресурсы этого сегмента должны принадлежать только профессионалам в соответствующих отраслях. Необходимо это для того, чтобы информация, которая будет находиться на сайтах этой зоны, являлась достаточно достоверной, поскольку изначально подразумевается, что посетители этих сайтов хотят использовать эту информацию в своей работе.

Специально для этой цели компания RegistryPro, являющаяся официальным регистратором имен в этой зоне, ввела специальные цифровые сертификаты, которые будут гарантировать, что сайты зоны действительно принадлежат профессионалам. 26.10.2003 Среди ИТ-специалистов все более популярным сегодня становится вопрос разработки систем распространения контента (content distribution system), на успех работы которых очень влияет размещение информационных серверов. Речь идет о таком размещении серверов, при котором время доступа было бы если не минимальным, то хотя бы приемлемым, т.е. отвечающим соглашению об уровне обслуживания (service level agreement — SLA). Фактически, требуется в единицу времени обслужить максимальное число пользователей при заданном времени обслуживания каждого. Так, для Web-страниц таким ограничивающим фактором будет приемлемое время загрузки страницы браузером, которое складывается не только из времени передачи данных по сети и времени их интерпретации, но также и времени, затраченного на поиск IP-адреса сервера, в том числе, и из времени обращения к службе Системы Доменных Имен (DNS).

Мой адрес не дом и не улица...

Система доменных имен Internet — ключевая служба, на которую замыкаются адреса информационных ресурсов, а точнее их идентификаторы Uniform Resource Identifier [1]. Как отмечено в [2], документе, посвященном роли системы доменных имен, архитектура DNS оставалась неизменной с момента своего создания, в то время как ее функции существенно изменились: коммерциализация Сети привела к существенному «уплощению» иерархии доменных имен. Владельцы ресурсов предпочитают использовать домены второго уровня в рамках национальных доменов или доменов общего назначения (например, microsoft.com), а не закапываться вглубь иерархии имен. Кроме того, начиная с 90-х годов, DNS стали использовать в качестве инструмента балансировки нагрузки серверов информационных ресурсов, эксплуатируя для этого алгоритм Round Robin, который применяется серверами доменных имен при ответе на запросы клиентов. Ни первое, ни второе при проектировании системы доменных имен не предполагалось (во всяком случае, в основополагающих документах [3] и [4] этого не указано).

Напомним типовую схему поиска IP-адреса по доменному имени.

Браузер через механизм resolver обращается к локальному кэширующему серверу доменных имен с рекурсивным запросом. Этому серверу передается доменное имя, для которого нужно найти IP-адрес. Сам браузер IP-адрес не ищет, а перепоручает это локальному кэширующему серверу доменных имен; в этом может убедиться каждый, кто сам настраивал подключение своего компьютера к Сети. При подключении через провайдера, например, по коммутируемому соединению, этого делать не нужно: сеть настраивается в большинстве случаев автоматически (в момент автоматической настройки провайдер по протоколу PPP присылает IP-адреса серверов доменных имен, которые будут выполнять рекурсивные запросы пользователя).

На схеме указаны два типа запросов: рекурсивный и нерекурсивный. В первом случае клиент перепоручает поиск IP-адреса серверу, а втором — сам производит опрос серверов. Локальный кэширующий сервер самостоятельно опрашивает все серверы доменных имен; поэтому он обменивается с ними нерекурсивными запросами.

В системе доменных имен установлена жесткая иерархия. Начинается она с корня. Затем следуют домены верхнего уровня (Top Level Domain, TLD), например, .com, .org, .net, .ru и т.п. Далее следуют домены второго уровня, например, nic.ru, vesti.ru и т.п. Каждый домен поддерживается авторитарным сервером домена и, как правило, не одним. При этом сервер, поддерживающий старшие имена, имеет возможность перепоручить управление младшими именами другому серверу. Такое перепоручение отражается в описании домена, управляемом сервером, и называется делегированием. Та часть дерева иерархи имен, которой управляет сервер, называется зоной. Если серверу поручено управлять корнем дерева имен, и он перепоручил все TLD другим серверам, то в его ведении остается только управление соответствиями между именами доменов и именами серверов, которым он эти домены перепоручил.

Кому поручено управление младшими именами, знает только тот сервер, который осуществляет делегирование. Поэтому, когда мы ищем что-то в домене RU, мы сначала должны узнать, кто поддерживает домен RU, а затем — кто поддерживает ту часть домена RU, которая, собственно, и интересует нас. На первый вопрос отвечает корневой сервер, который обслуживает «корень» имен DNS. Таких серверов 13 — десять в США, два в Европе и один в Японии. (До сих пор такое размещение было оправданным; действительно, согласно данным [5] около 60% клиентов корневых серверов размещены в США.) На второй вопрос ответят серверы, поддерживающие национальный домен RU. Их шесть: три размещены в России и три в Европе. Кстати, согласно статистике Фонда «Общественное мнение» [6], 19% пользователей Рунета находятся в Москве — там же, где расположены и три российских сервера зоны RU. С точки зрения использования DNS правильнее ориентироваться на данные SpyLog, которые получены на основе агрегирования статистики его счетчиков, размещенных на Web-сайтах: в апреле 2003 года в Москве находилось 43% всех городских пользователей Рунета [7].

После получения ответа с сервера, поддерживающего национальный домен, мы можем обратиться к авторитативному (authorative) серверу домена, которому принадлежит интересующее нас имя. Авторитативным этот сервер называют по той причине, что именно ему делегировано право отвечать на запросы к именам из этого домена. По правилам делегирования доменов второго уровня в RU для каждого домена таких серверов должно быть не менее двух. Вообще говоря, их может быть и больше; в [8] рекомендуется иметь три. Нарушением регламента регистрации доменов, способным повлечь временную приостановку делегирования, является ситуация, когда суммарное время отсутствия связи с сервером превышает два часа за сутки [9]. Ели домен обеспечен тремя серверами, то вероятность отказа сразу на двух серверах меньше, чем на одном, что существенно понижает риск временной потери делегирования. На самом деле, локальный кэширующий сервер доменных имен обращается к корневым серверам и авторитативным серверам домена RU только тогда, когда не может найти необходимый ему адрес в своем кэше.

Время хранения соответствий в кэше сервера определяется параметром TTL (Time To Live), которое устанавливает администратор соответствующего домена. Например, значение TTL для имен авторитативных серверов домена RU равно 86400 секунд (т.е. одни сутки); другими словами, после первого обращения за адресом из домена RU локальный кэширующий сервер доменных имен может обратиться к корневому серверу за получением списка авторитативных серверов домена RU только через сутки. Аналогичная схема работает и для всех остальных доменов. Если один пользователь обратился, скажем, к www.yandex.ru через локальный кэширующий сервер провайдера коммутируемого доступа, то этот сервер будет обслуживать всех остальных пользователей этого провайдера в течение суток, не обращаясь ни к корневым серверам доменных имен, ни к авторитативным серверам домена RU. Но, если в качестве примера выбрать www.rambler.ru, то такое кэширование (по данным на июнь 2003 года) будет осуществляться только один час. А для mail.ru это время будет равно двум часам. Таким образом, для конкретного пользователя DNS время отклика будет варьироваться от времени полного опроса всех серверов, обслуживающих искомый адрес, начиная от корневого сервера и кончая авторитативным сервером поддомена, до времени опроса только своего локального кэширующего сервера.

Вернемся к вопросу о времени отклика на запрос, а точнее к параметру RTT (Round Trip Time), который обычно и используют в качестве основы различных метрик в расчетах эффективности размещения ресурсов [5].

Не думай о секундах свысока...

Итак, как добиться приемлемого для пользователя времени обработки запроса? Прежде чем ответить на этот вопрос, разберемся, чему может быть равно это время.

Как показывают исследования [10, 11], все зависит от того, какую задачу решает пользователь. При этом обычно исследуют либо время задержки, которое начинает вызывать раздражение, либо влияние времени задержки на эффективность работы в целом. Обычно время задержки загрузки Web-страницы свыше секунды вызывает дискомфорт; однако если пользователь знает, что он получит, то раздражения не вызывают и задержки до 5 секунд. После 30 секунд речь уже не может идти об интерактивной работе. В целом для работы с известным интерфейсом подходит следующая шкала: до 5 секунд — «хорошо»; до 10 секунд — «удовлетворительно»; более 10 секунд — «плохо». Однако если показывать элементы страницы по мере их получения, то шкала для времени полной загрузки страницы изменится: до 39 секунд — «хорошо»; до 56 секунд — «удовлетворительно»; более 56 секунд — «плохо». Любопытно и другое — непреодолимое желание «ускорить» процесс возникает в среднем после 8,6 секунд ожидания хоть какого-нибудь результата.

С приемлемостью времени загрузки до 5 секунд согласны и «художники» баннеров, рекомендуя стандартный размер баннера в 10-15 Кбайт [12]: именно столько удается передать при коммутируемом соединении со скоростью 28,8 кбит/c за 3-5 секунд. (На самом деле не стоит надеяться, что пользователь, зашедший на ваш сайт впервые, будет ждать 5 секунд, а уж баннеры большинство однозначно не любит; поэтому при разработке страниц стоит все-таки стремиться к односекундной задержке до появления первого символа на экране.)

Однако баннер — только часть страницы, к тому же, для него, как правило, необходим отдельный поиск IP-адреса. Баннерообменные системы располагаются не в том же месте, где и сам сайт. Кроме того, нужно время на загрузку иллюстраций. Одним словом, время, затраченное на поиск IP-адресов, — это только часть времени загрузки, которое должно быть существенно меньше, чем приемлемое время загрузки страницы. На сколько меньше — определяется техническими ограничениями и реализацией алгоритма поиска в системе DNS.

Попытка — не пытка...

Алгоритм поиска IP-адреса по имени — многоступенчатый процесс, состоящий из серий попыток, которые выполняет «решатель» (resolver) и локальный кэширующий сервер. У каждого из них примерно одинаковый механизм опроса серверов доменных имен за исключением того, что кэширующий сервер применяет ранжирование авторитативных серверов зон по RTT. Рассмотрим этот алгоритм более внимательно.

В настройках resolver обычно указывают один-два сервера доменных имен, к которым он обращается с рекурсивными запросами. Процесс опроса начинается с первого сервера в списке и идет последовательно. Может быть совершено до четырех попыток. В первой попытке resolver ждет отклика от сервера 5 секунд, после чего переходит к следующему серверу. Если ответ не получен, то период ожидания увеличивается вдвое, и опрос серверов возобновляется с первого сервера в списке. Если resolver использует только один сервер, то тогда максимальное время ожидания отклика равно 75 секунд (5+10+20+40). Если серверов несколько, то возможны два варианта. В первом приведенный алгоритм справедлив для каждого сервера [13], а во втором время ожидания при каждой попытке на каждом сервере получается как результат деления установленного для данной попытки времени ожидания на число серверов. Например, для первой попытки и случая двух серверов оно будет равно 5/2 [14].

Следует пояснить, почему время суммируется. При рекурсивном запросе resolver перепоручает нахождение адреса локальному кэширующему серверу. Даже когда resolver начинает опрос второго сервера, первый сервер все равно пытается выполнить запрос (получить ответ и кэшировать его), поэтому при повторном обращении к нему он может иметь уже в своем распоряжении нужный ответ.

Перейдем ко второму звену поиска адреса — локальному кэширующему серверу. Он точно также опрашивает серверы, только их список он получает не из файла на диске, а из ответов других серверов. В нашем случае, когда мы не углубляемся в иерархию доменных имен дальше доменов второго уровня, список авторитативных серверов зоны домена второго уровня он получает от авторитативного сервера зоны RU. Список авторитативных серверов зоны RU он, в свою очередь, получает от корневого сервера, а список корневых серверов из своего файла настройки. Время кэширования списка авторитативных серверов зоны RU — одни сутки, поэтому основной вклад во время поиска будет вносить время доступа к авторитативным серверам искомой зоны домена второго уровня.

На самом деле разные серверы применяют разные алгоритмы выбора первого сервера для опроса [15] — BIND ранжирует серверы по RTT, а Windows выбирает просто случайным образом из полученного списка.

Что же дает анализ работы resolver в плане понимания компонентов времени отклика при поиске адреса? Во-первых, первым в настройках resolver должен быть указан сервер, который быстрее всего откликается на запросы клиента, поскольку локальный кэширующий сервер должен быть расположен как можно ближе к пользователю. Во-вторых, все серверы зоны должны быть одинаково хорошо расположены относительно пользователя (точнее, его кэширующего сервера), так как не факт, что клиент Windows, например, запросит тот сервер, который лучше всего расположен относительно него. В-третьих, с точки зрения «человеческого фактора» время задержки в 5 секунд достаточно велико для того, чтобы браузер пользователя многократно обращался к серверам.

Что такое хорошо, и что такое плохо...

Какое время отклика DNS-сервера принято считать «хорошим», а какое «плохим»? Посмотрим на наиболее загруженные и критичные с точки зрения всей системы серверы — корневые и те, что обслуживают «национальные» домены.

За последние два года был проведен ряд исследований в этой области. В CIADA [5] изучали время отклика корневых серверов на запросы клиентов со всего земного шара. Время отклика признавалось большим, если превышало 90% точку распределения времени отклика. Типичным большим временем отклика в этом исследовании было время, превышающее полсекунды. Для России из 437 точек только 14 имели большое время отклика (3% от общего числа российских участников), что сравнимо с данными по Бразилии. Важно также, что за полгода, в течение которого проводились эти исследования, доля точек в России с большим откликом не изменилась (к примеру, в Украине она увеличилась вдвое); была отмечена общая тенденция к сокращению времени отклика.

Более точные измерения проведены в работе [16]. Если в CIADA измерялось RTT от серверов к опрашивающим их хостам, то здесь использовалась программа, которая, будучи установленной в различных точках Сети и измеряла непосредственно отклик корневых серверов и серверов национальных доменов. Согласно данным [16], для США и Европы характерным временем отклика является время, меньшее 0,2 с. Здесь следует сделать оговорку. Основной объем трафика DNS приходится на корневой A–сервер; поэтому именно время отклика этого сервера и является определяющим, а оно при прямом подключении в редких случаях превышает 0,2 с. Как правило, время отклика ccTLD-серверов несколько хуже, чем корневых — несколько десятых долей секунды. Например, для Парижа среднее время отклика A-сервера равно 0,18 с, а сервера национального домена FR — 0,25 с.

А какое время отклика имеют серверы, поддерживающие домены в зоне RU? Для этого было решено замерять время обращения за записью зоны SOA (Start Of Authority), для которой сервер является авторитативным, проверять авторитативность отклика и запоминать параметр RTT. Измерения проводились из точки, для которой значение RTT до ns.ripn.net было равно 0,0013 с (запрос SOA для зоны RU), т.е. фактически от авторитативного сервера зоны RU (см. рис. 2).

Согласно статистике Ru-center, на момент проведения измерений в зоне RU было 28106 серверов [17], которые поддерживали домены второго уровня. Это означает, что 48% серверов имели время отклика менее 0,1 секунды. Еще 12% попадали в интервал 0,1-0,2 с. Приемлемое время отклика до 1 секунды имело 79% серверов; во время до 5 секунд укладывался 81% серверов.

Интересно посмотреть на 10 самых медленных (таблица 1) и самых быстрых (таблица 2) серверов из 50 наиболее популярных (по числу поддерживаемых ими уникальных доменов в зоне RU).

Разница между самыми быстрыми и самыми медленными наиболее популярными серверами составляет в среднем порядок. Пять с слишком секунд для ns1.masterhost.ru (два порядка величины) выглядят на этом фоне, мягко говоря, странно.

Следует учитывать тот факт, что серверы, поддерживающие домены второго уровня в зоне RU, как и во всем мире [18], в большинстве случаев (70%) одновременно являются и серверами, которые выполняют рекурсивные запросы. Чем ближе данный сервер расположен к корневому серверу, тем больше времени из интервала «приемлемого времени» останется на передачу полезной информации, а не на накладные расходы, к которым относится и служба DNS.

Конечно, можно возразить, что важно не как близко ты находишься к корню, а как близко к своим клиентам. Действительно, время отклика кэшируется, и не за каждым адресом приходится обращаться к авторитативному серверу доменных имен. Но больше половины пользователей, собственно, и располагаются около авторитативных серверов зоны RU, что показывает распределение времени отклика серверов доменов второго уровня.

Есть еще один момент. Например, rambler.ru, как уже было указано, кэшируется только час, а время доступа до него от ns.ripn.net — 0,004 с. Для mail.ru время доступа от ns.ripn.ru также равняется 0,004 с. Время определяется не только физическим расстоянием, но и качеством, и пропускной способностью канала. Например, для сервера ns.nsk.ru время отклика составляет 0,18 с, а для ns.spb.su — 0,019 с. В таких условиях времена отклика серверов доменных имен провайдеров услуг хостинга, которые превышают 0,15 с, выглядят плохо. Понятно, что это, скорее всего дублирующие серверы (secondary), но алгоритмы выбора серверов resolver предполагают «одинаковость» авторитативных серверов доменов.

Сухой остаток

Следует признать «приемлемым» время загрузки от 1 до 5 секунд, а в качестве цели, которую желательно достичь при разработке страниц сайтов, — 1 секунда до появления первого символа на экране пользователя. В качестве цели при размещении DNS-серверов следует признать такое время поиска в системе DNS, которое не превышало бы 0,15 с. Согласно измерениям времени отклика серверов доменных имен второго уровня в зоне RU, более половины серверов удовлетворяют этим условиям.

Для надежного обеспечения поиска своих ресурсов в сети следует не ограничиваться двумя авторитативными серверами, а увеличить их число до трех, чтобы не оказаться в ситуации приостановки делегирования.

«Хорошо» размещать нужно не только первичный (master) сервер зоны, но и все авторитативные серверы — неисправность любого из них грозит приостановкой делегирования, а кроме того, совершенно не обязательно, что resolver-сервер пользователя выберет при поиске первичный сервер.

У ИТ-общественности еще нет четкого понимания того, чем конкретно (убытки, потерянные пользователи, четко измеренные недопустимые задержки и т.п.) может грозить неправильное размещение DNS-сервера. Для Рунета никто не рассчитывал времена отклика на запрос ресурсов, не изучал составляющие времени отклика, и влияние всего этого на бизнес. Между тем, к примеру, при изменении маршрутизации в конце прошлого года тремя ведущими российскими провайдерами и увеличении RTT некоторые бизнесмены от Internet потеряли пользователей и, соответственно, понесли убытки, но их измерений и корреляций никто не делал. На Западе работы, посвященные измерению RTT тем же методом, что и рассмотренные в данной статье, были проведены в конце прошлого года [18]. Предполагается, что это поможет судить о влиянии RTT на эффективность работы Сети, однако пока эти работы еще не завершены. В общем случае, это достаточно серьезная проблема, затрагивающая оценку всего объема трафика, предоставляемого отечественными провайдерами.

Защита сервера DNS

Конфигурируя сервер, администраторы часто забывают правильно настроить службу DNS. После такой настройки служба DNS работает корректно: IP-адреса разрешаются в имена компьютеров, а символьные имена без проблем преобразуются в IP-адреса. На этом большинство администраторов и останавливаются: главное, чтобы работало. Работать-то оно работает, но неправильно настроенный сервер DNS может стать огромной дырой в системе безопасности компании. Одно дело, когда сервер DNS обслуживает локальную сеть без выхода в Интернет: даже, если кто-то и попытается "взломать" сервер, то вычислить "хакера" довольно просто. А вот, если сеть предприятия подключена к Интернет, то узнать, кто же пытался взломать (или взломал) вашу сеть довольно сложно. Ущерб от взлома может обойтись компании в кругленькую сумму.

Прежде, чем приступить к взлому сети или отдельной системы злоумышленник (или группа злоумышленников) пытается собрать как можно больше информации: имена компьютеров сети, имена пользователей, версии установленного программного обеспечения. Целой кладовой полезной для взломщика информации станет неправильно настроенная служба DNS (BIND). Рассмотрим небольшой пример: запустите программу nslookup и введите команду:
```
 ls server.com
```
Если администратор забыл правильно настроить трансфер зоны, то кто угодно получит список компьютеров нашей сети:
```
[comp2.server.com]
server.com. 323.111.200.2
server.com. server = comp1.server.com
server.com. server = comp2.server.com
server.com. server = comp3.server.com
mail 323.111.200.17
gold 323.111.200.22
www.ie 323.111.200.11
jersild 323.111.200.25
comp1 323.111.200.1
comp3 323.111.200.3
parasit3 323.111.200.20
www.press 323.111.200.30
comp1 323.111.200.1
www 323.111.200.2
```
Примечание. Чтобы не было недоразумений, указаны несуществующие IP-адреса

Дабы не случилось непоправимого, разрешите передачу зону только одному компьютеру - вторичному серверу DNS вашей компании, если такой, конечно, имеется. В файле конфигурации сервиса named - /etc/named.conf - измените секцию options следующим образом:
```
options{
allow-transfer
{
192.168.1.2;
};
};
```
Вторичный сервер DNS, как правило, не передает никакой информации о зоне, поэтому обязательно укажите следующую строку в его файле конфигурации /etc/named.conf (в секции options):
```
allow-transfer { none; }
```
Если у вас нет вторичного сервера DNS, добавьте вышеуказанную строку в файл конфигурации основного сервера DNS.

Как любой хороший администратор, вы хотите, чтобы ваш сервер DNS быстро обслуживал запросы клиентов. Но к вашему серверу могут подключаться пользователи не из вашей сети, например, из сети конкурирующего провайдера. Тогда вас сервер будет обслуживать "чужих" клиентов. Непорядок! Опция allow-query позволяет указать адреса узлов и сетей, которым можно использовать наш сервер DNS:
```
allow-query { 192.168.1.0/24; localhost; };
```
В данном примере мы позволяем использовать наш сервер узлам из сети 192.168.1.0 и узлу localhost. Целесообразно разрешить рекурсивные запросы только из сети 192.168.1.0 и узлу localhost:
```
allow-recursion { 192.168.1.0/24; localhost; };
```
Обычно взлом любой сети начинается со сбора информации - о структуре сети, об установленном программном обеспечении и версиях этого ПО и т.д. Мы можем заставить сервер DNS сообщать не номер своей версии, а произвольное сообщение:
```
version "Made in USSR";
```
Все вышеперечисленные опции должны быть указаны в секции options файла конфигурации named.conf:
```
options {
allow-query { 192.168.1.0/24; localhost; };
allow-recursion { 192.168.1.0/24; localhost; };
allow-transfer { 192.168.1.2; };
version "Made in USSR";
}
```
Из соображений безопасности рекомендуется запускать все сетевые сервисы в так называемом chroot-окружении. Сейчас поясню, что это такое. Создается файловая система, повторяющая структуру корневой файловой системы, но на этой файловой системе будут только те файлы, которые необходимы для запуска нашего сетевого сервиса. Взломав сетевой сервис и получив доступ к корневой файловой системе, злоумышленник не сможет повредить всей системе в целом, поскольку он получит доступ только к файлам, которые принадлежат данному сетевому сервису. Одни сетевые сервисы могут работать в chroot-окружении, а другие - нет. Сервис BIND как раз относится к первой группе. Теперь разберемся, как все это организовывается. Вам не нужно создавать отдельный раздел на диске для каждого сетевого сервиса: нужно только создать каталог, например, root-dns, в который вы скопируете все файлы, необходимые для запуска сервера DNS. Потом, при запуске сервиса, будет выполнена команда chroot для этого сервиса, которая подменит файловую систему. А так как в каталоге root-dns, который станет каталогом /, имеются все необходимые файлы для работы bind, то для сервиса запуск и работа в chroot-окружении будет совершенно прозрачным.

Сразу нужно сказать, что настраивать chroot-окружении мы будем для девятой версии BIND, поскольку это значительно проще, чем для восьмой версии. В отличие от восьмой версии, где для настройки chroot-окружения нужно было копировать все бинарные файлы или библиотеки, необходимые для запуска BIND, для работы девятой версии достаточно скопировать только файлы конфигурации и зон, обслуживаемых сервером.

Начнем настраивать chroot-окружение для нашего сервера DNS. Создадим каталоги корневой файловой системы сервера DNS - root-dns:
```
mkdir -p /root-dns
mkdir -p /root-dns/etc
mkdir -p /root-dns/var/run/named
mkdir -p /root-dns/var/named
```
Остановим сервер DNS, если он запущен:
```
service named stop
```
Переместим файл конфигурации named.conf и файлы зон в каталог /root-dns:
```
mv /etc/named.conf /root-dns/etc/
mv /var/named/* /root-dns/var/named/
chown named.named /chroot/etc/named.conf
chown -R named.named /root-dns/var/named/*
```
Нам еще понадобится файл localtime для правильной работы сервера DNS со временем:
```
cp /etc/localtime /root-dns/etc/
```
Защитим от редактирования и удаления файл конфигурации named.conf:
```
chattr +i /root-dns/etc/named.conf
```
Примечание. Не забудьте снять атрибут "i" перед редактированием файла конфигурации (chattr -i /root-dns/etc/named.conf)

Удалим каталоги /var/named и /var/run/named - они нам больше не нужны:
```
rm -rf /var/named/
rm -rf /var/run/named/
```
Добавим в файл /etc/sysconfig/named строку:
```
ROOTDIR="/root-dns/"
```
Все, теперь можно запустить сервер named:
```
service named start
```
Выполните команду ps -ax | grep named. Если вы увидите примерно следующее:
```
5380  ?                S       0:00 named -u named -t /root-dns/
5381  ?         S       0:00 named -u named -t /root-dns/
5382  ?         S       0:00 named -u named -t /root-dns/
5383  ?         S       0:00 named -u named -t /root-dns/
```
значит, вы все сделали правильно.

Мы запустили сервер DNS в chroot-окружении, но на этом данная статья не заканчивается. В девятой версии BIND появилась возможность создавать подписи транзакций (TSIG - Transaction SIGnatures). Механизм TSIG работает так: сервер получает сообщение, подписанное ключом, затем подпись проверяется, если она "правильная", сервер отправляет ответ, подписанный тем же ключом.

Механизм TSIG очень эффективен при передаче информации о зоне, уведомлений об изменении зоны и рекурсивных сообщений. Согласитесь, проверка подписи надежнее, чем проверка IP-адреса. Злоумышленник может вывести вторичный сервер DNS банальной атакой на отказ, и, пока администратор будет "подымать" вторичный сервер, он заменит свой IP-адрес адресом вторичного сервера. При использовании TSIG задача злоумышленника значительно усложняется: ведь ему придется "подобрать" 128-битный MD5-ключ, а вероятность такого подбора стремится к нулю.

Итак, приступим к настройке. Остановим сервис named, если он запущен:
```
service named stop
```
Сгенерируем общие ключи для каждой пары узлов. Общие ключи используются при "общении" первичного и вторичного серверов DNS.
```
[root@dns]# dnssec-keygen -a hmac-md5 -b 128 -n HOST ns1-ns2
Kns1-ns2.+157+49406
```
Мы используем алгоритм HMAC-MD5, 128-битное шифрование, ns1-ns2 - это имя ключа. После выполнения этой команды будет создан файл Kns1-ns2.+176+40946.private. Откройте его в любом текстовом редакторе. Вы увидите примерно следующее:
```
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: ms7dfts87Cjhj7FD9lk7a3==
```
Ключ "ms7dfts87Cjhj7FD9lk7a3==" и будет тем секретом, который будет передаваться между серверами. Запишите данный ключ на бумаге (которую потом нужно будет уничтожить) и удалите файлы:
```
rm -f Kns1-ns2.+157+49406.key
rm -f Kns1-ns2.+157+49406.private
```
Добавим в файл /etc/named.conf (или /root-dns/etc/named.conf) первичного и вторичного серверов DNS следующие строки:
```
key ns1-ns2 {
algorithm hmac-md5;
secret "ms7dfts87Cjhj7FD9lk7a3==";
};
```
Укажем серверу BIND использовать ключ ns1-ns2. Для этого в файле named.conf первичного сервера DNS добавим опцию server:
```
Листинг 1. Фрагмент файла named.conf первичного сервера DNS
key ns1-ns2 {
algorithm hmac-md5;
secret "ms7dfts87Cjhj7FD9lk7a3==";
};
# прописываем вторичный сервер DNS - 192.168.1.2:
server 192.168.1.2 {
keys { ns1-ns2; };
};
options {
# разрешаем передачу зоны вторичному серверу DNS
allow-transfer { 192.168.1.2; };
?
};
?.
Листинг 2. Фрагмент файла named.conf ВТОРИЧНОГО сервера DNS
key ns1-ns2 {
algorithm hmac-md5;
secret "ms7dfts87Cjhj7FD9lk7a3==";
};
# прописываем первичный сервер DNS - 192.168.1.1:
server 192.168.1.1 {
keys { ns1-ns2; };
};
options {
# никому не передаем зону
allow-transfer { none };
?
};
?.
```
Можно также настроить передачу зоны "по ключу". Для этого в файле конфигурации первичного сервера DNS замените строку
```
allow-transfer { 192.168.1.2; };
```
строкой
```
allow-transfer { key ns1-ns2; };
```
Нам осталось только "спрятать" файлы конфигурации обоих серверов DNS от посторонних глаз - ведь они содержат ключи в открытом виде.
```
chmod 600 named.conf
```
Запускаем сервис named:
```
service named start
```
Теперь о безопасности вашего BIND позаботится TSIG. Настройки DNS

Почему я должен в записи домена указывать сервер имён (DNS) моего хостинга?

Как было рассказано выше, сервер имен отвечает за то, как найти информацию о Вашем сайте. Когда Вы заполняете запись в Вашем домене, Вы сообщаете всему интернету информацию о точном направлении где можно взять наиболее точную информацию. Если Вы не измените информацию в записи своего домена, (то есть оставите использование предыдущего DNS хостинг-провайдера), то указатель на информацию о Вашем сайте будет указывать на сервер, где на самом деле уже нет Вашего сайта. Или если предыдущий хостинг-провайдер уже удалил со своего DNS записи о Вашем сайте, то Ваш домен будет указывать в "никуда".

Почему изменения о смене хостинга так долго вступают в силу?

Когда Вы меняете хостинг провайдера (адрес) или в первый раз регистрируете доменное имя, информация о новой записи поступает на другие сервер доменных имен (DNS). Выш сайт может заработать уже через 4 часа, но среднее время распространения информации составляет 24-72 часа. Эта задержка происходит в следствии того, что большинство серверов имен (DNS) настроены на периодическое обновление информации. Таким образом, информация, которая на них хранится не всегда "живая." Обновление информации через определенный период времени для данных серверов выбран потому, что информация такого рода меняется очень редко.

Почему мой домен ссылается на старый хостинг,хотя я там давно не имею аккаунта?

Этому есть несколько объяснений:

1. Информация о старых DNS осталась в записях Вашего домена.

Решение: Отредактируйте записи Вашего домена так, чтобы они указывали на сервер имен (DNS) Вашего нового хостинг провайдера.

2. Они не удалили записи о Вашем домене со своего сервера доменных имен.

Решение: Попросите их удалит старую запись о Вашем домене, или следуйте решению #1 если Вы перешли к новому хостинг провайдеру.

3. Информация о новой записи Вашего сайта еще не распространилась на все сервера имен (DNS). Это случается всякий раз, когда Вы меняете запись указателя сервера имен (DNS) домена Вашего сайта.

Решение: Подождите 24-72 часа и обращайтесь к Вашему хостинг провайдеру, если проблема остается.

Почему некоторые пользователи уже видят мой новый сайт, а я нет?

Записи о Вашем домене у провайдера, к которому они подключены, уже обновились. Будте терпеливы, и в ближайшее время (до 72 часов) записи обновятся и у Вашего провайдера.

Есть ли какой-либо способ посмотреть/получить доступ к моему сайту до тех пор пока не обновлены записи DNS?

Да. Вы можете получить доступ по адресу ip.address/~username. Если Вы не знаете IP адрес сервера, пожалуйста, спросите его у Вашего хостинг провайдера.

Изменение настроек DNS

Для доступа к настройкам DNS в главном меню панели управления нажмите на иконку "DNS Menu".

В приведенном примере даны настройки DNS для сайта site-helper.com. Следующие абзацы расскажут Вам как менять записи A, CNAME, NS, MX, и PTR. Эта секция необходима для полного понимания того, как панель управления управляет именами хостов.

Внимание: Есть два пути для ввода имени хоста:

1. Полное имя хоста с точкой на конце: full.hostname.ru.

2. Только поддомен: full

Например, первую запись в указанной таблице можно прочитать так:

admin A 216.194.67.119 или

admin.site-helper.com. A 216.194.67.119

Обе эти записи идентичны. В некоторых случаях, которые мы рассмотрим ниже, описывается только один из этих методов, но также может быть использован и другой.

Примечание: Если Вы не уверены как необходимо вводить записи, посмотрите на существующие записи в таблице и сделайте запись по the table for guidance.

Изучаем записи: A,CNAME, NS, MX, и PTR.

Записи типа A (A RECORDS)

Запись типа A позволяет установить соответствие между именем хоста в домене и его IP-адресом. Например, если Вы хотите, чтобы mycomputer.yourdomain.com указывала на Ваш домашний компьютер (который имеет адрес, например, 192.168.0.3), Вы должны ввести запись так:

Важно: Вы должны поставить точку после имени хоста. Не ставьте точки после адреса IP.

Запись CNAME (CNAME RECORDS)

Запись типа CNAME (Canonical Name - Каноническое имя) позволяют присваивать хосту мнемонические имена. Мнемонические имена, или псевдонимы, широко применяются для связывания с хостом какой-либо функции, либо просто для сокращения имени. Реальное имя иногда называют каноническим. Например:

vashdomain.ru. A 192.168.0.1

Если для хоста есть запись типа CNAME, которая содержит его мнемонические имена, другие записи для данного хоста должны ссылаться на его реальное (каноническое) имя, а не на мнемоническое. Когда программы DNS встречают запись CNAME, они прекращают свои запросы по мнемоническому имени и переключаются на реальное имя. Кроме того, если данное имя использовано в качестве псевдонима, то на него нельзя занести записи любого другого типа. Например:

ftp.vashdoman.ru. CNAME vashdomain.ru.

mail.vashdomain.ru. CNAME vashdomain.ru.

ssh.vashdomin.ru. CNAME vashdomain.ru.

записи CNAME дают возможность доступа к Вашему домену через адреса ftp.vashdomain.ru, mail.vashdomain.ru, и т.д.. Без таких записей CNAME Вы не сможете подключиться к Вашему серверу по таким адресам.

Ввод записи CNAME

Если мы хотим, чтобы home.site-helper.com указывал на site-helper.com, мы можем сделать это двумя методами:

Мы просто можем ввести имя поддомена. Не ставьте точку после названия поддомена.

Второй способ: введите полное имя домена, заканчивающееся точкой.

Записи сервера имён (NS)

Записи типа NS (Name Server - cервер имен) описывают authoritative DNS-серверы для данного домена. Количество записей типа NS в файле зоны должно точно соответствовать количеству DNS-серверов, обслуживающих домен и включать все DNS-серверы, указанные в домене. Для доменов второго уровня это DNS-серверы, указанные в полях "nserver".

Внимание: Изменением записей NS Вы можете остановить работу Вашего сайта. Обычно не требуется изменять записи NS.

Ввод записи NS

Первым шагом необходимо удалить старые записи NS.

Затем, введите две новые записи серверов имен. Имя хоста серевра имен должно оканчиваться точкой, как показано на примере:

Не забывайте ставить точку после имени хоста в записи NS (ns1.newnameserver.com. а не ns1.newnameserver.com ).

Записи MX

Запись типа MX (Mail Exchange - почтовый сервер) определяет почтовый сервер - машину, которая обрабатывает почту для вашего домена. Приоритет: определяет значение приоритетности почтового сервера. Чем меньше число, тем выше приоритет почтового сервера (0 означает самый высокий приоритет, 65535 - самый низкий). Таким образом, почтовый сервер с более высоким приоритетом является основным, а почтовые серверы с более низкими приоритетами будут второстепенным и вступят в работу в том случае, если все более приоритетные серверы по каким-либо причинам недоступны или неработоспособны. Если Вы меняете запись MX таким образом, что почта будет обрабатываться другим сервером, все Ваши текущие аккаунты POP3, переадресации, почтовые роботы, и списки рассылки остануться без работы, то есть почта на них поступать не будет.

Для изменения записи MX, сначала зайдите в "E-Mail Menu" из основного меню панели управления. Затем, нажмите иконку "MX Records".

Во-первых, удалите старую запись MX путем установки галочки напротив имени записи и нажатием на кнопку "Delete Selected." После выполнения данной операции список записей должен быть пустой.

Затем, введите имя нового хоста, оканчивающееся точкой, данное Вам провайдером электронной почтой. Затем выберите приоритет (обычно 10) из низспадающего меню. Уровень приоритета также должен быть выдан Вашим провайдером электронной почты. Нажмите "Add."

Внимание: Обязательно ставьте точку в конце имени хоста.

Для восстановления первоначальных настроек записи MX, введите vashdomain.ru. с приоритетом 0 после удаления всех других записей.

Записи PTR

Записи типа PTR (Pointer - указатель) служат для выполнения обратного преобразования IP-адресов в имена хостов. Для каждого сетевого интерфейса хоста рекомендуется создать запись PTR. Записи типа PTR, как правило, имеет смысл вносить только в обратные зоны. Если провайдер выделил вам несколько IP-адресов из своей сети, то по поводу записей в обратной зоне вам следует обращаться к нему Например, чтобы адресу 192.168.0.1 соответствовало www.vashdomain.ru, запись должна выглядеть так:

1.0.168.192.in-addr.arpa PTR www.vashdomain.ru.

Примечание: Адрес IP "перевёрнут" в первом поле. Пожалуйста, используйте точку после имени хоста (второе поле).

Чаще всего используется метод “in-addr-arpa”.

Важно: Записи PTR эффективны только в том случае, если Ваш сайт имеет собственный адрес IP.

Внимание:Записи PTR работают только в случае ручного редактирования named.conf путем добавления необходимой информации о зоне. Это может быть сделано суперпользователем (root) (Администратором сервера).

DNS: частые вопросы и ответы

Новости

Доменные Окончания