Блог - Linux, программирование, Я!

linux на сервереНастраиваем девелоперский DNS сервер

Рассмотрим эволюцию организации работы веб-разработчика с несколькими проектами на разных адресах и поможем поскорее перескочить через первые ступеньки!

Все на localhost

Когда ты в одиночку разрабатываешь один единственный веб-сервис или сетевое приложение, то, как правило, вполне хватает локального домена localhost. Но что происходит, когда появляется необходимость разрабатывать и поддерживать одновременно два или более совершенно разных приложения? Сперва ты пытаешься рассовывать разные приложения по подпапкам одного домена вроде http://localhost/app1/ http://localhost/app2/ и т.д. Ок, при более-менее простых приложениях такой вариант еще может работать. Но когда возникает необходимость в привязке приложения к корню сайта в относительных внутренних ссылках, когда необходимы специфические настройки веб-сервера (например специфические реврайт-правила), то сложность и запутанность полученной системы крайне резко возрастает, начинают появляться различные баги и замедляется процесс разработки.

Файл hosts

Позже, изрядно помучавшись с однодоменным расположением проектов, вдруг узнаешь про существование волшебного файлика hosts ( /etc/hosts) с помошью которого можно создавать для себя дополнительные "локалхосты", т.е. получаем возможность любое конкретное доменное имя направить на любой конкретный IP адрес. Отлично! Теперь можно разнести все свои "локалхосты" по отдельным "поддоменам" типа app1.loc app2.loc просто прописав в /etc/hosts ( WINDOWS\system32\drivers\etc\hosts для виндов) всего пару строк
127.0.0.1 app1.loc
127.0.0.1 app2.loc
Выглядит просто и понятно, все записи под рукой, можно легко добавить и удалить нужный домен, изменения, как правило, вступают в силу мгновенно. В принципе этим можно ограничиться если у тебя не так много проектов, меняются они нечасто и ты работаешь над ними неторопясь и ОДИН. Но есть у такого подхода 2 существенных недостатка:

  1. Для того чтобы к имени app1.loc добавить поддомен, например static.app1.loc допустим, для хранения статических файлов, приходится создавать в файле hosts дополнительную запись типа 127.0.0.1static.app2.loc т.к. hosts файл не поддерживает wildcard формы записи - прописать в нем 127.0.0.1*.app1.loc нельзя!
    Такую ситуацию еще можно терпеть если у вас действительно нужно добавить всего 1-2 поддомена, но что, если ваше приложение предоставляет своим пользователям отдельные поддомены? http://user.app1.loc, http://pi_es.seriyps.ru/, http://seriyps.habrahabr.ru/ ? Отладка такого проекта с использованием файла hosts становится практически невыполнимой задачей. Опять же при росте количества проектов файл hosts забивается мусором и в нем становится трудно что-то найти.
  2. Если вы разрабатываете ваше приложение не в одиночку а целым офисом, в котором стоит девелоперский веб-сервер, то для того чтобы дать коллеге ссылку на домен из вашего файла hosts вам как минимум нужно будет убедиться что этот адрес есть и в его файле hosts. Согласитесь, это даже звучит смешно!

Свой девелоперский DNS сервер

Ну вот мы и добрались до самого праведного способа организации разработки интернет-приложения для доменов - это использование своего DNS сервера. Имеется в виду конечно не "каждому девелоперу - по DNS серверу" а установка централизованного DNS сервера для офиса. Хотя даже для единоличной разработки свой DNS все равно удобнее hosts файла хотя бы из за наличия wildcards. Собственно преимущества такого подхода очевидны:

  1. Проект разрабатывается в той среде, в которой он будет использоваться в продакшене. Никаких посторонних файлов и настроек веб-сервера как в случае с расположением проектов в поддиректориях localhost
  2. Настоящие доменные ЗОНЫ со всеми типами записей в т.ч. и wildcard... @, *, MX, CNAME и пр.
  3. Все пользователи, прописавшие себе этот DNS (а если он включается автоматом по DHCP то все еще больше упрощается) смогут открывать ваши ссылки не задумываясь "a прописал-ли я ее себе в hosts файл.."

Устанавливаем и настраиваем DNS сервер.

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

Настройка простейшей dev зоны для DNS сервера BIND9 (named) на Ubuntu/Debian

Т.к. мы настраиваем DNS для небольшой сети "для своих", можно пренебречь некоторыми мерами безопасности. Например, мы не будем запускать bind в chroot окружении и не будем ограничивать подключение к ним с различных IP. К тому же для named уде при установке создаются вполне приемлемые правила для apparmor.
Для начала установим сам bind

