Forward local domain queries to upstream dns что это

Обновлено: 01.07.2024

В сети Интернет DNS управляется через достаточно сложную систему авторизированных корневых серверов имён, и других менее крупных серверов имён, которые содержат и кэшируют информацию о конкретных доменах.

В этом документа рассматривается BIND 8.x, так как это стабильная версия, используемая во FreeBSD. BIND 9.x может быть установлен как порт net/bind9 .

Протокол DNS стандартизован в RFC1034 и RFC1035.

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

. является корневой зоной

org. является зоной ниже корневой зоны

1.2.3.in-addr.arpa является зоной, в которую включены все IP-адреса, формирующие пространство адресов 3.2.1.*.

Сервера имён обычно используются в двух видах: авторитетный сервер имён и кэширующий сервер имён.

Авторитетный сервер имён нужен, когда:

нужно предоставлять информацию о DNS остальному миру, отвечая на запросы авторизированно.

блоку адресов IP требуется обратные записи DNS (IP в имена хостов).

резервный (slave) сервер имён должен отвечать на запросы о домене, когда основной не работает или не доступен.

Кэширующий сервер имён нужен, когда:

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

требуется уменьшение общего сетевого трафика (DNS составляет около 5% всего трафика Интернет, или чуть больше).

Во FreeBSD даемон BIND, по очевидным причинам, называется named .

Файлы зон обычно располагаются в каталоге /etc/namedb и содержат информацию о зоне DNS, за которую отвечает сервер имён.

Так как сервер имён BIND устанавливается по умолчанию, его настройка сравнительно проста.

Чтобы даемон named запускался во время загрузки, сделайте следующие изменения в файле /etc/rc.conf

Для запуска даемона вручную (после его настройки)

Обязательно выполните следующие команды:

для того, чтобы правильно создать файл /etc/namedb/localhost.rev локальной обратной зоны для loopback-интерфейса.

Как и говорится в комментариях, если вы хотите получить эффект от использования кэша провайдера, то можно включить раздел forwarders . В обычном случае сервер имён будет рекурсивно опрашивать определённые серверы имён Интернет до тех пор, пока не получит ответ на свой запрос. При включении этого раздела он будет автоматически опрашивать сервер имён вашего провайдера (или тот, который здесь указан), используя преимущества его кэша. наличия нужной информации. Если соответствующий сервер имён провайдера работает быстро и имеет хороший канал связи, то в результате такой настройки вы можете получить хороший результат.

Warning: 127.0.0.1 здесь работать не будет . Измените его на IP-адрес сервера имён провайдера.

/* * If there is a firewall between you and name servers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; /* * If running in a sandbox, you may have to specify a different * location for the dumpfile. */ // dump-file "s/named_dump.db"; >; // Note: the following will be supported in a future release. /* host < any; >< topology < 127.0.0.0/8; >; >; */ // Setting up secondaries is way easier and the rough picture for this // is explained below. // // If you enable a local name server, don't forget to enter 127.0.0.1 // into your /etc/resolv.conf so this server will be queried first. // Also, make sure to enable it in /etc/rc.conf. zone "." < type hint; file "named.root"; >; zone "0.0.127.IN-ADDR.ARPA" < type master; file "localhost.rev"; >; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" < type master; file "localhost.rev"; >; // NB: Do not use the IP addresses below, they are faked, and only // serve demonstration/documentation purposes! // // Example secondary config entries. It can be convenient to become // a secondary at least for the zone where your own domain is in. Ask // your network administrator for the IP address of the responsible // primary. // // Never forget to include the reverse lookup (IN-ADDR.ARPA) zone! // (This is the first bytes of the respective IP address, in reverse // order, with ".IN-ADDR.ARPA" appended.) // // Before starting to setup a primary zone, better make sure you fully // understand how DNS and BIND works, however. There are sometimes // unobvious pitfalls. Setting up a secondary is comparably simpler. // // NB: Don't blindly enable the examples below. :-) Use actual names // and addresses instead. // // NOTE. FreeBSD runs bind in a sandbox (see named_flags in rc.conf). // The directory containing the secondary zones must be write accessible // to bind. The following sequence is suggested: // // mkdir /etc/namedb/s // chown bind:bind /etc/namedb/s // chmod 750 /etc/namedb/s

