» Всё о DNS

8oton

Цитата:

вобщем как сделать, чтоб по ip открывалась страница моего сайта.

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

8oton
перегрузи намед и не парься. если бы ты днс-ом занимался и у тебя на серваке было бы 3К зон - тогда конечно все перегружать некорректно , а когда пару зон - можно и весь сервер ребутать :)

Возможно я не так выразился.

Вот пример, сейчас нужно сделать практически тоже самое:
Когда-то у меня был реселлерский акаунт в Германии.
Взял я себе у infobox'a почту, прикрепил туда один из своих .com.ru доменов.
Но они infobox не давали хост даже под redirect на мой сайт. Зато в панели управления есть возможность управлять dns.
Я связался с супортом infobox'a мол как мне сделать чтоб по этому домену открывался мой сайт.
Они мне сказали что это возможно, но для этого на другом мой сайт должен на другом открыватся по ip-адресу. Я сделал на акаунте у infobox'a в dns "A" запись на ip своего реселлерского акаунта. Связался с админами реселерского сервера и они как-то сделали имено то что мне нужно и сделали довольно быстро.

Добавлено:
я предопологаю что в панели управления confixx или plesk - есть такая функция.
только как она называется пониятия не имею.
дэмоверсии панелей есть на сайтах разработчика.

настроил rndc как описано в статье - скинул rndc.conf в /etc/named.d
добавил что написано в rndc.conf - в самое начало named.conf еще до переменной options {...};
и все равно пишет что и раньше
# rndc status
rndc: connect failed: connection refused

На сервере SuSE 9.x
Moжет я не туда скопировал rndc.conf и странно что в конфиге самого named нигде не указывается путь к rndc.conf

HELP !!!!

# lsof -i -n | grep named
named 10553 named 20u IPv4 124946446 UDP 127.0.0.1:domain
named 10553 named 21u IPv4 124946447 TCP 127.0.0.1:domain (LISTEN)
named 10553 named 22u IPv4 124946448 UDP 194.93.190.132:domain
named 10553 named 23u IPv4 124946449 TCP 194.93.190.132:domain (LISTEN)
named 10553 named 26u IPv4 124946456 TCP 127.0.0.1:rndc (LISTEN)

у тебя порт для rndc открыт ?

в конфиге named.conf 53'ий порт у меня закоментирован.
раскоментировать?

lsof -i -n | grep named
ничего не выдало.

Добавлено:
Вот мой конфиг:
http://big-world.com.ru/named.conf

8oton
почитай для начал пару howto


Цитата:

lsof -i -n | grep named

это у меня он намед назывется, у тебя он может и dns-ом называться, и bind-ом ... думать надо...

просто # lsof -i -n
и смотри что там есть

# lsof -i -n
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
dhcpcd 697 root 4u IPv4 1346 UDP *:bootpc
sshd 903 root 3u IPv6 1999 TCP *:ssh (LISTEN)
xinetd 1128 root 5u IPv4 2638 TCP *:pop3 (LISTEN)
xinetd 1128 root 8u IPv4 2639 TCP *:pop3s (LISTEN)
xinetd 1128 root 9u IPv4 2640 TCP *:ftp (LISTEN)
spamd 1130 spamd 5u IPv4 2649 TCP 127.0.0.1:783 (LISTEN)
ntpd 1197 ntp 4u IPv4 2825 UDP *:ntp
ntpd 1197 ntp 5u IPv6 2826 UDP *:ntp
ntpd 1197 ntp 6u IPv4 2827 UDP 127.0.0.1:ntp
master 1249 root 12u IPv6 3015 TCP *:smtp (LISTEN)
master 1249 root 13u IPv4 3016 TCP *:smtp (LISTEN)
master 1249 root 16u IPv6 3019 TCP *:smtps (LISTEN)
master 1249 root 17u IPv4 3020 TCP *:smtps (LISTEN)
httpd2-pr 1296 root 3u IPv6 3156 TCP *:http (LISTEN)
httpd2-pr 1296 root 4u IPv6 3157 TCP *:https (LISTEN)
httpd2-pr 1339 root 3u IPv6 3156 TCP *:http (LISTEN)
httpd2-pr 1339 root 4u IPv6 3157 TCP *:https (LISTEN)
httpd2-pr 1340 wwwrun 3u IPv6 3156 TCP *:http (LISTEN)
httpd2-pr 1340 wwwrun 4u IPv6 3157 TCP *:https (LISTEN)
httpd2-pr 1341 wwwrun 3u IPv6 3156 TCP *:http (LISTEN)
httpd2-pr 1341 wwwrun 4u IPv6 3157 TCP *:https (LISTEN)
httpd2-pr 1342 wwwrun 3u IPv6 3156 TCP *:http (LISTEN)
httpd2-pr 1342 wwwrun 4u IPv6 3157 TCP *:https (LISTEN)
httpd2-pr 1343 wwwrun 3u IPv6 3156 TCP *:http (LISTEN)
httpd2-pr 1343 wwwrun 4u IPv6 3157 TCP *:https (LISTEN)
httpd2-pr 1344 wwwrun 3u IPv6 3156 TCP *:http (LISTEN)
httpd2-pr 1344 wwwrun 4u IPv6 3157 TCP *:https (LISTEN)
httpd2-pr 2277 wwwrun 3u IPv6 3156 TCP *:http (LISTEN)
httpd2-pr 2277 wwwrun 4u IPv6 3157 TCP *:https (LISTEN)

