Slave DNS И Plesk: зачем нужны 2 ДНС сервера и как их настроить

Единственное неудобство в том, что вам приходится создавать и удалять каждую зону на обоих серверах, так как это автоматически не происходит. Вот почему вы создаёте доменную зону на master сервере и потом создаёте эту же доменную зону на slave сервере и указываете адрес master сервера. После того, как вы добавили ресурсные записи домена на master сервер, можете быть уверены, что slave сервер будет автоматически получать их от master сервера.

На протяжении многих лет интеграция Plesk и slave DNS сервера была непростой задачей. Подразумевается, что сервер Plesk должен быть master сервером. В Plesk есть режимы slave и master для доменной зоны и есть список ip адресов , которые отдаются доменной зоной . Но в плеск нет механизма создания новой доменной зоны на slave сервере. И этого механизма никогда не будет, потому что концепция плеск — это автоматизация хостинговых процедур на одном сервере. Для интеграции нескольких серверов разделённых для работы по видам сервисов, компания Parallels предлагает использовать продукты PPA (Parallels Plesk Automation) и PA (Parallels Automation).

На данный момент существует множество пользователей Plesk для которых решения PPA или РА превосходят их необходимые потребности для работы, так как им необходима только интеграция slave сервера. Ранее для решения этой проблемы каждый администратор Plesk должен был писать скрипты или приобретать коммерческие версии или вручную создавать и удалять доменные зоны на slave сервере.

Казалось бы, какие могут быть трудности. В Plesk есть собственный локальный сервер имён, который, предположим, будет master сервер. И есть система событий — давайте назначим исполнение нашего скрипта на события «создание DNS зоны» и «удаление DNS зоны» и проблема будет решена. Но, к сожалению, Plesk не поддерживает такие события.

Программисты Plesk не только разрабатывают одноименный продукт, но и пользуются своими разработками. Вот почему создали расширение, которое позволяет пользователям интегрировать Plesk с внешним slave сервером с установленным BIND9 . Скачать это расширение можно здесь

КАК ЭТО РАБОТАЕТ

Plesk использует BIND как локальный сервер имён. Им можно управлять удалённо с помощью штатной утилиты rndc . Нет причин, по которым мы не можем установить BIND на удалённом сервере и управлять им с помощью rndc. В Plesk 12.5 реализован механизм “Custom DNS backend”, который может быть использован для подключения внешнего DNS сервиса, например AWS Route53.

Если вкратце, то этот способ позволяет зарегистрировать в Plesk скрипт, который будет получать описание DNS зоны в JSON формате с инструкциями для исполнения, такими как создание, изменение, удаление любой DNS зоны в Plesk. Это то, что нам нужно. Реализовывая этот функционал, Plesk подразумевали, что будет использоваться внешний DNS сервис вместо того, чтобы устанавливать BIND сервер в Plesk.

Также нет нужды удалять локальный сервер BIND . Этот скрипт может одновременно работать с локальной DNS службой. Такова идея использования данного расширения.

Это расширение работает по следующему алгоритму:

Регистрируется slave сервер в своих настройках скрипта
IP адрес slave сервер автоматически добавляется в список адресов разрешённых для трансфера доменных зон из сервера Plesk
Когда вы создаёте, меняете или удаляете активную зону домена в Plesk , то эти действия происходят на локальном DNS сервере
После этого скрипт запускается , получает доменное имя и выполняет соответствующую операцию
Скрипт инициирует команду rndc для каждого подключённого slave сервера
Slave серверы синхроинизируют доменные зоны с сервером Plesk.

Все настройки, такие как формат зоновых файлов, подключение и перезапуск служб управляются службой DNS. Администратор должен настроить slave сервер для работы с внешним сервером Plesk только один раз. После этого вы можете сообщить регистратору, что теперь Plesk сервер и slave сервер являются серверами имён для ваших доменов. Таким образом мы решили все вопросы обозначенные в начале статьи.

А ТЕПЕРЬ О ТЕХНИЧЕСКОЙ СТОРОНЕ — КАК РЕШИТЬ ЗАДАЧУ

Для установки slave сервера возьмём, к примеру, сервер с Centos 7

Установка BIND

В начале проверим что система имеет все последние обновления.