Дополнительная информация о запуске BIND в ограниченном окружении находится в соответствующем разделе .

Это примеры описаний прямой и обратной зон из файла named.conf для вторичных серверов.

Для каждого новой зоны, которую будет обслуживать сервер имён, в файл named.conf должна быть добавлена запись

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

Файл зоны имеет следующий формат:

recordname IN recordtype value

Наиболее часто используемые записи DNS:

начало зоны ответственности

авторитативный сервер имен

каноническое имя для алиаса

указатель на доменное имя (используется в обратных зонах DNS)

имя домена, а также ориджин для этого файла зоны.

основной/авторитативный сервер имён для этой зоны

последовательный номер файла. При каждом изменении файла зоны это число должно увеличиваться. В настоящее время для нумерации многие администраторы предпочитают формат ггггммддвв . 2001041002 будет означать, что файл последний раз изменялся 10.04.2001, а последнее число 02 означает, что это была вторая модификация файла за день. Последовательный номер важен, так как он служит для того, чтобы вторичные серверы узнавали об обновлении зоны.

localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30

Для файлов зон in-addr.arpa (обратные записи DNS) используется тот же самый формат, отличающийся только использованием записей PTR вместо A или CNAME .

В этом файле дается полное соответствие имён хостов IP-адресам в нашем описанном ранее вымышленном домене.

Кэширующий сервер имён - это сервер имён, не отвечающий ни за какую зону. Он просто выполняет запросы от своего имени и сохраняет результаты для последующего использования. Для настройки такого сервера достаточно исключить все описания зон из стандартной конфигурации сервера имён.

Note: Многие рекомендуют вместо настройки named на использование chroot , запускать named внутри jail (8) . В этом разделе такой подход не рассматривается.

Так как named не сможет обратиться ни к чему вне песочницы (например, совместно используемым библиотекам, сокетам протоколов и так далее), то нужно выполнить несколько шагов, чтобы named смог работать нормально. В следующем списке предполагается, что каталогом песочницы является /etc/namedb и что вы не делали никаких изменений в содержимом этого каталога. Выполните следующие шаги, работая как пользователь root .

Создайте все каталоги, которые ожидает увидеть named :

Измените и создайте базовые файлы зоны и настроек:

Если вы используете FreeBSD версии ранее 4.9-RELEASE, то постройте статически скомпонованную копию named-xfer и скопируйте её в песочницу:

После установки статически скомпонованного named-xfer , во избежание появления старых копий библиотек и программ в дереве исходного кода, требуется некоторая зачистка:

и удалите ваше дерево /usr/obj :

При этом из вашего дерева исходных текстов будет удалён весь ``мусор'', и повторение вышеописанных шагов должно выполниться успешно.

Если вы используете FreeBSD 4.9-RELEASE или более позднюю версию, то копия named-xfer в каталоге /usr/libexec по умолчанию является статически скомпонованной, и вы можете просто скопировать её в песочницу при помощи команды cp (1) .

Создайте файл устройства dev/null , который named может видеть и писать в него:

Создайте символическую ссылку /var/run/ndc на /etc/namedb/var/run/ndc :

Задайте запуск named и выполнение chroot в песочницу, добавив следующее в /etc/rc.conf :

named_enable="YES" named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"

Note: Заметьте, что конфигурационный файл /etc/named.conf именуется по полному имени относительно песочницы , то есть в вышеприведённой строке указывается файл, который на самом деле является файлом /etc/namedb/etc/named.conf .

Следующим шагом является редактирование файла /etc/namedb/etc/named.conf так, чтобы named знал, какую зону загружать и где найти их на диске. Далее следует прокомментированный пример (все, что специально не прокомментировано, ничем не отличается от настройки сервера DNS, работающего не в песочнице):