sudo apt-get install bind9

В Ubuntu/Debian конфигурационные файлы Bind хранятся в директории /etc/bind, файлы, создаваемые при работе Bind хранятся в /var/cache/bind , главный конфигурационный файл bind находится по адресу /etc/bind/named.conf . В принципе, все опции можно вносить в него, но рекомендуется использовать для этого подключаемые файлы: named.conf.options - для настроек сервера и named.conf.local - для добавления зон. Таким образом нас интересуют именно эти файлы. Кстати, их синтаксис похож на C код, поэтому даже можно использовать подсветку синтаксиса C. Приступим:
Открываем файл /etc/bind/named.conf.options и приводим его содержимое к виду

options {
        directory       "/var/named";
        //раскомментировать строчки ниже, если хотим кешировать ответы DNS провайдера.. может немного "ускорить интернет"
        // forwarders {
        //      192.0.2.1; IP адреса DNS провайдера из "cat /etc/resolv.conf" при подключенном интернете
        //      192.0.2.2;
        // };
};

directory - указывает на директорию, в которой хранятся файлы сервера, такие как кеш, в forvarders можно добавить адреса DNS серверов вашего провайдера для кеширования их ответов и таким образом несколько сократить сетевые издержки на DNS запросы. Существует еще куча опций, но в нашем простейшем сервере они не нужны.
Прекрасно, общие настройки сделаны. Уже сейчас можно использовать наш сервер в качестве кеширующего DNS. Но нас интересует возможность создания и администрирования собственной зоны!
Открываем /etc/bind/named.conf.local и пишем в него

zone "dev" {
        type master;
        file "/etc/bind/db.dev";
        
};

type master означает что мы являемся единственным авторитетным источником информации о зоне dev, file указывает на расположение файла с информацией о зоне. Остается только создать этот файл
/etc/bind/db.dev

@ IN SOA dev. root.dev.    ( ; dev. - имя зоны, root.dev. - e-mail администратора зоны, в котором @ заменено на . т.е. это было root@dev но лучше вставить настоящий e-mail
        20100506        ; Серийный номер зоны. Обычно - текущая дата
        3h              ; обновление каждые 3 часа
        1h              ; повтор каждый час
        1w              ; информация хранится 1 неделю
        1d    )         ; TTL записи - 1 день

@   IN    NS    dev.        ; сервер имен. Рекомендую оставить как тут
@   IN    A  198.51.100.1       ; A - запись - IP адрес сервера для данной зоны (ваш девелоперский сервер). @ для имени домена означает "корень зоны"
*   IN    CNAME  @              ; CNAME запись. По сути - символическая ссылка. * для имени домена означает "любой поддомен".
                                  ; Т.е. при обращении на любой поддомен в зоне dev будет возвращаться IP 198.51.100.1
database IN A 198.51.100.2      ; Но поддомен database.dev будет расположен на другом IP адресе

Не забывайте ставить завершающие точки в имени домена!
Сохраняем, заставляем bind перечитать конфигурацию

sudo service bind9 reload

проверяем

nslookup any.dev
Server:            127.0.0.1
Address:        127.0.0.1#53

any.dev canonical name = dev.
Name:   dev
Address: 198.51.100.1
nslookup database.dev
Server:            127.0.0.1
Address:        127.0.0.1#53

Name:   database.dev
Address: 198.51.100.2

В случае возникновения каких-то проблем смотрим syslog - как правило bind сообщает об ошибках именно туда.
Понятно что таким-же образом можно создавать или переопределять любые другие зоны - добавляется блок zone в named.conf.local и создается соответствующий файл с информацией зоны.

Использование DNS сервера

Сервер есть, осталось его подключить!

Ubuntu

Если вы не пользуетесь NetworkManager-ом, то достаточно в самое начало файла /etc/resolv.conf прописать ваш DNS сервер.
Если NetworkManager используется, открываем "Изменить соединения", выбираем нужное соединение (проводное, VPN, etc), открываем вкладку "Параметры IPv4" и заменяем "Автоматически (DHCP)" на "Автоматически (DHCP, только адрес)", затем в поле "Серверы DNS" вписываем первым IP вашего DNS сервера и дальше через запятую ip адреса из /etc/resolv.conf
Переподключаем сеть.

Windows

В свойствах соединения в настройках TCP/IP прописываем первым наш DNS и после DNS провайдера.