Цитата:

key "rndc-key" {
algorithm hmac-md5;
secret "секрет";
};

secret "секрет"; - это в MD5 ?:)

named.conf---------------------------
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
include "/etc/rndc.key";


rndc.conf------------------------------
options {
default-server localhost;
default-key "rndckey";
};

server localhost {
key "rndckey";
};

include "/etc/rndc.key";

/etc/rndc.key-------------------------
key "rndckey" {
algorithm hmac-md5;
secret "здесь ключ в MD5 - должен быть написан какой-то по-умолчанию, можно оставить ";
};

да стоят там ключи в md5 и процесc named называется.

ща скину rndc.conf

Добавлено:
http://big-world.com.ru/rndc.conf

Добавлено:
вот что-то написано тут: http://forum.sysadmins.ru/0/16487/
но ответа на свою проблему я что-то не нашел.

тю, так у тебя намед не заводится.
при чем тут тогда rndc ?

All
Есть такая проблема.
Есть сервак с Windows DNS? с двумя сетевыми картами, постоянно через SHDSL в Инете висит.
Как сделать так чтобы одному имени присвоить два IP адреса?
1-й IP из локального Диопозона?
2-й IPнастоящий выданный провайдером?

В локалки DNS вроде нормально работает.
А вот из Инета, когда пингуем хост в 50% случаях выдаёт локальный IP.
Я так понимаю надо эти IP жеско по интерфейсом разнести , но как это сделать так и не нашёл.
Помогите пожалуйста разобраться.
Зарание спасибо.

MaximuS
Интересно, а как из Инета виден ваш локальный DNS, чтобы выдавать локальные IP?
А если DNS не локальный, то у него соответственно должно быть две зоны, для внешних и для внутренних.

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

Smoker
Вот конфигурация моего Внутреннего и единственного DNS

Название Тип Значение
comp
(как папка верхнего уровня) Начальная запись зоны (SOA) [143], demon.firma.by., administrator.firma.by.
(как папка верхнего уровня) Сервер имен (NS) demon.firma.by.
(как папка верхнего уровня) Почтовый обменник (MX) [10] mail.firma.by.
demon Узел (A) 194.194.194.1
demon Узел (A) 100.1.0.1
mail Узел (A) 194.194.194.2
mail Узел (A) 100.1.0.2

Эта зона прямого просмотра

tankistua
ну так а как мне его поднять?
процес то запущен.

MaximuS
Дублируется имя компьютера

Цитата:

demon Узел (A) 194.194.194.1
mail Узел (A) 194.194.194.2

Ты уверен, что тебе нужно поддерживать внешний IP?
Т.е. он не прописан у твоего провайдера?

8oton

Цитата:

ну так а как мне его поднять?

а я почем знаю как на сюсе поднимается бинд. Может ты там в конфиге нарулил неизвестно чего.