Если не указать "-y" ключ, то придется отвечать на все вопросы установщика, а с ним все ответы ставятся автоматически по умолчанию.

Установить bind и bind-utils
yum install bind bind-utils -y

Разрешим создание новых зон с помощью rndc. В файле /etc/named.conf, в фигурных скобках <>, напишите директиву:

Укажите ip адрес от которого должны быть приняты инструкции управления и установите BIND для прослушивания на всех доступных сетевых интерфейсах. Определите ключ rndc , который будет использоваться Plesk . В файле /etc/named.conf напишите:

Вот и всё, slave сервер установлен.

После этого установите расширение на сервере Plesk . В настройках расширения добавьте slave сервер, установите его ip адрес и ключ . Расширение создаст конфигурационный файл с настройками slave севрера для утилиты rndc.

Теперь Plesk будет автоматически передавать все созданные изменённые и удалённые зоны на slave сервер при выполнении следующей команды для каждого slave сервера:

# Изменение
/usr/sbin/rndc -c slave.config refresh example.com

# Удаление
/usr/sbin/rndc -c slave.config delzone example.com

Сейчас , когда вы добавили домен в Plesk, его ДНС зона автоматически создалась на slave сервер аналогично как на master сервере. Расширение (Slave DNS manager) доступно для загрузки здесь

Обращаем внимание, что Plesk не пр оводит техподдержку для для данного расширения . Это расширение лишь пример как можно решить техническую задачу.

Читайте так же:

Материнская плата asus p55

Перенос сайта на другой сервер: как прописать DNS домена

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

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

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

Что нужно знать, чтобы перенаправить домен на новый сервер

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

У каждого сайта есть доменное имя (Domain), которое отображается в строке браузера, например, liderpoiska.ru, и IP-адрес — уникальный сетевой адрес сервера, например, 37.139.7.16. Они связаны между собой посредством DNS (Domain Name System) — эта система доменных имен, как секретный агент, по имени домена вычисляет, по какому IP-адресу проживает конкретный сайт.

Схема работы DNS-сервера

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

Таким образом, чтобы направить домен на новый IP-адрес, нам нужно знать:

Доступ к панели управления доменом (в личный кабинет регистратора домена). Им может выступать nic.ru, reg.ru, webnames.ru и т.д.
Новый IP-адрес размещения сайта.
Провайдера DNS, который позволит отредактировать DNS-записи домена. Если вы пока не понимаете, о чем тут речь, то следующая глава поможет вам разобраться.
Есть ли корпоративная почта на домене. Например, для сайта liderpoiska.ru корпоративная почта выглядит, как info@liderpoiska.ru. Если такая почта есть, то нужно также узнать сервер, принимающий почту для вашего домена — это может быть Яндекс, Google, хостер или сторонний почтовый сервер.

Где находится DNS домена

Для начала разберемся, как узнать DNS-провайдера, чтобы понять, где хранится DNS. Для этого достаточно вбить домен сайта в сервис Whois и посмотреть значение в строках nserver:

Наиболее часто встречаются значения:

dns1.yandex.net, dns2.yandex.net — домен делегирован на Яндекс.Коннект.
в записях просматривается название хостера, например ns3.nic.ru, ns1.firstvds.ru, ns1.beget.com, ns1.reg.ru и другие — провайдером DNS является соответствующий хостер и/или регистратор домена: nic.ru, firstvds.ru, beget.com, reg.ru.
в строке читается комбинация символов AWSDNS — провайдер Amazon.

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

Как настроить DNS

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

Если домен делегирован на Яндекс.Коннект

NS-записи такого вида в кабинете регистратора домена говорят о том, домен делегирован на Яндекс.Коннект, т.е. DNS-записи хранятся и редактируются в аккаунте Яндекса в настройках сервиса Вебмастер. Самое сложное в этом случае — найти доступы от аккаунта в Яндексе (вида @yandex.ru), под которым домен был заведен в Коннекте.

Чтобы изменить DNS, нужно кликнуть на «Управление DNS» соответствующего домена:

DNS-записи здесь уже заполнены, нужно только указать новый IP-адрес для записи типа А, которая связывает IP с доменным именем:

Готово! Обновление DNS-записей домена происходит в течение 72 часов, но по нашему опыту у некоторых провайдеров сайт начинает открываться уже через пару часов.

