Назад | Перейти на главную страницу

Поддомены хоста с BIND9 и Apache в Ubuntu

У меня есть домен betasquirrel.com приобретены у GoDaddy и VPS с Ubuntu 16.04. И я успешно разместил домен, используя BIND9, как показано ниже:

Создан виртуальный хост для betasquirrel.com в Apache и разместил файлы. Далее созданы два хоста ns1.betasquirrel.com и ns2.betasquirrel.com в GoDaddy, указав IP-адрес VPS.

Далее настроил BIND9,

/etc/bind/zones/master/db.betasquirrel.com

;
; BIND data file for betasquirrel.com
;
$TTL    3h
@       IN      SOA     ns1.betasquirrel.com. admin.betasquirrel.com. (
1        ; Serial
3h       ; Refresh after 3 hours
1h       ; Retry after 1 hour
1w       ; Expire after 1 week
1h )     ; Negative caching TTL of 1 day
;
@       IN      NS      ns1.betasquirrel.com.
@       IN      NS      ns2.betasquirrel.com.


betasquirrel.com.    IN      MX      10      mail.betasquirrel.com.
betasquirrel.com.    IN      A       144.217.163.139
ns1                     IN      A       144.217.163.139
ns2                     IN      A       144.217.163.139
www                     IN      CNAME   betasquirrel.com.
mail                    IN      A       144.217.163.139
ftp                     IN      CNAME   betasquirrel.com.

/etc/bind/zones/master/db.144.217.163