Читай доки по бинду.

Теперь интересует как сделать вот такой редирект домена на другой сервер:
Домен уже прописан на сервер, нужно создать поддомен irc.domen.ru и сделать ему преадрисацию на irc.efnet.net

Расскажи плз как это через bind настроить?

8oton

Цитата:

создать поддомен irc.domen.ru

Сделай в файле зоны запись типа
irc А ip.address.efnet.net

Цитата:

irc А ip.address.efnet.net

не забывай перед рестартом зоны сериал менять.


Цитата:

Связался с админами реселерского сервера и они как-то сделали имено то что мне нужно и сделали довольно быстро.

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

Есть два контроллера домена, оба глобальные... на каждом стоит DNS-сервер с базой интегрированной в AD. Работает вроде всё отлично но nslookup не проходит даже при запуске локально:

*** Can't find server name for address 172.16.0.252: Non-existent domain
Default Server: UnKnown
Address: 172.16.0.252

Такое на обоих серверах... в чём могут быть проблемы? Работа с новыми записями и репликацией - никаких проблем нет.
Кстати оба сервера доступ в инет не имеют а также установлен ещё и WINS...

Добавлено:
Собственно вопрос - что делать? Плюнуть на результаты nslookup?

Что-то у меня снова не получается с доменами.
Суть проблемы - ошибка выдаваемая при попытке сменить ns для домена и захостить его на нужном сервере.
Вот текст ошибки

Цитата:

Ошибка:
Не удалось получить зону для домена domen.ru с DNS-сервера ns1.domen.ru.

Пока зона для домена domen.ru ещё не настроена на всех указанных Вами DNS-серверах, Вы можете оставить список DNS-серверов пустым. После того, как зона будет настроена на всех серверах — Вы сможете вернуться в настройки домена и указать нужные DNS-сервера.

Содержание файла зоны:


Цитата:

$TTL 3600
@ IN SOA ns1.domen.ru. admin.domen.ru. (
2005071900; serial, todays date+todays
14400; refresh, seconds
7200; retry, seconds
604800; expire, seconds
86400 ); minimum, seconds

ns1.domen.ru. IN A 255.255.255.255

IN NS ns1.domen.ru.
IN NS ns0.xname.org.
IN NS ns1.xname.org.

IN MX 10 domen.ru.

mail IN CNAME domen.ru.
www IN CNAME domen.ru.
ftp IN CNAME domen.ru.

Реальное доменное имя заменено на domen.ru, ip адрес сервера заменен на 255.255.255.255
Подскажите плз что не так в файле зоны?

# dig @127.0.0.1 domen.ru

; <<>> DiG 9.2.3 <<>> @127.0.0.1 domen.ru
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45866
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;domen.ru. IN A

;; AUTHORITY SECTION:
ru. 3600 IN SOA ns.ripn.net. hostmaster.ripn.net. 4009281 7200 900 2592000 3600

;; Query time: 66 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 19 00:16:43 2005
;; MSG SIZE rcvd: 88

В АUTHORITY SECTION написано то, что я вобще не прописывал:
ru. 3600 IN SOA ns.ripn.net. hostmaster.ripn.net. 4009281 7200 900 2592000 3600


ВСЕМ ЗАРАНЕЕ СПАСИБО ЗА ПОМОЩЬ.

2003 сервер, AD, DNS, 2 сетевых интерфейса (локаль и инет). DNS в сети один. DNS настроен на локальный инерфейс. Соответственно зона обратного просмотра так же на локали. Надо создать ptr запись на сетевой интерфейс смотрящий в инет. Можно ли это сделать?
Добавить вторую зону прямого просмотра и для нее создать обратную зону? (можно ли создавать 2 основные зоны?)

писал статью, но как-то недостает желания довести все до ума, тем более что разбираюсь в днс-е , но не супер-профи. А учить чему-то должен профессионал:

Посему, так как много написано и изложены некоторые мысли и личный опыт, просто выкладываю как есть.
Думаю кому-то будет полезно.





