Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

В последнее время только и разговоров об REG.RU. К ним массово перевели домены, а они на каждый чих, кроме смены DNS, хотят увидеть ваши паспортные данные. Что собственно не очень-то и правомерно. Официально они могут требовать такие данные в случае жалоб на домен. Ну ладно, достаточно лирики, приступаем к переносу доменов.

Сразу следует отметить, что забрать можно только GTLD домены. Для RU/SU наличие паспорта является обязательным.

Итак, первое что надо сделать — снять с желаемого домена приватность. Во whois домена должен быть виден ваш email.

Затем идем по ссылке и получаем на свой email информацию о том, что этот домен у реселлера reg.ru. Отлично!

Открываем эту ссылку и заполняем форму, в которую копипейстим полученные данные и говорим, что домен таки наш. А злой реселлер не дает transfer code. Естественно, что писать надо с того же email, что и во whois домена

Затем ждем 4-е дня. Потому что суппорт будет безуспешно пытать REG.RU в течении 3-х дней, чтоб отдали вам домен. А на 4-ый он вышлет вам transfer code.

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

Лично мной эта процедура была успешно проведена дважды, еще до того как домены «приплыли» к REG.RU — имел глупость зарегистрировать там пару в зоне COM.

P.S. Если вам помог мой совет — поставьте у себя ссылочку на эту статью. Буду очень благодарен!

P.P.S. Как заполнять форму жалобы:

Email Address: Ваш email, совпадающий с whois домена
Name: Ваше имя, транслитом
Category: Compilance
Domian Name: Имя домена
Summary: Reseller don't give me transfer code
Detailed support Request: Пишем такое письмо, после него прикрепляем информацию от реселлера:

Hi!

My Reseller don't give me transfer code. Please show whois of my domain. This is my email.

Please, sent me transfer code to whois email.

Thanks!

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Очень часто можно встретить множество проблем при смешивании 64-х и 32-х битных пакетов. По этому в самом начале работы, сразу на свежеустановленной центоси надо выкинуть все i386 пакеты:

rpm -qa --queryformat "%-{name}.%{arch}\n" | grep i386 | xargs  yum -y remove

И не забыть про i686:

rpm -qa --queryformat "%-{name}.%{arch}\n" | grep i686 | xargs  yum -y remove

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Вызов скрипта с аргументами: имя-домена место/с/файлами.

#!/bin/bash
cat <<EOF> /etc/nginx/conf.d/$1.conf
server {
		listen 80;
		server_name $1 www.$1;
		error_page 404 = @fallback;
		location / {
			proxy_pass http://127.0.0.1:80;
			proxy_redirect http://$1:80/ /;
			proxy_set_header Host \$host;
			proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
			proxy_set_header X-Real-IP \$remote_addr;
		}
		location ~* ^.+\\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
			root $2;
		}
		location @fallback {
			proxy_pass http://127.0.0.1:80;
			proxy_set_header Host \$host;
			proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
			proxy_set_header X-Real-IP \$remote_addr;
		}
	}
EOF

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Я провел достаточно много времени в поисках готового компилятора PHP для CentOS 5 и убедился, что подобной проблемой пока еще никто не занялся. Более того, базовый набор, даже с учетом всех дополнительных репозитаиев, не содержит необходимых пакетов для корректной установки HipHop-PHP.

Именно по этому я сделал локальный репозитарий, который позволяет исправить этот недостаток и поставить hphp или подготовить CentOS 5 для сборки из исходных кодов (рекомендуемый вариант).

Если вы хотите установить компилятор для php, то можете скачать готовые rpm файлы

Изменение в логике

Весь hiphop-php будет в /usr/lib (64)/hph/ а hphp и hphi создаются симлинками

Экспортируются переменные окружения

Если вы хотите собрать rpm сами, то все исходные srpm можно взять тут

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Ко мне поступил сервер с Linux CentOS 5.3 64bit, выполняющий роль коммерческого хостинга сайтов (WHM/cPanel), который был взломан и взломщики не потрудились вытереть за собой все инструменты, которые они использовали.
Проанализировав их, я смог составить цепочку событий, которая привела к взлому сервера и компрометации рутовой учетной записи.
Никаких логов небыло, так как они все были почищены, так что взломщик не оставил за собой следов, и я начал поистине детективное расследование — с уликами и подозреваемыми.

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