;
; BIND reverse data file for 163.217.144.in-addr.arpa
;
$TTL    604800
163.217.144.in-addr.arpa.      IN      SOA     ns1.betasquirrel.com. admin.betasquirrel.com. (
                          1         ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 day
;
163.217.144.in-addr.arpa.       IN      NS      ns1.betasquirrel.com.
163.217.144.in-addr.arpa.       IN      NS      ns2.betasquirrel.com.

139.163.217.144.in-addr.arpa.   IN      PTR     betasquirrel.com.

/etc/bind/named.conf.local

zone "betasquirrel.com" {
       type master;
       file "/etc/bind/zones/master/db.betasquirrel.com";
};

zone "163.217.144.in-addr.arpa" {
       type master;
       file "/etc/bind/zones/master/db.144.217.163";
};

В named.conf.options

forwarders {
    213.186.33.99;
};

/etc/init.d/bind9 restart

Далее добавлены DNS-серверы ns1.betasquirrel.com и ns2.betasquirrel.com в GoDaddy и сайт заработал.

Теперь, как я могу размещать такие поддомены, как demo.betasquirrel.com. Я только что создал виртуальные хосты, и это не работает.

/etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
search demo.betasquirrel.com
search betasquirrel.com
nameserver 213.186.33.99
search local

/etc/apache2/sites-available/betasquirrel.com.conf

<VirtualHost *:80>
  ServerName betasquirrel.com
  ServerAlias www.betasquirrel.com
  DocumentRoot /var/www/html/betasquirrel.com/htdocs
  DirectoryIndex index.php index.html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

/etc/apache2/sites-available/demo.betasquirrel.com.conf

<VirtualHost *:80>
  ServerName demo.betasquirrel.com
  ServerAlias www.demo.betasquirrel.com
  DocumentRoot /var/www/html/demo.betasquirrel.com/htdocs
  DirectoryIndex index.php index.html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

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

Ваши клеевые записи правильно настроены вашим регистратором, поэтому там ничего не нужно менять:

% dig @a.gtld-servers.net. ns1.BETASQUIRREL.COM. | egrep "^[[:alnum:]]"
BETASQUIRREL.COM.       172800  IN      NS      ns2.BETASQUIRREL.COM.
BETASQUIRREL.COM.       172800  IN      NS      ns1.BETASQUIRREL.COM.
ns2.BETASQUIRREL.COM.   172800  IN      A       144.217.163.139
ns1.BETASQUIRREL.COM.   172800  IN      A       144.217.163.139

Ваш сервер действительно находится в сети, так что проблема не в брандмауэре:

% dig @144.217.163.139 version.bind txt chaos +short
"9.10.3-P4-Ubuntu"

Однако ваш BIND, похоже, не действует как полномочный сервер для вашей доменной зоны:

% dig @144.217.163.139 ns1.BETASQUIRREL.COM. a +short
%

Сравните с тем, что происходит при правильной настройке имени:

% dig @216.218.131.2 ns2.he.net a +short
216.218.131.2
%

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

Кроме того, обратите внимание, что при настройке обратной зоны, 163.217.144.in-addr.arpa., подходит только в том случае, если вы приобрели не менее 256 адресов IPv4 в одном / 24 и получили полное делегирование для зоны. Иногда провайдеры также поддерживают «бесклассовое» делегирование, например, согласно http://tools.ietf.org/html/rfc2317однако с такими поставщиками ценностей и облачных сервисов, как OVH, вероятно, наиболее распространено просто использовать их интерфейс для установки обратной записи на своих собственных серверах без необходимости запускать какие-либо дополнительные зоны на вашей стороне.

Обратите внимание, что настройка forwarders { 8.8.4.4; }; будет правильным только в том случае, если вы собираетесь запустить локальный рекурсивный DNS-сервер; это отдельно и независимо от запуска авторитетный DNS-сервер, как вы изначально пытались сделать. Как правило, запускать оба как часть одного и того же демона - плохая идея из-за проблемы потенциального заражения кеша.

Более того, используя 8.8.4.4 это плохая идея по причинам, слишком длинным для этого ответа, и вы уже используете 213.186.33.99 (cdns.ovh.net.) в /etc/resolv.conf, который должен быть рекурсивным сервером вашего провайдера и, вероятно, является лучшим выбором для настройки.

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

Большинство хостинг-провайдеров уже поддерживают авторитетные DNS-серверы за небольшую плату или бесплатно (если вы являетесь клиентом) и имеют веб-интерфейс, где все можно настраивать. Кроме того, существует множество бесплатных провайдеров; самое обычное существо http://dns.he.net/ - это бесплатно и очень быстро, и они позволяют редактировать настройки онлайн.

В качестве альтернативы я также могу предложить отказаться от настроек BIND и Apache и попробовать использовать NSD3 и nginx.

Если вы хотите начать использовать demo в качестве поддомена вам нужно будет добавить запись A или CNAME в файл зоны, как вы это делали для ns1, ns2, и mail.

Итак, ваш файл зоны должен выглядеть так:

;
; BIND data file for betasquirrel.com
;
$TTL    3h
@       IN      SOA     ns1.betasquirrel.com. admin.betasquirrel.com. (
                        2        ; Serial
                        3h       ; Refresh after 3 hours
                        1h       ; Retry after 1 hour
                        1w       ; Expire after 1 week
                        1h )     ; Negative caching TTL of 1 hour

@       IN      NS      ns1
@       IN      NS      ns2

@       IN      MX      10      mail
@       IN      A       144.217.163.139
ns1                     IN      A       144.217.163.139
ns2                     IN      A       144.217.163.139
www                     IN      A       144.217.163.139
mail                    IN      A       144.217.163.139
ftp                     IN      CNAME   www
demo                    IN      CNAME   www

Обратите внимание на добавление последней строки. Теперь ваш DNS-сервер знает, как отвечать, когда вы запрашиваете demo.betasquirrel.com.

Также не забывайте увеличивать серийный номер при внесении изменений.

Кстати, использование CNAME на поддомене для возврата к верхнему домену - это то, чего я бы не стал делать ... поэтому я тоже это изменил. И @ является сокращением для текущего происхождения (то есть доменного имени).

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

Согласно вашему комментариюты удалил demo записи, и остальная часть вашего домена снова начала работать, что приводит нас к фактическим записям, которые были удалены, и все вместе взятые были неверными:

-demo.betasquirrel.com. IN A 144.217.163.139
-demo IN A 144.217.163.139
-demo IN CNAME demo.betasquirrel.com.

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

  2. Однако самая проблемная проблема возникает из-за наличия как A и CNAME записи в то же время - CNAME запись означает, что это имя вместо этого относится к другому хосту; и как таковое имя не может одновременно содержать НИКАКИХ других записей, поскольку это просто псевдоним.

    Говоря языком файловой системы, A запись похожа на строку в файле и может сосуществовать практически с любой другой записью (строками в том же файле). Однако CNAME похоже на символический link - если данный файл является символической ссылкой, он не может также содержать другие случайные строки.

  3. Более того, если более внимательно присмотреться к вашему CNAME, на самом деле это ссылка от самого себя на себя (после расширения), что также совершенно неверно само по себе.

Решение:

Либо добавьте CNAME запись, или A запись; разница в семантике, и здесь нет «правильного» или «неправильного» решения. Однако вы не можете добавить и то и другое одновременно. Более того, при добавлении записи CNAME она должна указывать на существующую запись, которая содержит требуемую запись A, и определенно не может просто указывать на себя.

Вариант 0:

+demo IN A 144.217.163.139

Вариант 1а:

+demo IN CNAME @

Вариант 1б:

+demo IN CNAME betasquirrel.com.

Вариант 2а:

+demo IN CNAME www

Вариант 2б:

+demo IN CNAME www.betasquirrel.com.

Нельзя одновременно брать все варианты !!!

Нет, серьезно, нельзя! Это просто не сработает. Не вините нас за это.

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

P.S. Также обратите внимание, что + знак перед примерами означает строку, которую вы должны добавить, это не должна быть фактическая часть файла.