=========================================================================
Чтобы понять DNS, необходимо обратиться к истории сети ARPAnet.
Изначально сеть ARPAnet представляла тесное сообщество из нескольких сотен
узлов. Всю информацию, необходимую для взаимных преобразований имен и узлов
сети ARPAnet, содержал единственный hosts.txt , ответственность за него нес
Network Information Center(NIC). Администраторы ARPAnet просто посылали
изменения электронной почтой в NIC, которые дополняли файл hosts.txt и раз
или два раза в неделю обновляли его на сервере. Администраторы ARPAnet
посредством протокла ftp синхронизировали свои файлы hosts.txt с копией на
сервере NIC.
После перехода сети ARPAnet на протоколs TCP/IP, сеть начала расти
быстро, естественно увеличивался размер файла hosts.txt, вследствие
чего возникало много проблемы:
- информационные потоки и нагрузка
- конфликты имен
- синхронизация
Основной же проблемой было отсутствие масштабируемости.
В 1984 году были изданы RFC 882 и RFC 883, которые описывали
принципы работы системы доменных имен (Domain Name System, DNS),
впоследствии документы были заменены RFC 1034 и RFC 1035, так же были
написаны множественные допосления. Cписок RFC, относящихся к DNS http://www.faqs.org/rfcs/dns-rfcs.html
Если просто , то DNS - это распределенная база данных.
Система DNS подразумевают под собой передачу прав на управление определенной зоной администратору
данной зоны. Процедура передачи прав на управление зоной называется делегированием.
Корневых сервер не имеет RR-записей делигируемой зоны, исключение
составляют специальные RR-записи glue-record, которые необходимы, если
name-сервер находится в делегируемой зоне
Первая версия системы DNS называлась JEEVES и была разработана автором
RFC 882 и RFC 883. Более поздняя реализация носит название BIND (Berkeley
Internet Name Domain) и была разработана для операционной системы BSD Unix.
В настоящее время BIND является самой популярной и распространенной системой
DNS, развитием и сопровождением которого занимается Internet Software Consortium.

Настройка DNS-сиcтемы BIND.
Правила делегирования домена требуют наличия как минимум двух
ответственных за данную зону DNS-серверов. Такие сервера называются
автритативными для конкретной зоны. Один из авторитативных серверов назначается primary,
остальные - secondary. На primary-сервере храниться основной файл зоны, secondary-сервера
получают ( точнее берут ) данные с primary-сервера.
Соответственно и отличаются настройки серверов:

Настройка primary-сервера.
В конфирурационный файл named.conf необходимо добавить запись зоны

zone "имя_домена" {
type master;
file "имя_домена";
};

Настройка secondary-сервера.
В конфирурационный файл named.conf необходимо добавить запись зоны

zone "имя_домена" {
type slave;
file "имя_домена " ;
masters { ip_адрес_ primary-сервера; };

где имя_домена - собственно имя зоны, которую необходимо поддерживать
type master; - запись указывает, что это primary-сервер для данной зоны
type slave; - запись указывает, что это secondary-сервер для данной зоны
file "имя_домена"; - здесь необходимо указать путь к файлу , в котором будут
храниться данные зоны. Для простоты использования
рекомендуется называть файл зоны именем зоны, но имя файла может быть
произвольным. primary-сервер будет данные читать из файла,
который указан, secondary-сервера будет загружать с primary-сервера
данные и хранить эти данные в указанном файле (данный файл создается
secondary-сервером).
ip_адрес_ primary-сервера - указывается ip-адрес primary-сервера, на котором
храниться основной файл зоны

Для того, чтобы все пользователи сети INTERNET могли получать данные зоны,
необходимо на всех днс-серверах разрешить прохождение UDP-пакетов на 53-ий
порт. Так же необходимо на primary-сервере разрешить прохождение TCP-пакетов
на 53-ий порт от всех secondary-серверов. Это необходимо для обновления
файла зоны.

Конфигурация файла зоны
Сначала описываются параметры зоны

$TTL 86400
@ IN SOA primary-сервер. e-mail_администратора_домена. (
2005010700 ; Serial
3600 ; Refresh
600 ; Retry
3600000 ; Expire
86400 ) ; Minimum TTL


$TTL 86400- время жизни, директива устанавливает
стандартное время жизни (Time-to-Live - TTL)
для любой записи, в которой значение
времени жизни не задано.
SOA - запись SOA (Start-of-Authority - Начало
полномочий)
primary-сервер.- primary name-сервер
e-mail_администратора_домена.- e-mail лица , ответственно за доменю.
Вместо @ пишется точка
2005010700 ; Serial- Серийный номер. Число, которое необходимо
увеличивать при любом изменении файла зоны. На основе изменений name-сервера
решают, необходимо ли перечитывать конфигурацию зоны. Можно использовать
любое число(главное увеличение этого числа после внесения изменений), но
принято в поле писать текущую дату изменений в формате ГГГГММДДНН
(последние две цифры - порядковый номер изменения за текущие сутки)
3600 ; Refresh- запись предназначена для
secondary-серверов, задает интервал обновлений данных
зоны. Поводом к обновлению служит
изменившийся Serial
600 ; Retry- время повторения попытки обновления (Refresh) после сбоя
3600000 ; Expire- - максимальное время использования данных о
зоне secondary name-серверами при отсутсвии
возможности выполнить Refresh
86400 ) ; Minimum TTL- запись предназначена для кеширующих
серверов, задает минимальное время использования данных зоны
кеширующими серверами