Если домен делегирован на хостинг

В личном кабинете регистратора домена можно также встретить NS-записи другого вида:

Конкретно в этом случае они означают, что домен делегирован на хостинг firstvds.ru, значит, и DNS-записи хранятся там. Дальнейшие действия зависят от того, куда переносим сайт.

Перенос сайта на другой сервер того же хостера

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

Перенос сайта на другой хостинг

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

Шаг 1: Перенос DNS на другой сервер

В Личном кабинете нового хостера необходимо найти место, где прописываются DNS, и прописать такие же записи, как у прежнего хостера, за исключением записи типа A — здесь нужно будет указать IP-адрес нового сервера.

Шаг 2: Проверка MX-записей домена

При переносе ресурсных записей существует опасность неправильной настройки MX-записей, которые сообщают различным почтовым программам о том, где находится нужный почтовый сервер. Если не перенести MX-записи с прежнего сервера или заполнить их некорректно, владелец сайта может остаться без почты на домене на долгий срок — он сможет отправлять письма, но входящие получать не будет. При этом отправитель письма на почтовый ящик на домене после отправки получит следующее уведомление:

Читайте так же:

Материнская плата 1155 sli

Если в течение трех суток MX-записи не будут настроены правильным образом, то неполученные письма потеряются навсегда, при этом отправитель получит уведомление о том, что письмо не доставлено.

Если в указанный срок проблема все же будет устранена, то входящие письма не потеряются, а придут позже, когда DNS-серверы в интернете обменяются данными о новых DNS-записях. Обновление DNS-записей занимает от 2 до 72 часов.

Шаг 3: Настройка NS-записей

После настройки ресурсных записей необходимо указать NS-записи нового хостера в личном кабинете регистратора домена — перенаправить домен на новый хостинг. Узнать, как должны выглядеть NS-записи для нового хостинга можно в справочных материалах, который предоставляет хостер при покупке тарифа, либо обратившись в службу технической поддержки хостинга. Стоит быть особенно внимательными — при неправильном заполнении NS-записей домена сайт не заработает при обновлении DNS-серверов.

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

Владелец сайта хранит на прежнем хостинге несколько сайтов.

В этом случае переносить DNS-записи и перенаправлять NS-сервера домена в панели управления доменом на другой хостинг не обязательно — они могут храниться в прежнем месте. Необходимо только изменить записи типа A, указав IP-адрес нового сервера.

Так случилось с нашим клиентом — домен его сайта куплен через провайдера Majordomo, который кроме хостинга еще предоставляет услугу регистрации домена. У данного провайдера NS-записи и DNS хранятся и редактируются в одном месте. В этом случае так же не требуется правка NS-записей и перенос DNS в другое место, достаточно в записи типа А указать новый IP-адрес.

TCP/IP и DNS

DNS , как и все остальные компоненты WS03, администрируется при помощи консоли MMC (см. рис. 8.11). Консоль MMC DNS открывается с помощью команды StartAdministrative Tools DNS (ПускАдминистрирование DNS ).

В консоли DNS в левой области под именем компьютера располагаются три компонента: Event Virewer (Просмотр событий), Forward Lookup Zones (Зоны прямого поиска) и Reverse Lookup Zones (Зоны обратного поиска).

Просмотр событий

Секция Event Viewer содержит часть DNS Events (События DNS) обычной программы просмотра событий. Это делает консоль DNS универсальным средством управления сервером доменных имен. Опции управления данной секции соответствуют опциям, доступным при обычном просмотре событий.

Зоны прямого поиска

Секция Forward Lookup Zones (Зоны прямого поиска) выводит список всех зон прямого поиска компьютера для обычных записей домена DNS (A, SRV, MX и т.д.).

Для создания зоны прямого поиска выполните следующие шаги.

Откройте консоль DNS MMC.
Щелкните правой кнопкой мыши на пункте Forward Lookup Zones (Зоны прямого поиска), затем во всплывающем меню выберите New Zone (Создать зону).
Откроется мастер создания новых зон (New Zone Wizard). Нажмите на кнопку Next (Далее).
Выберите тип создаваемой зоны, затем отметьте опцию Store In Active Directory (Сохранить в Active Directory), если она доступна.
Введите имя зоны.
Укажите имя файла, который будет использоваться (если не AD).
Разрешите/запретите динамические обновления.
Нажмите на кнопку Finish (Готово).