options < directory "/"; named-xfer "/bin/named-xfer"; version ""; // Не выдавайте версию BIND query-source address * port 53; >; // управляющий сокет ndc controls < unix "/var/run/ndc" perm 0600 owner 0 group 0; >; // Далее следуют зоны: zone "localhost" IN < type master; file "master/named.localhost"; allow-transfer < localhost; >; notify no; >; zone "0.0.127.in-addr.arpa" IN < type master; file "master/localhost.rev"; allow-transfer < localhost; >; notify no; >; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" < type master; file "master/localhost-v6.rev"; allow-transfer < localhost; >; notify no; >; zone "." IN < type hint; file "master/named.root"; >; zone "private.example.net" in < type master; file "master/private.example.net.db"; allow-transfer < 192.168.10.0/24; >; >; zone "10.168.192.in-addr.arpa" in < type slave; masters < 192.168.10.2; >; file "slave/192.168.10.db"; >;

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

Tip: Если возникают проблемы, то наличие последних исходных текстов и свежеоткомпилированного named не помешает.

Подскажите, что нужно сделать, чтобы компьютеры в одной локальной сети видели сетевые устройства в другой сети? Две локалки объединены через PPTP туннель средствами роутеров (Asus RT-N16 с прошивкой asuswrt-merlin). Сетевые устройства во второй сети пингуются, но в сетевом окружении не видны. Сетевое обнаружение включено. Заранее спасибо!

Включить Samba в настройках Vpn сервера?

Поддержка сетевого окружения (Samba) в VPN сервере изначально включена.

"Видимость" устройств по виндовым протоколам работает либо в пределах сегмента Layer 2 (что не есть случаем объединения двух подсетей туннелем PPTP), либо через какой-нибудь WINS сервер. Соответственно, WINS сервер должен существовать, и его айпишник должен быть прописан в сетевых настройках (или раздаваться через DHCP отдельной опцией).

Спасибо за разъяснение о WINS сервере. В настройках опций локальной сети в роутере есть "Настройка сервера DNS и WINS" - там можно внести адреса серверов DNS и WINS. Есть опция "Forward local domain queries to upstream DNS" (вкл./откл.). Но может ли быть сервер WINS в самом роутере? Хочется, чтобы не только Windows устройства могли видеть друг друга, находясь в разных подсетях, но например медиаплеер в первой подсети видел NAS в другой.

Работаю практически в такой же конфигурации, "видимостью" не заморачивался. Для подключения шар иду с МАСа прямо smb://<adr>, из Винды аналогично Поиск //<adr>, и подключаю постоянные шары.

serhiy69 29.05.2014 13:53 пишет:
Спасибо за разъяснение о WINS сервере. В настройках опций локальной сети в роутере есть "Настройка сервера DNS и WINS" - там можно внести адреса серверов DNS и WINS. Есть опция "Forward local domain queries to upstream DNS" (вкл./откл.). Но может ли быть сервер WINS в самом роутере? Хочется, чтобы не только Windows устройства могли видеть друг друга, находясь в разных подсетях, но например медиаплеер в первой подсети видел NAS в другой.

Если адреса серверов DNS и WINS настраиваются в разделе DHCP сервер - то это опции, которые раздаются клиентам. Сами серверы должны работать в сети отдельно. Я не знаю, можно ли поднять функционал WINS сервера на прошивке твоих роутеров, чтобы не выделять для этого отдельный компьютер. Надо смотреть на спецификацию прошивки.

А вообще то, что устройства не видят друг друга через "Сетевое окружение", еще не означает, что они друг другу недоступны: можно их ресурсы подключать, явно вводя путь к ресурсу через ip адрес вместо имени компьютера в удаленной сети.

serhiy69 29.05.2014 08:22 пишет:
Подскажите, что нужно сделать, чтобы компьютеры в одной локальной сети видели сетевые устройства в другой сети? Две локалки объединены через PPTP туннель средствами роутеров (Asus RT-N16 с прошивкой asuswrt-merlin). Сетевые устройства во второй сети пингуются, но в сетевом окружении не видны. Сетевое обнаружение включено. Заранее спасибо!

Для этого надо чтобы броадкасты между сетями ходили. По дефолту они режутся.
На циске такое делал с помощью ip helper-address. Были видны машины из других сеток.

На домашнем Asus-е стоит прошивка от Padavan-а, там есть такая настройка для PPtP:

По идее должно посылать броадкасты от клиента и обратно.
Никогда не пользовался этой штукой правда.

WINS, если есть Windows Server в сетке - лучше поставить там, если нет, то на самбе включить wins support = yes в секции global

В этой статье будет описано как правильно настроить работу DNS.