Далее в файле зоны идут записи о ресурсах RR (Resource Record) в формате

<name> [<ttl>] [<class>] <tipe> <data>

<name>- поле имени.
[<ttl>]- время жизни, если необходимо задать
отличное от глобально-заданого
[<class>]- поле класса, задает группу протоколов,
актуальным на данный момент остался один
класс INTERNET (сокращенно IN).
<tipe>- поле типа указывает тип записи RR
Основные типы:
A- IP-адрес, указывает на хост,
которому соотвествует данное имя
MX- почтовый шлюз, обслуживающий
данную зону. После типа необходимо
указать приоритет почтовых шлюзов в
числовом виде, наименьшему значению
соответствует наибольший приоритет.
CNAME- Псевдоним. Удобно использовать при
смене имени хоста.
<data>- поле данных, определяется по-разному в
зависимости от <tipe>


Перейдем к практике, потому как я готов оспорить фразу:
"Знание теории освобождает от знания практики"


Предлагаю выступить в роли администратора домена ru-board.com. :)
Для начала нужно определится, какие сервера будут обслуживать зону, т.е.
являтся авторитативными и выбрать из них primary. primary-сервером определяем
ns1.ru-board.com., и выделяем для secondary еще 2 : ens1.eastera.net. и ns.saturn.tj.
Теперь их нужно соответствующим образом настроить:

В named.conf на ns1.ru-board.com. добавляем следующие данные

named.conf ----------------------------------------------------
zone "ru-board.com" {
type master;
file "ru-board.com";
};
---------------------------------------------------------------

Создаем файл зоны ru-board.com ( обычно создается в том же каталоге, где
расположен named.conf)

ru-board.com --------------------------------------------------
$TTL 86400
@ IN SOA ns1.ru-board.com. admin.ru-board.com. (
2005010600 ; Serial
3600 ; Refresh
600 ; Retry
3600000 ; Expire
86400 ) ; Minimum TTL

IN NS ns1.ru-board.com.
IN NS ns.saturn.tj.
IN NS ens1.eastera.net.

IN MX 10 mail.ru-board.com.

mail IN A 65.75.176.221
---------------------------------------------------------------

