Isc bind что это
Эта часть фокусируется на предотвращении использования ISC BIND/DNS, как точки прерывания для доступа к системе. Так как ISC BIND/DNS выполняет относительно большую и комплексную функцию, вероятность возникновения ошибки, затрагивающей защиту, высока. Фактически, в прошлом имелись дефекты, которые позволяли удаленному пользователю получить root доступ к серверу с запущенным BIND.
Основная выгода chroot состоит в том, что в результате ограничивается часть файловой системы, которую DNS демон может видеть, корневым каталогом «окружения». Так как «окружение» создается только для поддержки DNS, число программ связанных с ISC BIND/DNS и доступных в этой части файловой системы чрезвычайно ограничено. Наиболее важно то, что здесь отпадает необходимость в setuid-root программах, которые могут быть использованы для получения root доступа и взлома «окружения».
ЗАМЕЧАНИЕ: Исполняемая программа «named» должна располагаться в каталоге, описанном в переменной PATH. В этом документе, я буду считать, что путь к named будет «/usr/sbin/named».
Для запуска ISC BIND/DNS в chroot «окружении» необходимо сделать слеующие шаги:
Для поиска подобных библиотек используйте следующую команду:
[root@deep /]# ldd /usr/sbin/named
libc.so.6 => /lib/libc.so.6 (0x40017000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Сделайте себе соответствующую отметку, чтобы можно было использовать ее позже на следующих шагах.
Сейчас мы должны определить chroot окружение и создавать корневой каталог для него. Мы выбрали каталог «/chroot/named», потому что хотим разместить ее на независимом разделе, чтобы предотвратить атаки на файловую систему. Раньше, во время инсталляции Linux мы создали раздел «/chroot» специально предназначенный для этого.
Сейчас копируем основные конфигурационные файлы, файлы с описаниями зон, программы named named-xfer в необходимые места:
ВАЖНОЕ ЗАМЕЧАНИЕ. Для подчиненного сервера имен владельцем каталога «/chroot/named/var/named» и всех файлов расположенных в нем должен быть процесс с «named», иначе вы не сможете осуществить пересылку зоны. Чтобы сделать на подчиненном сервере владельцем каталога «named» и всех файлов лежащих в нем пользователя «named» используйте следующую команду:
Копируйте разделяемые библиотеки определенные на шаге 1 в chroot каталог lib:
[root@deep /]# cp /lib/libc.so.6 /chroot/named/lib/
[root@deep /]# cp /lib/ld-linux.so.2 /chroot/named/lib/
Копируйте файлы «localtime» и «nsswitch.conf» в chroot каталог etc, чтобы элементы файлов регистрации были правильно установлены для вашей временной зоны:
[root@deep /]# cp /etc/localtime /chroot/named/etc/
[root@deep /]# cp /etc/nsswitch.conf /chroot/named/etc/
Для большей безопасности на некоторые файлы из каталога «/chroot/named/etc» мы должны установить бит постоянства:
[root@deep /]# cd /chroot/named/etc/
[root@deep etc]# chattr +i nsswitch.conf
[root@deep /]# cd /chroot/named/etc/
[root@deep etc]# chattr +i named.conf
Файл с атрибутом «+i» не может быть модифицирован, удален или переименован; к нему не может быть создана ссылка и никакие данные не могут быть записаны в него. Только суперпользователь может установить или снять этот атрибут.
Добавьте новый UID и новый GID для запуска демона «named», если они еще не определены. Это важно, так как запуск его как root нарушит правильное функционирование «окружения», а использование существующих пользовательских id позволит вашему сервису получить доступ к другим ресурсам.
Проверьте файлы «/etc/passwd» и «/etc/group» на наличие свободных UID/GID. В нашем примере, мы используем номер «53» и имя «named».
Мы должны сказать syslogd (демону системы syslog) о новом chrooted сервисе: Обычно, процессы обращаются к syslogd через «/dev/log». chroot-овое «окружение», этого сделать не сможет, поэтому syslogd необходимо объяснить, что нужно слушать «/chroot/named/dev/log» вместо принятого по умолчанию «dev/log». Чтобы сделать это, нужно редактировать скрипт запуска syslog.
Редактируйте скрипт syslog (vi +24 /etc/rc.d/init.d/syslog) и измените следующую строку:
Скрипт для запуска ISC BIND/DNS по умолчанию настроен для запуска его вне chroot «окружения». Мы должны внести следующие изменения в файл named (vi /etc/rc.d/init.d/named), чтобы исправить это:
Опция «-t» говорит «named» запускаться, используя новое chroot окружение.
Опция «-u» определяет пользователя от имени которого стартует named.
Опция «-g» определяет группу от имени которой стартует named.
В BIND 8.2, команда «ndc» стала двоичным файлом (ранее, это был скрипт), которая в этой конфигурации не работает. Чтобы исправить это, пакет ISC BIND/DNS должен быть скомпилирован из исходных кодов.
[root@deep /]# cp bind-src.tar.gz /vat/tmp
[root@deep /]# cd /var/tmp/
[root@deep tmp]# tar xzpf bind-src.tar.gz
[root@deep tmp]# cd src
[root@deep src]# cp port/linux/Makefile.set port/linux/Makefile.set-orig
Редактируем файл Makefile.set (vi port/linux/Makefile.set) и делаем в нем следующие изменения:
Различие между Makefile, который мы использовали прежде и новым, заключается в изменении строк «DESTSBIN=», «DESTEXEC=» и «DESTRUN=». В них мы задаем новое месторасположение файлов и теперь программа «ndc» будет знать, где находится «named».
[root@deep src]# make clean
[root@deep src]# make
[root@deep src]# cp bin/ndc/ndc /usr/sbin/
[root@deep src]# cp: overwrite `/usr/sbin/ndc’? y
[root@deep src]# strip /usr/sbin/ndc
Мы создали двоичный файл, а затем копируем полученную программу «ndc» в «/usr/sbin», переписывая старую. Мы не должны забыть выполнить команду strip для улучшения производительности.
Также хорошей идеей будет создание новых двоичных файлов «named» и «named-xfer», чтобы грантировано использовать одну и туже версию «named» и «ndc».
[root@deep /]# cd /var/tmp/src
[root@deep src]# cp port/linux/Makefile.set-orig port/linux/Makefile.set
[root@deep src]# cp: overwrite `port/linux/Makefile.set’? y
Редактируйте файл Makefile.set (vi port/linux/Makefile.set) и внесите в него следующие изменения:
Мы удалили файл «.settings», так как система кэширует в нем переменные и выполнили команду «make clean», чтобы убедиться, что у нас не возникнут старые наложения. После того, как создан файл «named», мы копируем его вместе с «named-xfer» в chroot каталог и используем команду «strip» для улучшения производительности новых исполняемых файлов.
Удаление ненужных файлов и каталогов.
Мы удаляем «named» и «named-xfer» из «/usr/sbin», так как они будут теперь запускаться из chroot каталога. Тоже самое проделываем и для файла «named.conf» и каталога «/var/named».
Мы должны тестировать новую chroot-овую конфигурацию ISC BIND/DNS.
Первое, перезапустите ваш syslogd демон:
Теперь можно запустить chroot версию ISC BIND/DNS:
Проверяем, что ISC BIND/DNS запущен от имени пользователя «named» с новыми аргументами:
Очистка после работы
Эта команда перемещает исходные файлы и tar архив, которые мы использовали при компиляции и инсталляции ISC BIND/DNS.
Для получения большей информации вы можете читать следующие страницы руководства:
Административные средства DNS
Команды описанные ниже мы будем часто использовать, но на самом деле их много больше, и вы должны изучить man-страницы и документацию для получения деталей.
Утилита «dig» (domain information groper) может быть использована для обновления файла «db.cache», который говорит вашему серверу какие сервера отвечают за корневую зоны. Такие сервера изменяются чрезвычайно редко. Хорошей идеей будет обновлять ваш файл каждые один-два месяца.
Используйте следующую команду для получения нового файла db.cache:
Копируйте, полученный файл db.cache в каталог /var/named/.
[root@deep /]# cp db.cache /var/named/
Утилита «ndc», входящая в ISC BIND/DNS, позволяет системному администратору из терминала интерактивно контролировать деятельность сервера имен.
Наберите на вашем терминале ndc и затем help, чтобы увидеть список доступных команд.
Утилиты пользователя DNS
Команды описанные ниже мы будем часто использовать, но на самом деле их много больше, и вы должны изучить man-страницы и документацию для получения деталей.
Программа nslookup позволяет пользователям интерактивно или не интерактивно запрашивать сервера имен Интернет. В интерактивном режиме пользователи могут запрашивать у серверов имен информацию о различных хостах и доменах, печатать список хостов в домене. В не интерактивном режиме пользователь может получить имена и запросить информацию о хостах и доменах.
Интерактивный режим имеет много опций и команд; рекомендуется прочитать страницу руководства для nslookup или дать команду help в интерактивном режиме.
Для запуска nslookup в интерактивном режиме используйте команду:
Команды: (идентификаторы представлены в верхнем регистре, что делать не обязательно)
Для запуска в не интерактивном режиме используйте команду:
[root@deep /]# nslookup www.redhat.com
Server: deep.openna.com
Address: 208.164.186.1
Non-authoritative answer:
Name: www.portal.redhat.com
Addresses: 206.132.41.202, 206.132.41.203
Aliases: www.redhat.com
Где это имя или Интернет адрес о котором вы хотите получить информацию.
Программа dnsquery запрашивает сервера имен через библиотеку определителей.Для организации запроса на сервер имен, используя библиоткеку определителей, введите следующую команду:
Программа host определяет имя хоста, используя DNS. Для определения имен хоста используя сервер имен, введите следующую команду:
[root@deep /]# host redhat.com
redhat.com has address 207.175.42.154
Для поиска всей информации предоставляемой DNS о хосте используйте команду:
Для получения полного описания домена используйте команду:
BIND 9
Versatile, classic, complete name server software
Why use BIND 9?
BIND 9 has evolved to be a very flexible, full-featured DNS system. Whatever your application is, BIND 9 probably has the required features. As the first, oldest, and most commonly deployed solution, there are more network engineers who are already familiar with BIND 9 than with any other system.
BIND 9 is transparent open source, licensed under the MPL 2.0 license. Users are free to add functionality to BIND 9 and contribute back to the community through our open Gitlab.
If you want source code, download current version from the ISC website or our FTP site. Or, install our updated ISC packages for Ubuntu, CentOS/Fedora, and the standard Debian package. If you prefer Docker, get our official Docker image.
Help is available via our community mailing list, or you may purchase a support subscription for expert, confidential, 24Г—7 support from the ISC team.
BIND Uses on the Internet
Almost every Internet connection starts with a DNS lookup
Before your mail server sends an email, before your web browser displays a web page, there is a DNS lookup to resolve a DNS name to an IP address. Watch this DNS Fundamentals presentation from Eddy Winstead of ISC or read A Warm Welcome to DNS by Bert Hubert of PowerDNS.
BIND 9 on the Internet
BIND is used successfully for every application from publishing the (DNSSEC-signed) DNS root zone and many top-level domains, to hosting providers who publish very large zone files with many small zones, to enterprises with both internal (private) and external zones, to service providers with large resolver farms.
Getting Started
Choosing a version
We support three major branches of BIND 9 at a time: Stable, Extended-Support, and Development. See this advice: Which version of BIND do I want to download and install? as well as our list of supported platforms.
If you would prefer a GUI management interface, you might consider a Commercial Product based on BIND.
Installation
Configuration
The BIND Administrator Reference Manual (ARM) included in the BIND distribution is the primary reference for BIND configuration. See the Best Practices documents in our Knowledgebase for configuration recommendations.
Resolver users may find Getting started with Recursive Resolvers to be useful. There are a number of excellent books on BIND; Ron Hutchinson’s DNS for Rocket Scientists is generously posted on the Internet at Zytrax.com and can be a very helpful online reference tool.
Maintenance
Most users will benefit from joining the bind-users mailing list. We advise all users to subscribe to bind-announce@lists.isc.org to get announcements about new versions and security vulnerabilities. For other news, see our BIND blogs.
Our partners at Men and Mice run a very good series of hands-on training classes. If your DNS is critical to your business, we recommend you subscribe for technical support from ISC.
An authoritative DNS server answers requests from resolvers, using information about the domain names it is authoritative for. You can provide DNS services on the Internet by installing this software on a server and giving it information about your domain names. The BIND 9 documentation includes a description of the Primary/Secondary/Stealth Secondary roles for authoritative servers.
Response Rate Limiting (RRL) is an enhancement to named to reduce the problem of “amplification attacks” by rate-limiting DNS responses. This feature is on by default because it has proven to be so effective; it’s now even more effective with DNS Cookies, which focus rate-limiting on unknown clients. DNS cookies, per RFC 7873, are exchanged between client and server to provide IP address identity, helping to prevent attacks using forged IP addresses. Servers enforcing cookies are less susceptible to being used as an effective attack vector for DNS DDOS attacks.
Minimal ANY Responses
Queries for ANY records are a possible abuse mechanism because they typically extract a response much larger than the query. The minimal-any option reduces the size of answers to UDP queries for type ANY by implementing one of the strategies in “draft-ietf-dnsop-refuse-any”: returning a single arbitrarily-selected RRset that matches the query name rather than returning all of the matching RRsets.
Dynamically-Loadable Zones (DLZ) enable BIND 9 to retrieve zone data directly from an external database. Not recommended for high-query rate authoritative environments.
Minimum Re-load Time
Update your BIND 9 server zone files with the remote name daemon control (rndc) utility, without restarting BIND 9. For those times when you do have to restart, the ‘map’ zone file format can dramatically speed up reloading a large zone file into BIND 9, such as on restart.
HSM Support
HSMs are used to store key material outside of BIND 9 for security reasons. BIND 9 supports the use of Hardware Security Modules through either a native PKCS#11 interface, or the OpenSSL PKCS#11 provider. From BIND 9.18 and beyond, only the OpenSSL PKCS#11 provider, which ISC has helped to improve, will be supported.
DNSSEC with In-line Signing
BIND 9 fully supports DNSSEC and has a mature, full-featured, easy-to-use implementation. Once you have initially signed your zones, BIND 9 can automatically re-sign dynamically updated records with inline signing. BIND’s Key and Signing Policy utility will help you maintain your DNSSEC implementation, periodically updating keys and signatures according to the policy you establish.
Catalog Zones
Catalog zones facilitate the provisioning of zone information across a nameserver constellation. Catalog zones are particularly useful when there is a large number of secondary servers. This feature will automatically propagate new zones added to the primary to the secondary servers, or remove zones deleted from the primary, eliminating the need for separate scripts to do this.
DNSTAP
Dnstap is a fast, flexible method for capturing and logging DNS traffic, developed by Robert Edmonds at Farsight Security, Inc. Dnstap is supported by several open-source DNS servers, including BIND. Using dnstap enables capturing both query and response logs, with a reduced impact on the overall throughput of the BIND server than native BIND logging. Messages may be logged to a file or to a UNIX socket. Support for log-file rotation will depend on which option you choose. A utility ‘dnstap-read’ has been added to allow dnstap data to be presented in a human-readable format.
Scaleable Primary-Secondary Hierarchy
A DNS authoritative system is composed of a primary with one or more secondary servers. Zone files are established and updated on a primary server. Secondaries maintain copies of the zone files and answer queries. This configuration allows scaling the answer capacity by adding more secondaries, while zone information is maintained in only one place. The primary signals that updated information is available with a NOTIFY message to the secondaries, and the secondaries then initiate a zone transfer from the primary. BIND 9 fully supports both the AXFR (complete transfer) and IXFR (incremental transfer) methods, using the standard TSIG security mechanism between servers. There are a number of configuration options for controlling the zone updating process.
A resolver is a program that resolves questions about names by sending those questions to appropriate servers and responding to the servers’ replies. In the most common application, a web browser uses a local stub resolver library on the same computer to look up names in the DNS. That stub resolver is part of the operating system. The stub resolver usually will forward queries to a caching resolver, a server or group of servers on the network dedicated to DNS services. Those resolvers will send queries to one or multiple authoritative servers in order to find the IP address for that DNS name.
NX Domain re-direct
When a customer searches for a non-existent domain (NXDOMAIN response), you can redirect the user to another web page. This is done using the BIND 9 DLZ feature.
Maximum Cache Hit Rate
Prefetch popular records before they expire from the cache. This will improve the performance delivered to end users for resolving names that have short expiration times.
Flexible Cache Controls
From time to time you may get incorrect or outdated records in the resolver cache. BIND 9 gives you the ability to remove them selectively or as a group.
BIND 9 is unique in providing the ability to configure different views in a single BIND server. This allows you to give internal (on-network) and external (from the Internet) users different views of your DNS data, keeping some DNS information private.
Resolver Rate-limiting
BIND 9 offers two configuration parameters, fetches-per-zone and fetches-per-server. These features enable rate-limiting queries to authoritative systems that appear to be under attack. These features have been successful in mitigating the impact of a DDoS attack on resolvers in the path of the attack.
DNSSEC Validation
Protect your clients from imposter sites by validating DNSSEC. In BIND 9, this is enabled with a single command. BIND 9 also has a Negative Trust Anchor feature, which temporarily disables DNSSEC validation when there is a problem with the authoritative server’s DNSSEC support. BIND 9 offers support for RFC 5011 maintenance of root key trust anchors.
A Response Policy Zone or RPZ is a specially constructed zone that specifies a policy rule set. The primary application is for blocking access to domains that are believed to be published for abusive or illegal purposes. There are companies that specialize in identifying abusive sites on the Internet, which market these lists in the form of RPZ feeds. For more information on RPZ, including a list of DNS reputation feed providers, see https://dnsrpz.info.
DNS Privacy
BIND supports QNAME minimization by default. This feature minimizes leakage of excessive detail about the query to systems that need those details. BIND will be supporting two different encryption mechanisms, DNS over HTTPS (DoH) and DNS over TLS (DoT), in BIND 9.18. These implementations are available in the development branch today.
Download BIND
ISC builds and maintains packages for every major operating system or download sources and build it yourself.
ISC packages may be found at: CentOS Epl & Fedora, Ubuntu Launchpad, and Debian. We also have an official Docker image. Download sources here and follow these instructions to verify a download file. Note that BIND 9.18 and beyond will no longer support the native Windows(tm) operating system.
Isc bind что это
9.9.2-P1 (04 декабря 2012 [1] )
BIND 10 devel-20121115 (15 ноября 2012 [2] )
BIND (Berkeley Internet Name Domain, до этого: Berkeley Internet Name Daemon) — открытая и наиболее распространённая реализация DNS-сервера, обеспечивающая выполнение преобразования DNS-имени в IP-адрес и наоборот.
BIND поддерживается организацией Internet Systems Consortium. BIND был создан студентами и впервые был выпущен в BSD 4.3.
В Unix этот сервер является стандартом де-факто, но имеются и альтернативы:
См. также
Примечания
Ссылки и источники
Полезное
Смотреть что такое «BIND» в других словарях:
Bind — (Berkeley Internet Name Domain) Entwickler: ISC Aktuelle Version: 9.6.0 (7. Januar 2009) Betriebssystem: z. B. UNIX, NetBSD, FreeBSD, OpenBSD … Deutsch Wikipedia
BIND — Developer(s) Internet Systems Consortium Stable release 9.8.1 P1 / November 16, 2011; 4 days ago (2011 11 16) Preview release 10 devel 20111014 / October 14, 2011; 37 days ago … Wikipedia
BIND — Entwickler Internet Systems Consortium Aktuelle Version 9.8.1 (31. August 2011) Betriebssystem Unixartige, Windows NT, z/OS, OS/2 Kategorie … Deutsch Wikipedia
BIND — Saltar a navegación, búsqueda BIND Desarrollador Internet Systems Consortium https://www.isc.org/software/bind Información general … Wikipedia Español
Bind — Saltar a navegación, búsqueda BIND Desarrollador Internet Systems Consortium www.isc.org/sw/bind/ Información general … Wikipedia Español
Bind — Bind, v. t. [imp.
BIND — Développeur Internet Systems Consortium Dernière version … Wikipédia en Français
bind — / bīnd/ vt bound / bau̇nd/, bind·ing 1 a: to make responsible for an obligation (as under a contract) agents have the power to bind the insurer R. I. Mehr b: to burden with an obligation prevented married women from bind ing … Law dictionary
bind — [baɪnd] verb bound PTandPP [baʊnd] binding PRESPART [transitive] LAW if a legal agreement binds someone, it makes them promise to do something: • If a person signs a documen … Financial and business terms
Bind — Bind: BIND наиболее распространённый DNS сервер. bind (Unix) команда bash для назначения макроса комбинации клавиш. bind (системная функция) имя библиотечной функции API сетевого интерфейса sockets … Википедия
bind — [bīnd] vt. bound, binding [ME binden < OE bindan < IE base * bhendh > BAND1, BEND1, Sans badhnāti, (he) binds, Goth bindan] 1. to tie together; make fast or tight, as with a rope or band 2. to hold or restrain as if tied or tied … English World dictionary
BIND 9: опыт настройки и эксплуатации DNS-сервера
Содержание статьи
Сегодня невозможно представить себе интернет без DNS. Однако многие администраторы не уделяют время настройке этой службы на своих серверах, поэтому не используют всю ее мощь даже на треть.
Итак, планы на сегодня!
Xakep #211. Когда «Окна» смотрят в тебя
Интро
Когда я устроился на работу, количество сервисов в нашей сети можно было пересчитать по пальцам одной руки. Время шло, число сервисов росло. Обслуживающий DNS-сервер был один и выступал мастером для одной зоны (назовем ее xak.ru). Все остальные запросы он просто пересылал на DNS-сервер Google (8.8.8.8). А, чуть не забыл добавить: сервер этот был виртуальным. Потом в один прекрасный день сервер рухнул физически. После замены систему подняли, виртуализацию прикрутили. Поставили свежеустановленный Debian и к нему BIND 9. Присвоили тот же IP, что был у DNS-сервера до падения. Настройки восстановили из бэкапа. После успешного старта стали думать, как «закручивать болты».
Параллельно с этой работой был установлен хостинг, который держал на себе зону (например) xaker.ru. Само собой, центральный DNS должен о ней знать, а еще лучше быть slave DNS-сервером для этой зоны. Далее возникла необходимость перенаправлять DNS-запросы от центрального сервера к редиректору в зависимости от того, из какой сети пришел запрос. Делалось это ради подключения внешних DNS-фильтров, но не для всех. А только для тех, кому надо, а именно образовательных городских сетей — территории образовательных учреждений! Обо всем этом и пойдет речь ниже.
Немного теории
Основная цель DNS — это отображение доменных имен в IP-адреса и наоборот — IP в DNS. Решено было рассмотреть BIND (Berkeley Internet Name Domain, ранее Berkeley Internet Name Daemon), как самый распространенный софт для решения задачи DNS. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для части запросов TCP/53. Очень подробно о нем рассказано в статье на Хабре.
Если хочешь познакомиться с «новым» BIND, то рекомендую к чтению вот эту статью. В двух словах: версия 9 была последней, с 10-й версии права передают сообществу, и это ПО ныне известно как Bundy.
Быстрая установка, или еще раз об одном и том же
Итак, как установить BIND 9 в Debian/Ubuntu, в Сети очень и очень много материала. Так что быстро пройдемся по этому пункту, не вдаваясь в подробности. Для начала необходимо установить BIND 9 в систему. Для пользователей MS Windows есть версия BIND 9 под их платформу.
apt-cache search bind9
Для других дистрибутивов руководств по сборке из исходных кодов на просторах Сети предостаточно, забирай быстрее, переписывай в блокноты, пока новый «суперполезный» закон не накрыл весь интернет или пока тебя не отругали за то, что ты ходишь или ходил на сайт с запрещенной литературой. 😉
чем подключим новый файл в конфиг для правил подсетей. Далее создаем файл /etc/bind/named.conf.acl и добавляем правила:
Здесь мы разделили сети на группы для дальнейшей обработки. Прежде чем продолжим, уточню один момент. Для корректной обработки зон необходимо в каждую группу правил добавлять все зоны. Можно это делать в одном файле или вынести настройки зоны в отдельный файл и потом просто подключать в нужных местах. Итак, в файл /etc/bind/named.conf.local вносим изменения:
Здесь мы обозначаем группу, с которой будет работать BIND. Добавляем сюда клиенты из правил, которые мы определили выше. Назначаем вышестоящий сервер, на который будут пересылаться запросы, пришедшие из сетей, согласно описанным правилам. Здесь это единственная группа адресов School. В качестве вышестоящего DNS задал DNS-сервер Яндекс, который фильтрует «плохой» контент. Можно аналогично использовать другие DNS-сервисы, такие как SkyDNS.
Далее в этот же файл ниже добавляем вторую или остальные группы клиентов. Зона zone2.ru подключена как slave-зона, указан DNS-мастер-сервер и файл — путь к базе.
Здесь мы снова перечисляем, какие группы входят в эту секцию правил или, говоря иначе, каким сетям отвечать. Настройки зон могут быть различными. Если необходимо обеспечить доступ в зону xaker.ru, то эту секцию нужно описывать в обеих секциях. Зона server.local описана только во второй части. Это говорит о том, что доступ к ней есть только у группы адресов, описанных в этой секции конфига. Это полезно использовать для обеспечения доступа, например, к зоне серверов или закрытых внутренних сервисов, порталов и прочего только необходимых клиентов. Как видно из конфига, вышестоящий DNS-сервер здесь другой. Таким образом, можно подключать внешние DNS-фильтры для избранных.
В общем файле настроек /etc/bind/named.conf.options описываем только недостающие параметры.
Эти правила можно отключить и прописать для каждой группы. Учти, что в таком случае параметры нужно прописывать в каждой секции, у нас их две. Файлы зон описываются при этом стандартно.
Здесь все стандартно. Описываем зону. Если нужно, MX-записями задаем узлы для работы с почтой. Последней строчкой мы описываем XMPP-сервер для передачи файлов с поддержкой Jabber-прокси. Без этого файлы между сетями, находящимися за шлюзом, передавались нестабильно.
А в файле /etc/bind/named.conf.local после описания параметров и перед подключением настроек зон подключить файл с настройками:
А уже потом описывать зоны, которые будут обрабатываться только для этих клиентов, описанных в данной секции конфига.
Как видно, совсем не сложно разбить клиенты DNS на группы сетей или отдельные узлы и обрабатывать их запросы или перенаправлять вышестоящему DNS-серверу в зависимости от адреса, с которого пришел запрос. Чтобы наши клиенты НЕ СМОГЛИ использовать внешние DNS-серверы на выходном шлюзе, добавляем правило «Разрешить DNS-запросы в интернет от ваших DNS-серверов и запретить для всех остальных». Делается это из-за того, что есть знающие пользователи, которые меняют настройки на своих устройствах. Или просто заворачиваем все запросы на наш DNS. Следует отметить, что если используется прокси, то для его клиентов запросы будет обрабатывать прокси-сервер, это нужно учитывать.
Служба DNS не менее важна, чем DHCP и другие. При правильном подходе она помогает решить довольно большой круг задач. Игнорируя этот сервис, перекладывая все заботы на публичные DNS-серверы, администраторы лишают себя очень гибкого инструмента для работы с сетью. Так, например, можно снизить нагрузку на канал, если описать зоны с сервисами, находящимися в локальной сети и имеющими доступ из сети Интернет, чтобы внутренние клиенты ходили только по локальной сети, а клиенты внешние — через внешний канал соответственно. Когда число клиентов переваливает за сотню, это особенно ощутимо.
P. S. Всем удачи! Легкой настройки, бесперебойной работы и свободного канала связи 🙂
Александр «Plus» Рак
Участник сообщества OmskLUG. Инженер отдела электронного взаимодействия МКУ «Информационно-технического управления».
