Есть сервер к которому у меня рутовские права. Есть два IP в разных зонах класса C. Вопрос: как поднять primary & secondary DNS на одной машине? Если точнее то есть три домена второго уровня ensk.ru, rene.ru, vipdors.ru и куча субдоменов зоне ensk.ru. Надо чтобы работали сайты и почта .. уфф...Если не сложно, то укажите последовательность действий, какие файлы редактировать.
BIND 9, Red Hat Linux...
>BIND 9, Red Hat Linux...Читал вот это
http://www.citforum.ru/operating_systems/linux_nag/linuxnag_...
и вот это
http://mgul.ac.ru/~t-alex/Linux/item/dns00.htmНо пока к применению знаний полученных в результате чтения не готов. слегка все запутано.
>>BIND 9, Red Hat Linux...
>
>Читал вот это
>http://www.citforum.ru/operating_systems/linux_nag/linuxnag_...
>и вот это
>http://mgul.ac.ru/~t-alex/Linux/item/dns00.htm
>
>Но пока к применению знаний полученных в результате чтения не готов. слегка
>все запутано.
На одной машине primary и secondary поднять нельзя. Поднимаешь у себя primary, потом выбиваешь у провайдера поддержку secondary DNS и все дела.
По поводу настройки primary почитай https://www.opennet.ru/docs/RUS/dns2/index.html
и https://www.opennet.ru/docs/RUS/bind-8/index.html
И почему же нельзя? Если два демона прицепить на два разных ip и назначить их master-slave - должно работать. Другое дело, что по правилам master-slave должны быть в разных подсетях... :))
>И почему же нельзя? Если два демона прицепить на два разных ip
>и назначить их master-slave - должно работать. Другое дело, что по
>правилам master-slave должны быть в разных подсетях... :))Мы говорим об одном и том же, только в разное время. Я с тобой полностью согласен.
Два named.conf, два набора зонных файлов. Соответственно, два демона, запущенных с параметром '-с'. В named.conf прописать ip, по которому каждый демон будет слушать (options { listen-on { ip; } }). В общих чертах, всё. Желательно прочитать BIND9 Administrator Reference Manual (см в пакете BIND в docs). Очень полезно для полной ясности DNS and BIND, Cricket Liu & Paul Albitz, O'Reilly.
>Два named.conf, два набора зонных файлов. Соответственно, два демона, запущенных с параметром
>'-с'. В named.conf прописать ip, по которому каждый демон будет слушать
>(options { listen-on { ip; } }). В общих чертах, всё.
>Желательно прочитать BIND9 Administrator Reference Manual (см в пакете BIND в
>docs). Очень полезно для полной ясности DNS and BIND, Cricket Liu
>& Paul Albitz, O'Reilly.
Если на машине стоит primary, но secondary на ней же поднять нельзя. Сервера, на которых находятся primary и secondary зоны обязательно должны быть в разных подсетях, и 2 демона здесь непричем. Они могут помочь, если надо отделить внутреннее пространство имен от внешнего.
Т.е. физически нельзя? Я сам такого делать не пробовал, потому как бессмысленно %) Но просто интересно. :)
>Т.е. физически нельзя? Я сам такого делать не пробовал, потому как бессмысленно
>%) Но просто интересно. :)
Да, в этом случае робот не будет апдейтить зоны.
Народ скажите если настроил первичный ДНС для локалки, а как мне сослаться на ДНС провайдера, если запрос идущий с моей локалки обработанный ДНС, и IP адрес не найден то должен идти во внешнюю сеть, на ДНС провайдера? И найдя там IP адрес запрашиваемого сайта провайдера без проблем идти на этот сайт, у меня почему-то этот запрос пересылается на мой сайт? А если сделать ДНС провайдера, то такая штука работает, так вот как это связать?
>Народ скажите если настроил первичный ДНС для локалки, а как мне сослаться
>на ДНС провайдера, если запрос идущий с моей локалки обработанный ДНС,
>и IP адрес не найден то должен идти во внешнюю сеть,
>на ДНС провайдера? И найдя там IP адрес запрашиваемого сайта провайдера
>без проблем идти на этот сайт, у меня почему-то этот запрос
>пересылается на мой сайт? А если сделать ДНС провайдера, то такая
>штука работает, так вот как это связать?
В named.conf в секцию options:
forwarders {111.222.333.444; };111.222.333.444 - dns-сервер провайдера
>>Т.е. физически нельзя? Я сам такого делать не пробовал, потому как бессмысленно
>>%) Но просто интересно. :)
>Да, в этом случае робот не будет апдейтить зоны.
А почему, собственно? У него же есть эти два IP из разных сеток? Или робот еще и trace делает?
>>>Т.е. физически нельзя? Я сам такого делать не пробовал, потому как бессмысленно
>>>%) Но просто интересно. :)
>>Да, в этом случае робот не будет апдейтить зоны.
>А почему, собственно? У него же есть эти два IP из разных
>сеток? Или робот еще и trace делает?
Не понял, в чем вопрос, однако:
При настройке DNS необходимы 2 прямые зоны - primary и secondary. Primary поднимается на собственном сервере, а secondary _обязательно_ должна находиться в _другой_ подсети. В противном случае зона не пройдет тестирование и не будет делегирована.
Ну, это уже другой вопрос :) Делегирована RIPN естественно не будет, но физически такая схема работать должна - т.е. slave должен стаянуть с master зоны и начать отвечать на запросы. Разные подсетки для master-slave - это чисто организационное требование.
>Ну, это уже другой вопрос :) Делегирована RIPN естественно не будет, но
>физически такая схема работать должна - т.е. slave должен стаянуть с
>master зоны и начать отвечать на запросы. Разные подсетки для master-slave
>- это чисто организационное требование.
А, ну если вопрос в этом - то конечно. Полностью согласен.
>Ну, это уже другой вопрос :) Делегирована RIPN естественно не будет, но
>физически такая схема работать должна - т.е. slave должен стаянуть с
>master зоны и начать отвечать на запросы. Разные подсетки для master-slave
>- это чисто организационное требование.не чисто, организационно-технологическое.
работать будет, только на кой сие городить, ибо технически бесполезно,
лег канал, легла тачка, хакнули тачку и убили bind и тд и тп
Оно ж усе на одной машинке, запустить то можно много bind'ов, а вот толку
то от этого?
>>Ну, это уже другой вопрос :) Делегирована RIPN естественно не будет, но
>>физически такая схема работать должна - т.е. slave должен стаянуть с
>>master зоны и начать отвечать на запросы. Разные подсетки для master-slave
>>- это чисто организационное требование.
>
>не чисто, организационно-технологическое.
>работать будет, только на кой сие городить, ибо технически бесполезно,
>лег канал, легла тачка, хакнули тачку и убили bind и тд и
>тп
>Оно ж усе на одной машинке, запустить то можно много bind'ов, а
>вот толку
>то от этого?
С точки зрения тог, для чего это придумано -- надежности -- никакого толку.
толк единственный -- экономия. Мой провайдер, к примеру, за держание у себя слэйва требует 5 баксов в месяц за зону. Вот и сидят мастер и слэйв на соседних машинах.А у человека еще и второй машины нет, насколько я понял.
Вот и выкручивается.
>толк единственный -- экономия. Мой провайдер, к примеру, за держание у себя
>слэйва требует 5 баксов в месяц за зону. Вот и сидят
>мастер и слэйв на соседних машинах.
>
>А у человека еще и второй машины нет, насколько я понял.
>Вот и выкручивается.у нас в городе тоже есть один такой провайдер. выходит 60 баксов в год. что совсем уж заоблачно. прову этому конечно все пофиг, так как это гос. структура и эти цены у него года четыре не менялись. но такой у нас один.
к тому же всегда есть RU-CENTER, у которого цены очень доступны:
http://www.nic.ru/dns/contract/sup2_price.html
>>>Ну, это уже другой вопрос :) Делегирована RIPN естественно не будет, но
>>>физически такая схема работать должна - т.е. slave должен стаянуть с
>>>master зоны и начать отвечать на запросы. Разные подсетки для master-slave
>>>- это чисто организационное требование.
>>
>>не чисто, организационно-технологическое.
>>работать будет, только на кой сие городить, ибо технически бесполезно,
>>лег канал, легла тачка, хакнули тачку и убили bind и тд и
>>тп
>>Оно ж усе на одной машинке, запустить то можно много bind'ов, а
>>вот толку
>>то от этого?
>С точки зрения тог, для чего это придумано -- надежности -- никакого
>толку.
>толк единственный -- экономия. Мой провайдер, к примеру, за держание у себя
>слэйва требует 5 баксов в месяц за зону. Вот и сидят
>мастер и слэйв на соседних машинах.
>
>А у человека еще и второй машины нет, насколько я понял.какой толк от второй машины если она в той же сети?
>Вот и выкручивается.
есть www.nic.ru - вполне доступные цены
есть форумы и фидошные конференции где всегда можно бесплатно договориться
с кем-то во вне взаимно держать slave'ы (обмен)
есть друзья или знакомые которых находят на форумах или конференциях
я же специально спросил "физически невозможно?" - мне ответили, "да физически". Понятно, что все яйца в одной корзине - это полная з... т.е. ж... :)))
Что за робот? И зачем их аптейтить? slave просто должен стянуть с master зону и отвечать на запросы... Или я чего не понимаю? :)
>Что за робот? И зачем их аптейтить? slave просто должен стянуть с
>master зону и отвечать на запросы... Или я чего не понимаю?
>:)
Я имею ввиду автоматическую систему тестирования зон. И в данном случае я говорил не о master-slave а о primary-secondary. Разные вещи.
"The DNS specs define two types of name servers: _primary masters_ and _secondary masters_. A primary master name server for a zone reads the data for the zone from a file on its host. A secondary master name server for a zone gets the zone data from another name server that is authoritative for the zone, called its master server. Quite often, the master server is the zone's primary master, but that's not required: a secondary master can load zone data from another secondary. When a secondary starts up, it contacts its master name server and, if necessary, pulls the zone data over. This is referred to as a zone transfer. Nowadays, the preferred term for a _secondary master_ name server is a _slave_, though many people (and much software, including Microsoft's DNS Manager) still call them secondaries."DNS and BIND, 3-rd edition
Где разница? :) "Не в интересах правды, а в интересах истины..."
>"The DNS specs define two types of name servers: _primary masters_ and
>_secondary masters_. A primary master name server for a zone reads
>the data for the zone from a file on its host.
>A secondary master name server for a zone gets the zone
>data from another name server that is authoritative for the zone,
>called its master server. Quite often, the master server is the
>zone's primary master, but that's not required: a secondary master can
>load zone data from another secondary. When a secondary starts up,
>it contacts its master name server and, if necessary, pulls the
>zone data over. This is referred to as a zone transfer.
>Nowadays, the preferred term for a _secondary master_ name server is
>a _slave_, though many people (and much software, including Microsoft's DNS
>Manager) still call them secondaries."
>
>DNS and BIND, 3-rd edition
>
>Где разница? :) "Не в интересах правды, а в интересах истины..."что подразумевается под разницей?
PS. Хорошие книги - это верный подход, но истину обычно выясняют по RFC,
которые тоже устаревают и дополняются, так что истина в технологичности.