После создания зоны обратного поиска можно создать записи. Самым распространенным типом записи является Address (Адрес), поэтому мы начнем именно с нее.

Откройте консоль DNS.
Щелкните правой кнопкой мыши на зоне, в которую нужно добавить записи, и выберите New Other Records (Создать другие записи). Отобразится перечень всех типов записей, которые можно расположить в данной зоне.
Укажите нужный тип записи. В нашем примере следует указать Host(A).
Нажмите на кнопку Create Record (Создать запись). Появится окно New Resurce Record (Новая запись ресурса).
Введите имя узла. При создании веб-сайта в качестве имени узла обычно указывается WWW.
Введите IP-адрес узла.
Если есть зона обратного поиска, и вы хотите обновить обратную запись, отметьте опцию, после чего произойдет ее автоматическое обновление.
Нажмите на кнопку OK.
Нажмите на кнопку Done (Готово) для закрытия окна Resouce Record type (Тип записи ресурса).

Зоны обратного поиска

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

Совет. Следует заметить, что несовпадение обратного и прямого адресов не обязательно является тревожным признаком. Клиенты ISP часто используют характерные имена обратного просмотра, например, в коммерческих доменах, особенно в электронной почте. Многие серверы электронной почты игнорируют почту, если почтовый сервер отправителя не соответствует прямому и обратному DNS.

Давайте рассмотрим пример, связанный с работой зон обратно поиска. Предположим, кто-то представился под именем mail.someisp.com и IP-адресом – 55.56.57.58 . При проверке обратного соответствия выясняется, что данный IP-адрес принадлежит имени spamalot.badmail.com . С точки зрения безопасности здесь что-то не так. Именно для этого и предназначены обратные DNS-адреса.

Как функционируют зоны обратного поиска

Зоны обратного поиска аналогичны зонам прямого поиска, за исключением двух важных отличий. Все IP-адреса являются частью одного домена с именем in-addr. arpa . Этот домен является полномочным для всех операций поиска имен по IP-адресам. Такие домены делегируются посредством блоков IP-адресов. Например, для IP-блока класса C адресов 192.168.0.0 / 24 ( 192.168.0.0 – 192.168.0.255 ) зоной обратного поиска в DNS является 0.168.192.in-addr. arpa . Обратные зоны присваиваются в обратном порядке. Часть IP-адреса, представляющая собой номер сети, формирует зону, а номера узлов образуют записи PTR.

Читайте так же:

Именная карта путешественника с флажками

Ниже приведены несколько примеров.

Блок IP	Маска подсети	Зона обратного поиска
10.0.0.0	255.0.0.0	10.in-addr. arpa
145.162.0.0	255.255.0.0	162.145.in-addr. arpa

Обратный адрес DNS делегируется блоком IP, начиная с верхнего блока вниз до используемого вами блока. Это означает, что адреса класса A делегируются с первого октета, адреса класса B – со второго октета, а адреса класса С – с третьего октета.

Рассмотрим последовательность преобразования IP-адреса в имя посредством обратного поиска DNS.

Клиенту нужно выяснить, кем является определенный IP-адрес, скажем, 55.66.77.88 . Клиент спрашивает у DNS-сервера: «Кто такой 88.77.66.55.in-addr. arpa ?».
Поскольку это адрес класса A, начинаем с первого октета. DNS-сервер начнет с опроса корневых серверов: «Кто такой 88.77.66.55.in-addr. arpa ?».
Корневой сервер отвечает, что ему это не известно, но 0.0.0.55.in-addr. arpa принадлежит MongoISP.
DNS-сервер спрашивает у DNS-сервера провайдера MongoISP: «Кто такой 88.77.66.55.in-addr. arpa ?».
DNS-сервер провайдера MongoISP отвечает, что ему это не известно, однако ему принадлежит 0.0.0.55.in-addr. arpa , и он делегировал 0.0.66.55.in-addr. arpa провайдеру MidTierISP.
DNS-сервер спрашивает у DNS-сервера провайдера MidTierISP: «Кто такой 88.77.66.55.in-addr. arpa ?».
DNS-сервер MidTierISP отвечает, что ему это не известно, но в его владении находится 0.0.66.55.in-addr. arpa , и что он делегировал 0.77.66.55.in-addr. arpa провайдеру HomeTownISP.
DNS-сервер спрашивает у DNS-сервера HomeTownISP «Кто такой 88.77.66.55.in-addr. arpa ?»
DNS-сервер провайдера HomeTownISP отвечает, что он точно знает, кто это, и что данный адрес принадлежит mail.somebody.com .