После этого, используя найденную уязвимость, в /tmp заливается Remote Backdoor Shell — perl скрипт, открывающий доступ к командной строке сервера, работающий с правами вебсервера, в данном случае — nobody.
Через этот скрипт в /tmp были установлены

• набор взломщика (см. ниже)
• червь для автоматизации работы со сканерами RFI ботнета, само ищет сайты на Joomla 1.x, пытается взломать через них сервер и залить весь этот комплект, автоматически скачивает эксплойты с Milw0rm и пытается их применить(!) в публичном доступе мной не найден
• модифицированный сканер RFI, который исключает из проверки уже взломанные сайты, обмениваясь информацией по IRC с такими же скриптами ботнета, за основу взят FeeLCoMz RFI Scanner Bot
• скрипт для выполнения приказов типа scan, ddos и тд, простой, в публичном доступе мной не найден
• модифицированный Jheefry RFI Scanner Bot

Все скрипты написана на Perl и управляются через IRC на порту 6667, взломанный сервер заходит под случайным логином в
специальный канал на хаккерском IRC сервере, который в свою очередь так-же устанавливается скриптами на один из взломанных серверов.

Теперь о том, что включает в себя набор взломщика, который скрипты ботнета заливают автоматически:

• psybnc скрипты
• бинарный файл irc севера собранный статически и переименованный в httpd (!)
• бинарный файл proc неизвестного назначения, собран статически, и служит скорее всего для запуска irc сервера в контексте httpd (!)
• скрипт run: ./proc «/usr/local/apache/bin/httpd -DSSL» httpd JaM5, выполняющий подключение irc сервера в контексте httpd (!!!)
• бинарник неизвестного формата с названием xh, вероятно эксплойт, не рабочий, выполняющий подключение irc сервера в контексте httpd для FreeBSD

Итак, на сервере взломщики получили доступ к запуску файлов от имени вебсервера, но как же я определил, что они получили там доступ к root?

Когда я в профилактических целях остановил вебсервер httpd, то в процессах оставался висеть один httpd процесс. Как это возможно?
На самом деле это был perl скрипт, который маскировался под /usr/bin/httpd, тем самым себя выдав, так как httpd запускался из /usr/local/apache/bin/httpd. Он использовал маскировку под procname, где procname — имя процесса:

…
$rm="rm -rf";
qx ($rm $0);
$0 = 
$procname. "";
…
Но самое интересное было не это, а то, что файл с правами nobody находился в /var/lib/mysql, куда может писать только
пользователь mysql! И я решил проверить подозреваемого целостность пакета mysql-server:
#rpm -V MySQL-server
.M5...T /usr/sbin/mysqld
M — означало смену прав, 5 — содержимого (сравнение по MD5 хешу), T — времени. Само собой понятно, что был взломан именно mysql, тем более, что shell у пользователя mysql установлен в /bin/bash, чего быть не должно.

Итак, взломщик при помощи сканов уязвимостей ядра нашел лазейку в ядре, после чего использовал эксплойт для получения консоли с правом root и запустил руткит для mysqld, который при старте запускает бекдор, маскирующийся под процесс /usr/sbin/httpd!

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

• perl под nobody — зло, suexec рулит
• исходящие коннекты с сервера —зло, но порой необходимое, а вот прикрыть irc порт никогда не помешает
• каждый скрипт должен работать от своего владельца, а не от nobody, fastcgi рулит
• надо своевременно обновлять ядро — отсутствие известных уазвимостей в публичном доступе еще не означает их отсутствие в ядре
• если смонтировать разделы, доступные пользователю на запись с noexec — любой эксплойт будет отдыхать

P.S. По ссылке — увлекательная история с ботнетом и infobox.ru.

UPD. Про perl, апач, nobody и suexec:
Все дело в том, что как правило скрипты на Perl запускают с правами владельцев через suexec. И это хорошо, так как в случае проблем будут видны права владельца, через которого закачали бэкдор.
Но если права на запуск Perl доступны для всех, то его можно запустить через функцию exec () PHP. А PHP работает у большинства хостеров от nobody.
Таким образом разрешение запуска Perl от nobody — зло, так как непонятно через какого пользователя заливают бекдор.

UPD2 — ЧАВО