Прежде чем выбрать путь настройки, убедитесь, что на машине с UserGate на интерфейсе, который смотрит во внешнюю сеть (WAN), имеются DNS провайдера или внешние крупные DNS, на интерфейсе, который смотрит в локальную сеть (LAN), отсутствует шлюз и DNS (прописаны только адрес и маска). Внимание! Убедитесь, что на внешнем интерфейсе прописано не более трех DNS-адресов, иначе могут быть вызваны ошибки с обработкой запроса и страницы в браузере могут открываться долго . Если все так, тогда можно идти дальше.

Существуют четыре основных пути настройки DNS:

1. В локальной сети отсутствует DNS-сервер на машине с контроллером домена.

В этом случае настройка производится следующим образом:

Включить DNS-форвардинг на использование системных настроек в консоли администратора во вкладке Настройка DNS.
*На клиентских компьютерах требуется прописать в качестве шлюза и DNS LAN-интерфейс машины с UserGate.

В данном случае нужно настраивать DNS следующим образом:

3. В локальной сети присутствует DNS-сервер на машине с контроллером домена и это та же машина, на которой стоит UserGate.

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

Отключить DNS-форвардинг в консоли администратора во вкладке Настройка DNS.
*На клиентских компьютерах требуется прописать в качестве шлюза и DNS LAN-интерфейс машины с UserGate.

4. Машины из локальной сети имеют шлюзом отличную от машины с UserGate машину (например RRAS сервер, поднятый в Windows Server ****).

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

Включить DNS-форвардинг на использование DNS-адресов из списка в консоли администратора во вкладке Настройка DNS, где в списке надо прописать DNS провайдера или любой крупный внешний интерфейс.

В самом DNS-форвардинге имеется возможность поменять порт (по умолчанию стоит 5458, однако лучше без крайней необходимости этого не делать), изменить тайм-аут DNS-запроса (по умолчанию 7000, который тоже не рекомендуется менять, если нет представления о том, как это работает), включить/отключить кэш DNS-записей и изменить их число при включенном кэш. Кэш снижает нагрузку на сервер, благодаря тому, что ответ на запрос берется из кэша, если данный адрес уже вызывался.

Если после корректной настройки согласно данной статье у вас появляется в браузере ошибка 10065, то обратитесь к данной статье.

Относится к: Windows Server (Semi-Annual Channel), Windows Server 2016 Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Режим AD является устаревшим, начиная с Windows Server 2019. AD mode is deprecated beginning with Windows Server 2019. Для сред, в которых невозможно подтвердить аттестацию доверенного платформенного модуля, настройте аттестацию ключа узла. For environments where TPM attestation is not possible, configure host key attestation. Аттестация ключа узла обеспечивает аналогичные гарантии в режиме AD и проще в настройке. Host key attestation provides similar assurance to AD mode and is simpler to set up.

Выполните следующие действия, чтобы настроить пересылку DNS и установить одностороннее отношение доверия с доменом структуры. Use the following steps to set up DNS forwarding and establish a one-way trust with the fabric domain. Эти действия позволяют службе HGS размещать контроллеры домена структуры и проверять членство в группе узлов Hyper-V. These steps allow the HGS to locate the fabric domain controllers and validate group membership of the Hyper-V hosts.

Чтобы создать одностороннее доверие лесов, выполните следующую команду в командной строке с повышенными привилегиями: To create a one-way forest trust, run the following command in an elevated Command Prompt:

Finishing bits of technology, vintage and new.

Using ASUSWRT for Local DNS and DHCP

A little background on ASUSWRT. ASUSWRT is the firmware ASUS ships on current routers. It started as a fork of the Tomato firmware project. Tomato is similar to DD-WRT. ASUSWRT-Merlin is an enhanced, and fixed (some), version of the ASUS supplied ASUSWRT.

Post Switch Concerns

After switching to ASUSWRT from DD-WRT I thought I would be losing the ability to serve local DNS. I was wrong. I loaded ASUSWRT-Merlin on my ASUS RT-N66U. After some trial and error configuration I discovered local DNS is alive and well in ASUSWRT-Merlin.