Это довольно сложный процесс, так как в делегировании используется уровень октетов IP-адреса, особенно если маска подсети не соответствует точным образом строкам подсети. Тем не менее, можно делегировать любую нужную подсеть.

Например, обратной зоной DNS для подсети 192.168.0.128 / 26 является 128/26.0.168.192.in-addr. arpa . Число 128 говорит о том, что нужно начать с этой подсети с 26-битной маской подсети.

Почему «делегирование»?

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

Если вас интересуют более глубокие аспекты, связанные с работой обратного поиска DNS, обратитесь к документу RFC 2317 «Classless IN-ADDR. ARPA Delegation».

Создание зоны обратного поиска

Рассмотрим процесс создания зоны обратного поиска.

Откройте консоль DNS.
Щелкните правой кнопкой мыши на сервере, где нужно создать зону, после чего выберите команду New Zone (Создать зону).
Выберите тип зоны. В данном примере – Standard Primary (Стандартная главная) (не в AD).
Выберите создание зоны обратного поиска Reverse Lookup Zone (Зона обратного поиска).
Введите сетевой идентификатор создаваемой зоны. В данном примере используйте 192.168.0 . Обратите внимание на то, что здесь не указывается четвертый октет, поскольку с ним нельзя создать зону обратной DNS. Если создается бесклассовая (в подсети) обратная зона, то следует ввести имя, а не использовать область мастера Network ID (Сетевой идентификатор).
Выберите создание зоны с данным именем файла, введите новое имя файла либо используйте существующий файл. Помните, что при создании бесклассовой зоны в имени файла нельзя использовать прямой слеш, поскольку он является недопустимым символом в именах файлов Windows. Вместо него следует использовать дефис («-«). При использовании существующего файла преимущество заключается в том, что готовый файл DNS уже настроен и содержит все записи.
Разрешите или запретите динамическое обновление. Если не используется интегрированная с AD зона, нельзя разрешить только защищенные динамические обновления, потому что невозможно настроить списки контроля доступа на стандартных зонах. Тем не менее, можно разрешить динамические обновления с любого клиента.
Нажмите на кнопку Finish (Готово) для завершения процесса.

После создания зоны в ней можно создать записи. В нашей зоне требуется создание записи PTR и обеспечение делегирования.

Создание записей в зоне обратного поиска

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

Выделите зону, в которой нужно создать записи.
Выберите команду ActionNew Pointer (PTR) (ДействиеНовый указатель [PTR]).
Введите узловую часть IP-адреса в соответствующем текстовом поле.
Введите имя узла.
Нажмите на клавишу OK.

Делегирование зон DNS

Рассмотрим процесс делегирования зоны обратного поиска в DNS.

Выделите зону обратного поиска, для которой необходимо реализовать делегирование.
Выберите команду ActionNew Delegation (ДействиеНовое делегирование).
Введите номер подсети, которую нужно делегировать. Например, если для подсети 10.10.0.0/16 нужно делегировать 10.10.5.0/24 , то следует ввести 5.
Нажмите на кнопку Next (Далее).
Добавьте имя (имена) DNS-сервера (серверов), на которых будет располагаться зона, нажав на кнопку Add (Добавить).
Нажмите на кнопку Next (Далее).
Нажмите на кнопку Finish (Готово) для завершения работы мастера.

Вам необходимо также создать соответствующую зону на рассмотренном сервере. В этом случае запись указывает клиенту на сервер имен при выполнении преобразования клиентом имени DNS.

Делегирование для этого dns сервера невозможно создать

У меня небольшая проблема. Мне необходимо сделать так, чтобы после записи у домена в панели регистратора доменов моих DNS созданных на сервере, домен делегировался, без создания его на сервере. И при заходе по делегированному, но не созданному домену открывалась определенная парковочная страница. Помогите пожалуйста, если нужно платно.