• Уязвимость с ld.so, которая позволяла запустить бинарник с раздела, смонтированного noexec — уже давно закрыта.
• Для хаккера все равно какой ID будет в шелле — юзерский или апача. А сисадмину — это важно знать, так как будет видно какой пользователь имеет уязвимый сайт, просто сделав ps axuwf. Именно по этому php-fastcgi предпочительней mod_php
• Исходящие коннекты нужны для многих вещей — RPC-Ping'ов, Яндекс.Маркета, бирж ссылок, именно по этому невозможно закрыть все исходящие коннекты

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Кроме интеграции nginx, я бы хотел немного поговорить о php. Как известно, он может работать в трех режимах — mod, cgi и fast-cgi. Наиболее быстрым является mod apache. Однако самым экономным в плане работы с оперативкой — fast-cgi.

Каждый решает сам для себя, что ему важнее — быстрее рисовать страницы или экономить память. Лично мой выбор — экономить память, тем более что с fast-cgi без проблем работают такие популярные движки как Wordpress, Drupal, Битрикс и многие другие.

Для контроля за fast-cgi я предлагаю использовать php-fpm. Это нормальная интеграция fast-cgi в php, которая позволяет плодить процессы, рестартовать их, корректно убивать и менять их число в зависимости от нагрузки.

Когда DirectAdmin создает нового пользователя, то вызывает скрипт user_create_post.sh  в /usr/local/directadmin/scripts/custom в который передает информацию о логине в переменной $username. Этим и воспользуемся, написав например такой скрипт, генерирующий кусок XML конфига для php-fpm:

#!/bin/shcat << EOF > /etc/fpm/$username.conf                <section name="pool">                        <value name="name">$username</value>                        <value name="listen_address">/home/$username/php</value>                        <value name="listen_options">                                <value name="backlog">-1</value>                                <value name="owner">$username</value>                                <value name="group">apache</value>                                <value name="mode">0660</value>                        </value>                        <value name="php_defines">                            <value name="sendmail_path">/usr/sbin/sendmail -t -i -f $username@$domain</value>                            <value name="upload_tmp_dir">/home/$username/tmp</value>                            <value name="session.save_path">/home/$username/tmp</value>                        </value>                        <value name="user">$username</value>                        <value name="group">$username</value>                        <value name="pm">                                <value name="style">static</value>                                <value name="max_children">2</value>                        </value>                        <value name="request_terminate_timeout">60s</value>                        <value name="rlimit_files">206103</value>                        <value name="rlimit_core">0</value>                        <value name="catch_workers_output">yes</value>                        <value name="max_requests">256</value>                        <value name="environment">                                <value name="HOSTNAME">$HOSTNAME</value>                                <value name="PATH">/usr/local/bin:/usr/bin:/bin</value>                                <value name="TMP">/home/$username/tmp</value>                                <value name="TMPDIR">/home/$username/tmp</value>                                <value name="TEMP">/home/$username/tmp</value>                                <value name="OSTYPE">$OSTYPE</value>                                <value name="MACHTYPE">$MACHTYPE</value>                                <value name="MALLOC_CHECK_">2</value>                        </value>                </section>EOFexit 0;