There is one minor caveat in that local DNS only works for DHCP served addresses, unless you further modify the dnsmasq configuration from the command line. I spent a lot of time managing non-DHCP addresses in that fashion with DD-WRT, and want to make management as simple as possible. The dnsmasq service used by ASUSWRT operates as a masquerading forwarding DNS server.

With DD-WRT I had non-DHCP addresses allocated in a certain range (0-99), and DHCP addresses from 100 to 255. Within the DHCP addresses I reserved the first 20 (via DHCP reservations) for our devices. Which let any guests pickup other addresses. Why?

With DD-WRT I broke the DHCP range into two and had QOS rules in place for each group. Guest addresses received tighter restrictions and lower bandwidth. Managing these in DD-WRT was a pain. The ASUSWRT makes it a lot simpler to accomplish the same things.

Local DNS Setup

I couldn’t find any definitive guides on setting this up, only that it could be done. So heres how. Before proceeding, to make things easier, make sure all devices in the ASUS Client list have a name showing up. If the name doesn’t show up, click it’s MAC address (top one) and define it in the pop-up window that appears.

Open the LAN menu, and “DHCP Server” tab. A few things to note:

a) “Enable the DHCP Server” should be Yes.

b) The routers Domain Name can be blank or you can set it to what you want, just don’t use one of the top level domains like com, net, org, etc. I chose “home”. This makes all hosts on my network resolvable as “hostname.home”.

c) Set the DHCP starting and ending range, for example 192.168.1.10 to 192.168.1.150. The subnet and final address are blocked out in the image. For the subnet, it should be the same as the routers defined subnet. If you defined the routers address as 192.168.1.1 then the IP range should be on subnet 1. I don’t use 1.

d) The “Default Gateway” is the gateway that clients will route through.

e) Now the DNS settings need special attention:

If you select Yes for “Advertise routers IP in addition to user specified DNS”, then the routers address will be appended to the DNS address list given to the clients when they lease an IP address. I said “appended” meaning it will be LAST!

So if you want to be able to resolve names on your network without specifying the routers address as the name server to do the resolution (i.e.: nslookup – 192.168.1.1), then you should make sure the Advertise setting is set to No, and put the routers address in “DNS Server 1”. This puts the router in the list FIRST! Apply your secondary (if any) in “DNS Server 2”.

The last thing surrounding DNS, which ties into the router domain defined above, is the “Forward local domain queries to upstream DNS”. This should be No. You don’t want a query for “xbox.home” to be passed up to be resolved at the internet level. You want it to stay on your network.

f) Click the Apply button when done.

I typically assign a static address to devices that I want to always be at a certain address (like a printer, NAS drive, etc). I typically setup appliances like streaming players and TV’s with static addresses too since they really don’t need to change.

I still wanted to resolve the problem where these non-DCHP devices (devices with static IP assignments) could be resolved on the network WITHOUT having to modify configuration from the command line. Remember, simple, low maintenance.

To resolve this I changed all devices with static IP’s to DHCP. Bonus that makes device setup simpler too. I then setup DHCP reservations for them within the DHCP pool in a particular range (99 or less). This way I can easily identify “appliances” from computing devices.

a) Set the “Enable Manual Assignment” to Yes.

b) Use the dropdown to select a device, which will have the MAC address or device name (if it was given by the requesting client or defined manually on the ASUSWRT Client list).

c) Set the address (it will default to whatever it was assigned by the server). If you want to change it, change it.

d) Click the + button.

e) Click the Apply button.

Traffic Control

With DD-WRT I had devices setup in ranges with guest range relegated to low bandwidth and peer to peer services blocked. I want the same thing with ASUSWRT. I also had my devices defined with particular classes of service.

The ASUSWRT firmware has defaults based on traffic type, mainly surrounding file transfer.

Once enabled you can delete the default ones, and add custom ones.

I added the peer to peer services using the service name drop down and selecting the common ones. To add, select it, set the priority, and click the + sign icon.

I then added my devices, this time using the Source IP or Mac dropdown. The name will show up if it was offered by the requesting client or was manually defined on the ASUS Client list. This makes it a cinch to add, unlike DD-WRT where you add each device by MAC address only.

Once defined, click the Apply button.

So what about the lower priority guest traffic? With ASUSWRT, any traffic not matching a rule gets routed to the “Low” setting. I have my low and lowest settings set to use very little bandwidth.