Читайте так же:

Импульсный блок питания увлажнителя воздуха

Создайте какой-нибудь WWW домен, где вы создадите парковочную страницу. А потом в модуле "IP-адреса" установите этот WWW домен поумолчанию.

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

Вы совсем не о том простие.
Никакой связи между дефолтным http ответом и делегированием нет.

Чтобы домен делегировался, необходимо создать корректную DNS зону. Без этого делегирование не возможно

а робот регистратора проверяет ответ сервера о домене, а его нет.
Учите матчасть 😉

Вы совсем не о том простие.
Никакой связи между дефолтным http ответом и делегированием нет.

Чтобы домен делегировался, необходимо создать корректную DNS зону. Без этого делегирование не возможно

а робот регистратора проверяет ответ сервера о домене, а его нет.
Учите матчасть 😉

а я и не претендую на звание профессора, каждый должен заниматься своим делом 🙂 мне нужно добиться результата, описанного в первом сообщении. кто нибудь может дать четкие инструкции? если надо я есстественно оплачу

как сделал я: создал себе домен parking.tut(можно пофантазировать, это не принципиально) в панели и соответствующий www к нему, далее в www домен в псивдонимы внес список доменов, которые необходимо было припарковать, после чего в панели управления регистратора ко всем требуемым доменам прописал свои ns сервера.
РЕЗУЛЬТАТ: все домены делегированы и при заходе на любой из них появляется index.html из папки parking.tut

вот собственно и весь фокус, вы это имели ввиду?

не совсем. хотелось бы все тоже самое, только без создавания псевдонимов. чтобы только прописывать днс у регистратора. Так например реализовано у parked.ru, пропишите их днс у домена, и он успешно делегируется без создания его на их сервере. у нас тысячи доменов, и физически нет возможности каждый день добавлять новые в ручную на сервер.

вот еще немного информации:

DNS-хостинг настроенный в режиме Wildcard. Это значит, что на запрос любого домена (заранее не прописанного в зоне) к DNS-серверу, от него идет заранее настроенный ответ с А, MX, NS и прочими записями. Данная технология обычно применяется для парковки доменов (например, для собственной парковки или привязки доменов на публичные парковки, но со своими доменами в NS-записях).

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

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

Никаких других действий не потребуется. Что еще надо ?

это не вариант. у регистратора можно прописать ip, есть одно но. DNS можно указывать в момент регистрации. причем даже если я регистрирую 100 доменов за один раз, я только один! раз прописываю DNS. А вот чтобы прописать IP мне нужно пойти в редактирование каждого домена в отдельности, и прописать ip. Это по времени в разы дольше, чем даже указать пачку псевдонимов на сервере. это не выход, мне нужно через DNS. как это реализовано на всех доменных парковках.

Из того, что я написал следует, что в панели надо выполнить всего 2 действия (независимо от числа доменов, которые вы хотите припарковать). Все остальное выполняется у регистратора (если вы используете сервера имен регистратора) и автоматизации через панель управления сервером не подлежит.

для меня второстепенно в какой панели нужно выполнять действия. для меня главное затраченное на это время. получается надо всего пару кликов сделать в панели и не надо автоматизировать, но при этом потратить больше времени на панель регистратора это лучший вариант? сомневаюсь сильно. кроме того, я точно знаю, что парковаться будут не только мои домены, а объяснять всем что нужно еще сходить куда то и прописать ip это и мне хлопотно, и людям. они просто уйдут на парковку, где прописал dns и все.

Читайте так же:

Вентилятор для кулера zalman

Все остальное выполняется у регистратора (если вы используете сервера имен регистратора) и автоматизации через панель управления сервером не подлежит.

2Александр: Думаю, он как раз использует свои собственные DNS-сервера. При делегировании домена сервер регистратора спрашивает у его DNS-серверов про определенный домен, а в ответ получает отказ, так как записей для этих доменов нет. Соответственно домены не делегируются. В общем, насколько я понял, ему надо что-то вроде записи *, чтобы на любой запрос типа domain.ru возвращался ответ, что такой домен есть.