Теперь о nginx и генерации конфига. Устанавливаем nginx классическим образом как акселлератор на 85-ом порту и делаем проброс через iptables. Подключаем в конфиг чтение всех файлов конфигов из /etc/nginx/vhost/*

Когда создается домен или поддомен, DirectAdmin соответственно запускает domain_create_post.sh и subdomain_create_post.sh. Просто создадим эти скрипты, чтоб они добавляли конфиг в nginx и рестартовали его:

#!/bin/shcat << EOF > /etc/nginx/vhost/$domain.conf   server {        listen       $ip:85;        server_name  $domain www.$domain;        access_log  /var/log/httpd/domains/$domain.log  main;        root   /home/$username/domains/$domain/public_html;
                location / {                        fastcgi_pass unix:/home/$username/php;                        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;                        fastcgi_index  index.php;                        include        fastcgi_params;                }                location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {                        root /home/$username/domains/$domain/public_html;                        error_page 404 = @fallback;                }                location @fallback {                        fastcgi_pass unix:/home/$username/php;                        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;                        fastcgi_index  index.php;                        include        fastcgi_params;                }        }EOFkillall -s 1 nginxexit 0;

Если же надо оставить apache и просто отдавать статику nginx, то используем такой конфиг:

#!/bin/shcat << EOF > /etc/nginx/vhost/$domain.conf   server {        listen       $ip:85;        server_name  $domain www.$domain;        access_log  /var/log/httpd/domains/$domain.log  main;        root   /home/$username/domains/$domain/public_html;
                location / {                        proxy_pass http://$ip:80;                        proxy_redirect http://$ip:80/ /;                        proxy_set_header Host $host;                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;                        proxy_set_header X-Real-IP $remote_addr;                }                location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {                        root /home/$username/domains/$domain/public_html;                        error_page 404 = @fallback;                }                location @fallback {                        proxy_pass http://$ip:80;                        proxy_redirect http://$ip:80/ /;                        proxy_set_header Host $host;                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;                        proxy_set_header X-Real-IP $remote_addr;                }        }EOFkillall -s 1 nginxexit 0;

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

#! /bin/sh -x
#
# демонстрация возможностей по управлению входящим (ingress) трафиком
# здесь приводится пример ограничения пропускной способности для входящих SYN-пакетов
# Может оказаться полезным для защиты от TCP-SYN атак.
#
#пути к различным утилитам;
#укажите правильные значения.
#
TC=/sbin/tc
IP=/sbin/ip
IPTABLES=/sbin/iptables
INDEV=eth2
#
# пометить все SYN-пакеты, пришедшие через $INDEV, числом 1
############################################################
$iptables -A PREROUTING -i $INDEV -t mangle -p tcp --syn \
  -j MARK --set-mark 1
############################################################
#
# установить ingress qdisc на входящий интерфейс
############################################################
$TC qdisc add dev $INDEV handle ffff: ingress
############################################################ #
#
# SYN-пакет имеет размер 40 байт (320 бит), отсюда -- три пакета
# имеют размер 960 бит (примерно 1 Кбит); ограничим скорость поступления
# 3-мя пакетами в секунду ( точнее -- 1 Кбит/сек )
############################################################
$TC filter add dev $INDEV parent ffff: protocol ip prio 50 handle 1 fw \
police rate 1kbit burst 40 mtu 9k drop flowid :1
############################################################
#
echo "---- qdisc parameters Ingress  ----------"
$TC qdisc ls dev $INDEV
echo "---- Class parameters Ingress  ----------"
$TC class ls dev $INDEV
echo "---- filter parameters Ingress ----------"
$TC filter ls dev $INDEV parent ffff:#Удаление ingress qdisc

#$TC qdisc del $INDEV ingress

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

После установки HyperVM прежде всего проверьте что текущее ядро поддерживает XEN.

В панеле обязательно установите пул IP адресов для VPS.

Скачайте дистрибутив Windows в виде iso образа и поместите в /home/wincd.img — это обязательно!

Создавайте VPS с шаблоном windows.

После этого можно зайти по VNC на VPS и выполнить установку.

Но сразу же сделать клониирование VPS в шаблон ОС на Centos 5 64-bit не выйдет — там нет пакет ntfsprogs, так как разработчики не смогли его скомпилировать для 64-битной системы.

По этому качайте пакеты с сайта, ставьте их и выполняйте клонирование.

Успешной вам работы с XEN и HyperVM!

]]> http://www.manageserver.ru/2011/07/15/%d1%83%d1%81%d1%82%d0%b0%d0%bd%d0%be%d0%b2%d0%ba%d0%b0-windows-vps-xen-%d0%bf%d1%80%d0%b8-%d0%bf%d0%be%d0%bc%d0%be%d1%89%d0%b8-hypervm-%d0%bd%d0%b0-centos-5-64-bit/feed/ 0 http://www.manageserver.ru/2011/07/14/%d0%b2%d1%81%d0%b5-%d1%87%d1%82%d0%be-%d0%b2%d1%8b-%d1%85%d0%be%d1%82%d0%b5%d0%bb%d0%b8-%d0%b7%d0%bd%d0%b0%d1%82%d1%8c-%d0%be-hypervm-%d0%bd%d0%be-%d0%b1%d0%be%d1%8f%d0%bb%d0%b8%d1%81%d1%8c-%d1%81/ http://www.manageserver.ru/2011/07/14/%d0%b2%d1%81%d0%b5-%d1%87%d1%82%d0%be-%d0%b2%d1%8b-%d1%85%d0%be%d1%82%d0%b5%d0%bb%d0%b8-%d0%b7%d0%bd%d0%b0%d1%82%d1%8c-%d0%be-hypervm-%d0%bd%d0%be-%d0%b1%d0%be%d1%8f%d0%bb%d0%b8%d1%81%d1%8c-%d1%81/#comments Thu, 14 Jul 2011 16:18:46 +0000 Повелитель серверов http://www.manageserver.ru/2011/07/14/%d0%b2%d1%81%d0%b5-%d1%87%d1%82%d0%be-%d0%b2%d1%8b-%d1%85%d0%be%d1%82%d0%b5%d0%bb%d0%b8-%d0%b7%d0%bd%d0%b0%d1%82%d1%8c-%d0%be-hypervm-%d0%bd%d0%be-%d0%b1%d0%be%d1%8f%d0%bb%d0%b8%d1%81%d1%8c-%d1%81/

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Список вопросов и ответов, которые любезно предоставил Pilat в этой теме:

Может ли работать только master с реальным IP адресом, а все Slave в приватной сети? Это вопрос к лицензии.

Да, конечно. Однако Slave серверам будет необходим доступ в сеть, так что нужно будет для них настроить NAT.

Как делается backup сервера, можно ли запускать скрипты до и после бэкапа и нужно ли (например, бэкап и восстановление mysql баз). Подозрительная рекомендуемая опция останавливать виртуальную машину перед бэкапом мне не нравится. Насколько вообще можно полагаться на его бэкап?

Зависит от технологии. На OpenVZ можно смело выполнять бекап без остановки, что конечно может нарушить целостность данных, но в XEN отключение VPS обязательно. Бекап VPS идет на уровне контейнеров а не на уровне сервисов (mysql баз например). На бекап можно расчитывать, особенно если под него выделен отдельный диск.

Можно ли через HyperVM раздавать не только vlan, а veth с выделением ethernet порта одной из виртуальных машин в монопольное использование? Что будет, если я вручную сконфигуриру бриджи, не попортятся ли они?

Нет, с выделением придется проводить настройки вручную. HyperVM не будет их портить, проверенно. Однако стоит внимательно прочитать официальный форум OpenVZ, так как там есть много ошибок и подводных камней. Это связанно с самой технологией OpenVZ, а не HyperVM.

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

Потому что панель позволяет одновременно управлять VPS на Xen и OpenVZ. Соответственно интерфейс сделан совмещенным. То, что отмечено для определенной технологии будет работать только на ней. Не стоит ожидать, что в OpenVZ появится SWAP на уровне VPS, или что XEN сможет использовать Brustable RAM.

Насколько безопасен серверный интерфейс?

Взломов не замечено, кроме того он постоянно обновляется. Были случаи взлома.

Вообще насколько HyperVM упрощает жизнь администратору. Я посмотрел на графики — мне что-то они показались не оччень информативными, есть ли механизм контроля параметров виртуальных машин. Вообще я полагался до сих пор на zabbix, но он сам не сильно надёжен.

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

]]> http://www.manageserver.ru/2011/07/14/%d0%b2%d1%81%d0%b5-%d1%87%d1%82%d0%be-%d0%b2%d1%8b-%d1%85%d0%be%d1%82%d0%b5%d0%bb%d0%b8-%d0%b7%d0%bd%d0%b0%d1%82%d1%8c-%d0%be-hypervm-%d0%bd%d0%be-%d0%b1%d0%be%d1%8f%d0%bb%d0%b8%d1%81%d1%8c-%d1%81/feed/ 0 http://www.manageserver.ru/2011/07/13/wildcarddns-dns-%d0%b4%d0%bb%d1%8f-%d0%bf%d0%b0%d1%80%d0%ba%d0%be%d0%b2%d0%ba%d0%b8-%d0%b4%d0%be%d0%bc%d0%b5%d0%bd%d0%be%d0%b2-ru/ http://www.manageserver.ru/2011/07/13/wildcarddns-dns-%d0%b4%d0%bb%d1%8f-%d0%bf%d0%b0%d1%80%d0%ba%d0%be%d0%b2%d0%ba%d0%b8-%d0%b4%d0%be%d0%bc%d0%b5%d0%bd%d0%be%d0%b2-ru/#comments Wed, 13 Jul 2011 15:18:43 +0000 Повелитель серверов http://www.manageserver.ru/2011/07/13/wildcarddns-dns-%d0%b4%d0%bb%d1%8f-%d0%bf%d0%b0%d1%80%d0%ba%d0%be%d0%b2%d0%ba%d0%b8-%d0%b4%d0%be%d0%bc%d0%b5%d0%bd%d0%be%d0%b2-ru/

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Домашняя страница проекта размещена по адресу http://wildcarddns.sourceforge.net/

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

Установка стандартна и вопросов не требует:

1. Получить исходные коды через CVS
2. Скомпилировать бинарник при помощи make

Учтите — софт очень капризный и требовательный к конфигам.  Делайте свои на базе примеров.