I now have ASUSWRT doing everything DD-WRT was doing, and without command line management.

Oh, and now is a good time to backup the configuration using the Administration/Save feature.

Подробное объяснение dnsmasq и его использования в openstack и контейнерах

Чтобы понять Dnsmasq, он все еще начинает с изучения нейтронной сети с открытым стеком. В сети с открытым стеком dnsmasq предоставляет функции dhcp и dns для указанной сети. Этот процесс в фоновом режиме выглядит следующим образом:

Этот процесс запускается, когда функция подсети dhcp или dns включена.Если функция dhcp или dns нескольких подсетей включена в одной сети, процесс запуска dnsmasq в первый раз в сети будет изменен. То есть, если процесс dnsmasq запущен в первой подсети, подсеть под сетью связи, созданной позже, не перезапустит новый процесс, но изменит процесс, запущенный в первый раз. Следующим образом:
Подсеть запускает процесс dnsmasq:

Две подсети запускают процесс dnsmasq:

Мы обнаружим, что функция dhcp или dns дополнительной подсети будет изменена только в процессе dnsmasq, созданном в первый раз, и будет добавлена соответствующая информация о второй подсети, например: --dhcp-range = set: tag1,10.11 .0.0, статический, 255.255.255.0,86400 с. Здесь кратко упоминается Dnsmasq об openstack, давайте поговорим об общей функции dnsmasq.

Dnsmasq （dnsmasq）
Предоставляет функции DNS-кэша и службы DHCP. Будучи сервером разрешения доменных имен (DNS), dnsmasq может кэшировать DNS-запросы, чтобы увеличить скорость нашего соединения с посещаемыми веб-сайтами. В качестве DHCP-сервера dnsmasq может предоставлять IP-адреса в интрасети и маршрутизацию для компьютеров (облачных хостов) в локальной сети (например, сети в openstack). Две функции DNS и DHCP могут быть реализованы одновременно или по отдельности. dnsmasq является легким и простым в настройке, подходит для отдельных пользователей или сетей с менее чем 50 хостами.

Давайте поговорим о конфигурации dnsmasq, файл конфигурации dnsmasq находится в /etc/dnsmasq.conf, или он может находиться в / etc / default / dnsmasq, /etc/dnsmasq.d/ или / etc / dnsmasq из-за вашей другой версии Linux В каталоге d-available / мы также можем указать адрес файла конфигурации при запуске процесса dnsmasq или вызвать другие файлы конфигурации с помощью опции conf-file = в файле конфигурации. Они могут быть гибко определены в соответствии с потребностями.
Ниже приведены выдержки из dnsmasq.conf, которые являются важными и часто используемыми элементами конфигурации и краткими описаниями:

Не читать ни одного сервера. Файл /etc/resolv.conf по умолчанию можно настроить с помощью resolv-файла
не загружать локальный файл / etc / hosts

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

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

Укажите пользователей и группы

Укажите порт DNS, по умолчанию 53, установите порт = 0, чтобы полностью отключить функцию DNS, использовать только DHCP / TFTP

Установить размер кеша DNS (единица измерения: количество разрешений DNS)

Кэш неизвестного доменного имени не кэшируется. По умолчанию dnsmasq кэширует неизвестное доменное имя и возвращает его непосредственно клиенту.

Укажите номер пересылки DNS-запроса

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

Определите, где dnsmasq получает адрес вышестоящего DNS-сервера, по умолчанию его получают из /etc/resolv.conf

Указывает, что разрешение DNS выполняется строго сверху вниз в порядке в файле resolv-файла, пока первое разрешение не будет успешным

Привязать интерфейс, открыть этот пункт будет слушать только указанный интерфейс.

Недавно добавленный интерфейс также связан.

Ограничьте сетевые интерфейсы, которые слушает Dnsmasq

Укажите интерфейс, который нужно исключить из прослушивания, с высоким приоритетом, чтобы исключить, вы можете использовать подстановочный знак '*'

Указывает интерфейс, который не предоставляет службы DHCP или TFTP, а предоставляет только службы DNS.

dhcp динамически распределяемый диапазон адресов

Статическая привязка службы DHCP

Установить аренду по умолчанию

Аренда сохранена в следующем файле

