jerromo 17.05.2010 19:12
How-to`s — Настройка dnsmasq для одновременной работы с DNS провайдера и локальной сети
Дано:Несколько серверов имен провайдера, полученных с помощью dhcp.Локальный сервер имен для внутренних доменов.
Машина с Ubuntu/Debian (Проверялось на Ubuntu 10.04).
Для решения будем использовать dnsmasq и resolvconf.
dnsmasq - это легкий кэширующий DNS, DHCP сервер,
а resolvconf - пакет для управления информацией о серверах имён.
Для начала установим пакеты:
1 |
|
В Ubuntu 10.04 пакет resolvconf не требует конфигурации и работает из коробки.
А dnsmasq свой адрес (127.0.0.1) установит сам после перезагрузки.
Далее настроим dnsmasq.
Сохраним конфигурационный файл по умолчанию и создадим новый с нужными настройками.
Настройки закончены. Теперь лучше перезагрузиться, чтобы перезапустились сервисы и
провайдер, по новой, нам выдал сервера имен.
Все, теперь запросы для локальных доменов будут уходить на адрес 192.168.0.1
А так же, все запросы теперь кэшируются, что должно положительно сказать на скорости преобразования имен.
Другой вариант, eсли вместо локальной сети есть vpn и свои DNS,
тогда файл конфигурации будет такой:
Порядок следования серверов для интерфесов задаетcя resolvconf в /etc/resolvconf/interface-order
Пояснения к файлу настроек dnsmasq (по умолчанию), в части касающейся DNS:
1 |
# Файл настроек dnsmasq.
|
Username 17.05.2010 19:30 #
+ 1 -
Неистово плюсую, добавляю в мемориз и реквестирую редактирование поста для вообще идиотов.
Не. Просто чем разжеванней материал, тем он ценее в итоге. ЭЭээ порог вхождения в статью меньше
хорошая шняга, только у dnsmasq есть 1 минус, при перезагрузке кеш обнуляется. Из-за этого пользовался pndns, но его глюки достали (временами переставал резольвить локальные адреса, то просто тупо вис)поэтому вернулся назад на dnsmasq
Призрачный минус. Время жизни доменной записи как правило 2-3 часа (в основном), поэтому они в кэше все равно умирают.
а причем тут кеши ns серверов ? Насколько я понимаю принцип работы локального кеширующего днс в том, что он сначала ищет запись у себя, а если не находит отправляется искать её выше по иерархии. Или я ошибаюсь?
нет все правильно. Только надо понимать, что кэш dnsmasq ничем не отличается от кэша вышестоящих серверов. В его кэше записи также умирают по истечении TTL
# Установить время жизни кэша запросов к файлу /etc/hosts и DHCP
#local-ttl=
#local-ttl=
вот тут -то эти плюшки и настраиваются :)
неа. тут настраиваются плюшки только для адресов прописанных в файле /etc/hosts и полученных от встроенного DHCP. И какой смысл кэшировать записи находящиеся и так локально?
Вопрос. У меня такая ситуация - есть много локальных проектов, они все в зоне .dev, то есть, любой адрес, оканчивающийся на .dev отправляется апачу, который сам по нему определяет путь до сайта (то есть для создания нового сайта не нужны вообще никакие правки httpd.conf, используется mass hosting).
Так вот, я для этого использовал bind9, а можно ли такую же задачу решить этими инструментами (то есть резолвить все *.dev как 127.0.0.1)?
Так вот, я для этого использовал bind9, а можно ли такую же задачу решить этими инструментами (то есть резолвить все *.dev как 127.0.0.1)?
jerromo спасибо! второй пример с указанием конкретных dns серверов это то что надо. Все заработало как и хотел.
что то у меня с утра плохо думается сегодня, разжуйте поплиз... =)
в случае использования bind на локальной машине все ясно:
в /etc/resolv.conf прописываем nameserver 127.0.0.1 поднимаем bind на loopbak'e и в конфигурации bind указываем forvarders сервера у которых bind спрашивает то чего не знает.
А тут я что то запутался dnsmasq смотрит этот самый /etc/resolv.conf в котором те самые сервера у которых он спрашивает, а где же тогда говорить системе что ей надо искать DNS на loopback интерфейсе?
в случае использования bind на локальной машине все ясно:
в /etc/resolv.conf прописываем nameserver 127.0.0.1 поднимаем bind на loopbak'e и в конфигурации bind указываем forvarders сервера у которых bind спрашивает то чего не знает.
А тут я что то запутался dnsmasq смотрит этот самый /etc/resolv.conf в котором те самые сервера у которых он спрашивает, а где же тогда говорить системе что ей надо искать DNS на loopback интерфейсе?
DNS-сервер на интерфейсе, например eth0, указывается как 127.0.0.1. Как-то так наверное.
тут описанную картину меняет пакет resolvconf. Это именно он разруливает ситуацию с разными dns с разных интерфейсов. Во первых /etc/resolv.conf перестает быть файлом и становится симлинком на автоматом генерируемый файл. Его теперь руками править нельзя. Во вторых dnsmasq, как впрочем и bind, умеет сообщать resolvconf свой адрес и интерфейс (типа 127.0.0.1, после чего resolv.conf содержит только его). resolvconf все полученные адреса серверов по интерфейсам хранит в /etc/resolvconf/run/interface/, и вызывает скрипты /etc/resolvconf/update.d если информация обновилась. Все заинтересованные, в том числе dnsmasq и bind, имеют там свои обработчики и забирают себе адреса. И да bind тоже динамически добавляет сервера в forwarders {} у себя в конфиге (/var/run/bind/named.options).
Так что /etc/resolv.conf трогать не надо, кому надо тот адреса DNS узнает сам. А если надо прописать свои сервера руками, тогда либо в конфиги dnsmasq, bind, etc, либо в /etc/resolvconf/resolv.conf.d/{base|head|tail}.
PS. Получилось несколько сумбурно, но надеюсь понятно :)
Так что /etc/resolv.conf трогать не надо, кому надо тот адреса DNS узнает сам. А если надо прописать свои сервера руками, тогда либо в конфиги dnsmasq, bind, etc, либо в /etc/resolvconf/resolv.conf.d/{base|head|tail}.
PS. Получилось несколько сумбурно, но надеюсь понятно :)
А оно нормально дружит с Network Manager? Он ведь прямо в resolv.conf пишет.
я Network Manager не использую, поэтому точно сказать не могу. но скорее всего тут либо Network Manager либо resolvconf. Они по сути занимаются одним и тем же в плане DNS, т.е. разруливают разные сервера с разных интерфейсов. так что конфликт неизбежен.