2Щапаев: Если вы посмотрите на parked.ru, то там на самом деле, неявное занесение информации о доменах в DNS. Т.е. если спросить его о testdomain.parked.ru, то он скажет, что такого домена нет. Думаю, они создаются, когда там регистрируется клиент. Если бы вы поподробней описали свою задачу, то вам бы подсказали более правильное решение. На данный момент, вам скорее всего проще написать скрипт, который будет добавлять записи в DNS. (Поищите по форуму, что-то такое здесь уже обсуждали, возможно, что даже и писать ничего не придется)

http://forum.ispsystem.com/ru/viewtopic.php?t=1706 вот ссылочка

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

часть скриптов
Но часть-то наверное у вас?
Скажите, откуда ISPManager узнает о адресах, которые надо обрабатывать, если вы ему не сообщите об этом каким-нибудь образом?

DNS-хостинг, настроенный в режиме wildcard
Добавьте в DNS вашего домена запись "*" (без кавычек), и ваш DNS-сервер будет обрабатывать все записи вида *.domain.ru
Но, он не будет обрабатывать сервера вида client.com.

Также можете попробовать добавить руками запись:

* IN A xxx.xxx.xxx.xxx
где xxx.xxx.xxx.xxx — это адрес вашего сервера, лично я не пробовал.

P.S. 2Igor: По-моему, через панель нельзя добавить такую запись, или можно?

wildcard для того и создан, чтобы в том числе, не нужно было и давать серверу вообще информацию о домене. Если бы не было это уже реализовано на разных парковках, и не продавались подобные сервисы, я бы не так уверено писал о возможности реализации.

часть скриптов По-поводу:

Также можете попробовать добавить руками запись:

* IN A xxx.xxx.xxx.xxx
где xxx.xxx.xxx.xxx — это адрес вашего сервера, лично я не пробовал.

P.S. 2Igor: По-моему, через панель нельзя добавить такую запись, или можно?

а что можете сказать о записи "*.ru"? в ручную в панель так не добавить, пробовал, но будет ли обрабатывать все .ru если вписать ручками в файлы конфига?

А если внимательно читать http://www.parked.ru/about то там четко сказано:

В панели управления добавьте список доменов, которые хотите припарковать. Затем у регистратора смените name-сервера указанных доменов на ns1.parked.ru и ns2.parked.ru

Так и здесь — сначала в панели управления создаем доменные имена, а потом у регистратора прописываем ns1/ns2 в качестве ДНС серверов.

Если нужно сразу множество доменов припарковать, то дорабатывайте скрипт http://forum.ispsystem.com/ru/viewtopic.php?t=1706 чтобы можно было ему скормить прямо из веб-панели через форму.

А если внимательно читать http://www.parked.ru/about то там четко сказано:

а если не только внимательно читать, но и использовать сервис, то еще лучше можно понять о чем речь. с паркедом не один год работаю. если вы не пропишите домены в их панели, то это не означает что они не припаркуются. они очень даже припаркуются, и будет открываться страница паркеда (проверено неоднократно с доменами c .ru, .su, .com, сами попробуйте). Прописывать домены у них в панели, нужно не для того, что бы они делегировались, а для того чтобы система начисляла доход за клики посетителей ваших доменов именно вам. и так работает не одна доменная парковка, тот же sedo.com.

у меня такое ощущение, что я борюсь с чужими въевшимися стереотипами доказывая очевидное, а мне доказывают, что то, чем я несколько лет пользуюсь на чужих сервисах невозможно.

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

Схему, которую Вы расписали сейчас, можно реализовать следующим образом без всяких wildcard для имени зоны (меняем конфиг named.conf)

$TTL 3600
@ IN SOA ns3.host.ru. hostmaster.host.ru. (2008071101 10800 3600 604800 86400)
@ IN NS ns3.host.ru.
@ IN NS ns4.host.ru.
@ IN MX 10 mail-null.host.ru.
* IN A 12.34.56.78

$TTL 3600
@ IN SOA ns3.host.ru. hostmaster.host.ru. (2008071101 10800 3600 604800 86400)
@ IN NS ns3.host.ru.
@ IN NS ns4.host.ru.
@ IN MX 10 mail-work.host.ru.
* IN A 23.45.67.89

Дальше — продублировать по всем зонам (com,net и пр.), при необходимости можно упростить конфиг named — если весь паркинг будет жить на одном IP, то можно рулить все только настройками virtualhost в apache.

голоса

Рейтинг статьи