Игнорирование запроса DHCP для MAC-адреса ниже

Домен, в котором находится dhcp

Установите выход по умолчанию для маршрута, опция 3 - маршрут по умолчанию, 10.10.10.1 - шлюз

После прочтения файла конфигурации давайте взглянем на параметры процесса dnsmasq, которые можно настроить:
Вы можете обратиться к документации на английском языке:анализ параметров командной строки dnsmasq

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

Далее мы проанализируем параметры процесса dnsmasq в openstack в приведенной выше конфигурации:

Dnsmasq также установлен в контейнере, следующая установка для версии centos7:

Прост в использовании:

Простая топология сети выглядит следующим образом: создайте следующую сеть в среде ovs + kvm, процесс dnsmasq прослушивает устройство DHCP tap1, широковещательные пакеты dhcp, отправленные хостом host1 и host2, принимаются tap1, процесс dnsmasq найдет соответствующий mac в соответствующем файле хоста. Ip доставляется на хост. Если он не найден, хост не может получить ip.

Для этой среды, пожалуйста, смотрите:Настройка тестовой среды

Запишите mac двух хостов в соответствующий файл хоста:

Введите виртуальную машину для автоматического получения теста ip:

Чтобы запустить dnsmasq в контейнере, контейнер должен быть запущен в сетевом режиме net = host, чтобы можно было отслеживать интерфейс dhcp_tap на хосте и сохранять такие файлы, как host и pid, в контейнере.

Начать процесс в контейнере

Примечание. Если процесс dnsmasq запускается в качестве входной программы в контейнере, необходимо добавить параметр -d, чтобы процесс мог запускаться на переднем плане, а не в фоновом режиме.

После тестирования, когда виртуальная машина получает IP, процесс сообщает о следующей ошибке:

Операция не разрешена, вот из-за проблемы с разрешениями, при создании контейнера вы можете дать режим привилегий.

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

Для настройки форвардинга, проделайте следующее:

1. На главной странице модуля нажмите на значок Forwarding and Transfers(Форвардинг и Трансфер).

Рисунок 1 - Главная страница модуля BIND. Для увеличения картинки, нажмите на неё

2. В открывшейся форму заполните поле Servers to forward queries to(Серверы к которым направлять запросы) IP адресами DNS серверов, к которым будет происходить перенаправление(форвардинг).

BIND будет обращатся к этим серверам в том порядке, в которомы они представлены в списке.

Если список будет пуст, то DNS сервер пойдет по обычному пути, начиная с root зон.

3. Если вы хотите, чтобы ваш DNS сервер, не найдя нужной записи на DNS серверах из списка, шёл по обычному пути через root зоны, то установите значение поля Lookup directly if no response from forwarder(Идти напрямую, если DNS серверы из списка не имеют нужной записи) в Yes(Да). Это будет полезно, только в том случае, если ваш файрволл(firewall) позволит идти напрямую через root серверы.

Рисунок 2 - Форма редактирования настроек форвардинга и трасфера зон. Для увеличения картинки, нажмите на неё

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

1. На главной странице модуля нажмите на значок Forwarding and Transfers(Форвардинг и Трансфер).

2. По умолчанию, BIND будет ожидать трансфер зоны 120 минут. Для изменения этого, введите требуемое число минут в поле Maximum zone transfer time(Максимальное время трансфера зоны). Эта настройка может быть перекрыта значением, указанным для некоторой зоны отдельно.

3. BIND версии 8.1 поддерживает трансфер только одной зоны за раз. Если зон много, то их трансфер затянется на некоторое время. Это время может быть достаточно большим. В случае такой ситуации установите значение поля Zone transfer format(Формат трансфера зоны) в Many(Множественный) для использования нового формата трансфера зон. Этот формат позволяет ускорить процесс трансфера зон. Если установлено значение One at time(Один за раз) или Default(По умолчанию), то за раз будет производится трансфер только одной зоны.

4. По умолчаню, ваш DNS сервер использует два одновременных потока для трансфера зоны. Чтобы изменить это значение, отредактируйте поле Maximum concurrent zone transfers(Максимальное количество одновременных трансферов). Увеличение этого значения ускорит процесс трансфера, но также и увеличит нагрузку на master сервер.

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