Удачных экспериментов!
Почитать:
Официальный сайт bind
Кеширующий DNS сервер для локальной сети на основе BIND 9
Установка Bind (named) на CentOS
Установка и настройка DNS сервера bind9 Ubuntu-Debian HOWTO

  1. Katerinka
    2010-05-07 21:07:13 | #

    Ponravilos

  2. 2010-05-12 15:41:11 | #

    Текста конечно много, но все таки прочел, и не жалел, почерпнул для себя новую инфу, спасибо 🙂

  3. asfgsdfg
    2010-06-21 23:37:59 | #

    а если DNS провайдера выдается DCHP сервером — как быть???

    • 2010-06-22 12:07:07 | #

      Очень хороший вопрос!

      Уверен, есть более правильное решение, но мне на ум приходят такие варианты:

      1) если у вас в сети провайдера нет локальных ресурсов и DNS используется только для доступа к интернету — можно прописать себе какой-нибудь внешний DNS сервер
      2) если сеть провайдера не очень большая, то, возможно, DNS серверов у провайдера не так много и их адреса не меняются. Тогда можно посмотреть что выдается в DHCP и жестко прописать у себя. (для себя использовал именно этот способ)
      3) если интернет работает через VPN, можно покопаться в файлах вроде /etc/ppp/ip-up.d/usepeerdns, которые отвечают за смену DNS при подключении VPN соединения.

      • Ivan1986
        2010-09-20 23:16:36 | #

        Если используется resolvconf, то нигде копаться не надо — он сам обновит в конфиге бинда dns сервера и при смене перезапустит его

        (файл /etc/resolvconf/update.d/bind)

        • 2010-09-20 23:38:00 | #

          Спасибо, так и есть!
          Стоит отметить что resolvconf сейчас используется почти во всех дистриутивах

  4. casper
    2011-05-19 16:27:22 | #

    отсутствует описание обратной зоны, автор ……..

    • 2011-05-19 17:19:38 | #

      Для собственных нужд, мне кажется, сойдет и так)
      Но, честно говоря, я в типах зон DNS не шибко силен. Если подскажете что нужно добавить, с удовольствием подправлю!

  5. 2011-12-16 05:43:02 | #

    That’s what we’ve all been waiting for! Great ptonsig!

  6. 2012-03-29 13:12:52 | #

    Спасибо большое за статью очень помогла, да и узнал многое для себя.
    Желаю удачи всем

  7. 2019-03-17 21:02:30 | #

    Инстаграм SMM клиенты предлагает горы преимуществ и решает следующие проблемы Инстаграм страниц . Дизайн и настройка изображения. Управление репутацией бренда и улучшения Instagram . Образование необходимых требований также вероятно в соответствии с требованиями Инстаграм страниц . Отзывы Instagram целевой группы Социальные путы с миллионами зрителей лайков продвижении в день являются идеальным местом чтобы привлечения новых клиентов продвижении . Наши специалисты знают продвижении , как исполнять эту работу более эффективно. Разряд мероприятий, в которых социальные сети используются в качестве ресурса ради раскрутки деятельности веб-сайта аудитория и решения конкретных проблем бизнеса. С через рекламы в социальных сетях (smm) вы можете выбрать свою аудиторию, чтобы воздействовать для них и найти наиболее положенный канал связи. Мы нашли сноровка давать ограничения ВКонтакте и Instagram, и теперь мы можем исполнять неограниченное количество приглашений Instagram и раскрутки вашей целевой аудитории! Вы будете единственно заинтересованы и постоянные клиенты. Каждый решает присоединиться массфолловинга к продвижении своему сообществу либо нет клиенты.
    Массфолловинг продвижения в Instagram
    Те, который, непременно, заинтересованы в книга, для проявить барыш к их сообществу вывода Инстаграм, приходят с приглашением. Все гости являются активными пользователями. Привлекая определенное количество участников по количеству отправленных приглашений, некоторый останутся лайков. Спасибо следовать вашу гений замечать свою группу. Мы создаем набитый мнение о часть, когда и если человек прибывают. Есть союз с людьми и временем. Существование группы в популярных социальных сетях Instagram ныне — это не просто налог моде или другим торопливо развивающимся тенденциям раскрутки Инстаграм . Это исправный сбруя ради привлечения и привлечения клиентов. Разве у компании затрапезничать разряд социальных сетей лайков, это поможет улучшить имидж компании аудитория. Он современный и зияющий, что повышает доверие клиентов вывода Инстаграм.
    заходите https://instaspb.ru — Продвижение аккаунтов в инстаграм