В named.conf на серверах ens1.eastera.net. и ns.saturn.tj. добавляем следующие данные
named.conf ----------------------------------------------------
zone "ru-board.com" {
type slave;
file "ru-board.com" ;
masters { 65.75.176.228; };
---------------------------------------------------------------

Заставляем BIND перечитать файл конфигурации на name-серверах
# rndc reload ( # ndc reload - для BIND 8-ой версии )

Проверяем
$ dig ru-board.com @65.75.176.228 soa
$ dig ru-board.com @ns.saturn.tj soa
$ dig ru-board.com @ens1.eastera.net soa

Если получаем 3 одинаковых ответа:

; <<>> DiG 9.2.4 <<>> ru-board.com @65.75.176.228 soa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23365
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; QUESTION SECTION:
;ru-board.com. IN SOA

;; ANSWER SECTION:
ru-board.com. 3600 IN SOA ns1.ru-board.com. admin.ru-board.com. 1088096129 5400 600 1814400 3600

;; AUTHORITY SECTION:
ru-board.com. 3600 IN NS ns.saturn.tj.
ru-board.com. 3600 IN NS ns1.ru-board.com.
ru-board.com. 3600 IN NS ens1.eastera.net.

;; ADDITIONAL SECTION:
ns1.ru-board.com. 3600 IN A 65.75.176.228

;; Query time: 203 msec
;; SERVER: 65.75.176.228#53(65.75.176.228)
;; WHEN: Sat Jan 8 02:17:34 2005
;; MSG SIZE rcvd: 162


Значит name-сервера и зона настроены корректно.
И только после того , как убедились , что зона корректно настроена,
отправляем заявку на регистрацию домена.

Данное руководство не охватывает в полной мере всех настроек BIND, кому
интересно, тот может обратиться к RFC или книгам. Книг написано достаточно
много, есть переведенные на русский и достаточно грамотно. Целью же данного
руководства было описание процесса пошаговой настройки BIND-а.


Замечания.
----------------------------------------------------------------------------

Для того, чтобы все пользователи сети INTERNET могли получать данные зоны,
необходимо на всех днс-серверах разрешить прохождение UDP-пакетов на 53-ий
порт. Так же необходимо на primary-сервере разрешить прохождение TCP-пакетов
на 53-ий порт от всех secondary-серверов. Это необходимо для обновления
данных зоны secondary-серверами.

----------------------------------------------------------------------------

Обратите внимание на точки в RR-записях, это не опечатка и не просто так.
Например записи
IN NS ns1.ru-board.com.

ru-board.com. IN NS ns1.ru-board.com.

ru-board.com. IN NS ns1

IN NS ns1


различны в написании, но полностью идентичны по функциональности. Если имя
или данные не заканчиваются на точку, то BIND добавляет к имени индекс зоны.
Если мы не поставим точку в записи
IN NS ns1.ru-board.com

, то окажется, что зону обслуживает сервер ns1.ru-board.com.ru-board.com

----------------------------------------------------------------------------

Что такое glue-record.

Допустим мы делегируем зону users.ru-board.com, а один из name-сервера будет
расположены в делегируемой зоне и иметь имя fire.users.ru-board.com.
Тогда в файл зоны ru-board.com добавим следующие записи

users IN NS ns1.ru-board.com.
IN NS secondary-ns

fire.usersIN A193.193.193.193 (ip-адрес хоста fire.users.ru-board.com)

Запись
fire.users IN A 193.193.193.193

как раз и есть glue-record.

----------------------------------------------------------------------------

Из предыдущего примера.
Запись

users IN NS ns1.ru-board.com.
IN NS secondary-ns

будет равносильна записи:

users IN NS ns1.ru-board.com.
users IN NS secondary-ns

но запись

users IN NS ns1.ru-board.com.

IN NS secondary-ns

будет иметь совсем другое значение.

Данные полей <name> и <class> предыдущей RR-записи имет влияние на следующие за ними RR-записи,
если в следующих не заданы другие параметры. Чтобы следующие RR-записи не
подвергались данному воздействию необходимо записи разделять пустой строкой.

Может кто сталкивался...
Работало все вроде бы Оки, и вдруг... безо всякой на то причины (ну не менялось ничего!)

Домен Windows 2000 mixed, 2 контроллера, один (PDC Emulator & Master for all) - Win2003 Server Corporate Edition SP1; второй - Windows 2000 Server SP3.
Второй параллельно работает как файл-сервер (куча расшаренных папок)... Так вот в нем и проблема... Вдруг оказалось, что клиенты на Windows XP SP1 Professional не могут зайти в шары. То, чем заходишь - виснет намертво. Проходит минут 10 пока получается зайти... Интересный факт - запускаешь второе окно и пытаешься снова зайти - заходит моментом в ту же папку, заходишь на другую шару - снова тормозит...
Кроме того некоторые машины (не все, у которых такая проблема) заходят в домен по 10 минут на стадии "Применение параметров компьютера..."

Что делали:
1. Ставили QoS, в отключенном и включенном состоянии - не помогло.
2. Добавляли в hosts.txt строку с IP этого контроллера - не помогло.

Потом вроде помогла комбинация - выключенный QoS и строка в hosts.txt

Решили посмотреть DNS...
Обнаружилось, что на обоих контроллерах поднят DNS Server при этом в логах ошибка 6702
Цитата:

(DNS server has updated its own host (A) records. In order to ensure that its DS-integrated peer DNS servers are able to replicate with this server, an attempt was made to update them with the new records through dynamic update. An error was encountered during this update, the record data is the error code. If this DNS server does not have any DS-integrated peers, then this error should be ignored.)

Снесли DNS на той что Windows 2000 Server.
Заработало!
Но всего на полчаса...
Снова та же история началась и медленно заходим в домен и в папки по 10 минут...

???

есть файл зони, можна ли в нем написать так
host IN A 10.0.0.1
www IN A 10.0.0.1
тоесть може ли бить 2 зиписи А для одного IP-адреса,
или нужно (обязательно) использовать CNAME
www IN CNAME host

и 2-ой вопрос:
если есть 2 интерфейсы то можна ли записать

comp IN A 192.0.0.1
comp IN A 193.0.0.3

????????????????

Цитата:

есть файл зони, можна ли в нем написать так
host IN A 10.0.0.1
www IN A 10.0.0.1
тоесть може ли бить 2 зиписи А для одного IP-адреса,
или нужно (обязательно) использовать CNAME
www IN CNAME host

можно и так и так. Суть второго метода в том, что если ты меняешь а запись для host, то она автоматом меняется и для www. В пределах одной зоны это значения не имеет, но вот если сим-линк смотрит в другую зону - это уже становится интересно, меньше телодвижений надо делать.
Пример. У тебя есть зона. Зону держишь ты у себя. У тебя есть сайт, сайт ты держишь у хостера. Если хостер поменяет айпишник своего сервера, то в случае с сим-линком тебе ничего не придется в свой зоне исправлять.


Цитата:

comp IN A 192.0.0.1
comp IN A 193.0.0.3

да , легко. это делается для разгрузки сервера.

Допустим есть сайт с миллионом уников. Один сервер такого не выдержит.
При запросе днс-сервер отдает удаленному резолверу айпишники по-очереди. Используется для разделения нагрузки

Подскажите как ?
Имеется пограничный маршрутизатор с ДНС на борту под фриибсд (Named 9.2 Free 5.4).
Имеется 2 "View" с зонами для интернал и экстернал соответственно. Вопрос: в какой VIEW прописывать зоны типа "." "127.in-addr.arpa" "255.in-addr.arpa" "localnet"?
Как ПРАВИЛЬНО сказать другим внутренним серверам (слейвам) что "ресолвим что знаем. что не знаем спрашиваем ТОЛЬКО у мастера. К корневым не лезем совсем"?

Цитата:

Имеется 2 "View" с зонами для интернал и экстернал соответственно. Вопрос: в какой VIEW прописывать зоны типа "." "127.in-addr.arpa" "255.in-addr.arpa" "localnet"?

вообщето эти зоны прописаны. Не трогай их . 255.in-addr.arpa - это вообще нафига надо ?


Цитата:

Как ПРАВИЛЬНО сказать другим внутренним серверам (слейвам) что "ресолвим что знаем. что не знаем спрашиваем ТОЛЬКО у мастера. К корневым не лезем совсем"?

читаем доки.
http://ru-board.com/new/article.php?sid=161

to tankistua:
зоны 127.... 255.... изначально в поставке бинда. Зачем нужны? Подумай сам.
При прописывании "view" ВСЕ зоны должны быть внутри эти "view" (т.е. описания зон вне каких-либо "view" недопускаются). Вот я и хотел узнать КАК ПРАВИЛЬНО их разносить по "view"ам....

А в ссылке что ты дал нет ни слова об этом - читай сам.