Настройка зоны днс – Настройка DNS сервера Bind9 (Создание локальной доменной зоны)’, body = ‘Сегодня поговорим о создании локальной доменной зоны внутри локальной сети. Для чего нужна локальная доменная зона и DNS-сервер? Чтобы расшарить (сделать доступными) свои локальные с

alexxlab

Содержание

Настройка DNS сервера с FQDN-доменом и внешним статическим ip адресом |

Последнее изменение: 12.08.2019

Сегодня настроим DNS сервер с FQDN-доменым именем и внешним статическим ip адресом. В качестве DNS сервера будет выступать bind9 и операционная система Ubuntu Server 16.04. Так же разберем настройку двух зон: зона прямого и зона обратного просмотра.

DNS – это система доменных имен для преобразования имени в ip адреса компьютера и наоборот. Зная имя компьютера, вам не нужно запоминать его ip адрес. Простыми словами набирая адрес интернет странички в Вашем браузере DNS сервер всемирной паутины преобразует его в ip-адрес хостинга на котором расположен данный домен.

И так у нас уже есть установленная ОС Ubuntu Server 16.04 LTS и настроенный DHCP сервер isc-dhcp-server. Что от нас требуется, так это установить и настроить DNS сервер bind9

Установка DNS сервера bind9 на Ubuntu | Debian | Linux Mint

Для установки DNS сервера нам необходимо подключиться к серверу при помощи ssh.

Как настроить доступ по ssh описано тут.

После того как подключились в первую очередь необходимо обновить систему. Вводим следующие команды.

sudo apt update
sudo apt dist-upgrade -y

Далее устанавливаем сам DNS сервер

sudo apt install bind9

Настройка зон для DNS

Исходные данные:

  • Доменное имя FQDN – obu4alka.ru
  • IP адрес сервера – 80.81.82.83/32
  • Имя сервера – ns1.obu4alka.ru

Настройка зоны прямого просмотра DNS

Создадим файл в котором будет храниться данные о зоне прямого просмотра. Для этого сделаем копию образца файла прямого просмотра

sudo cp /etc/bind/db.local /var/lib/bind/db.obu4alka.ru

И открываем его на редактирование

sudo nano /var/lib/bind/db.obu4alka.ru

Содержимое файла

$TTL 14400  
@  IN  SOA  ns1.reg.ru.  root.obu4alka.ru. (
2018052655 ; serial 
604800     ; refresh
86400      ; retry
2419200    ; expire
604800     ; minimum
)
@    IN  NS ns1.reg.ru.
 @    IN  NS ns2.reg.ru.
@    IN  A  80.81.82.83
ns1  IN  A  80.81.82.83
www  IN  A  80.81.82.83
  • Записи вида А — предназначена для ip адресов версии 4
  • Запись вида АААА — предназначена для ip адресов версии 6
  • Запись вида NS — для DNS серверов регистратора (обычно).

Настройка зоны обратного просмотра DNS

Обратная зона преобразовывает IP адреса машины в доменное имя FQDN. Обратная зона нужна если у вас на сервере будет запущен ещё и почтовый сервер. Все известные почтовики проверяют сервер по обратной зоне. Если у Вас проблема с отправкой почты, например на mail.ru письма не приходят, а служба безопасности присылает отчёт, что данный почтовый сервер находится в списке недоверенных серверов, то скорее всего для вашего домена нет файла обратной зоны. Выход из сложившейся ситуации, попросить вашего провайдера создать файл зоны обратного просмотра. Ну а мы с вами создадим зону для нашего сервера.

Давайте сделаем копию файла прямого просмотра:

sudo cp /var/lib/bind/db.obu4alka.ru /var/lib/bind/db.revers.obu4alka.ru

Открываем его на редактирование:

sudo nano /var/lib/bind/db.revers.obu4alka.ru
$TTL 14400
@ IN SOA ns1.reg.ru. root.obu4alka.ru. (
2018052655 ; serial
604800 ; refresh
86400 ; retry
2419200 ; expire
604800 ; minimum
)
@ IN NS ns1.reg.ru.
@ IN NS ns2.reg.ru.
83 IN PTR ns1.obu4alka.ru.

Настройка конфигурационных файлов Bind9

Для начала отредактируем файл named.conf.options

 sudo nano /etc/bind/named.conf.options

Добавим в него следующий код:

options {
directory "/var/cache/bind";
# с каких сетей или  IP адресов будут обслуживаться запросы нашим DNS сервером.
listen-on { 
80.81.82.83/32; 
127.0.0.1; 
};
# вышестоящий dns сервер, используется если URL запроса не найден в нашей базе.
forwarders { 
77.88.8.1; 
8.8.8.8; 
};
# Кому разрешено запрашивать dns сервер
 allow-query { any; };
allow-query-cache { any; };
# Кому разрешено посылать рекурсивные запросы
allow-recursion { any;};
# Запросы DNSSEC
dnssec-validation auto;
# Запросы NXDOMAIN
auth-nxdomain no;
# с каких сетей или  IPv6 адресов будут обслуживаться запросы нашим DNS сервером
listen-on-v6 { all; };
# Прописываем версию DNS - для защиты от любопытных
version "DNS server v1.0";
};

Теперь открываем файл конфигурации зон и вносим информацию о наших зонах.

sudo nano /etc/bind/named.conf.local
 // зона прямого просмотра\
zone "obu4alka.ru" {
type master; 
file "/var/lib/bind/db.obu4alka.ru";
};
// зона обратного просмотра
zone "83.82.81.80.in-addr.arpa" {  
type master; 
file "/var/lib/bind/db.revers.obu4alka.ru";
};

Сохраняем, закрываем. Теперь проверим правильность синтаксиса конфигурационных файлов BIND.

sudo named-checkconf

Если конфигурационные файлы не содержат ошибок, вывод этой программы будет пуст.

Перезагружаем bind9

sudo /etc/init.d/bind9 restart

Проверяем работу DNS сервера

nslookup ns1.obu4alka.ru

в ответ вы должны увидеть:

Server:     127.0.0.1
Address:    127.0.0.1#53
Non-authoritative answer:
Name:    ns1.obu4alka.ru
Address: 80.81.82.83

Как видите зона прямого просмотра работает, нам показался ip адрес проверяемого имени. Теперь проверим работу зоны обратного просмотра

nslookup 80.81.82.83

В ответ должны получить:

Server:        127.0.0.1
Address:    127.0.0.1#53
Non-authoritative answer:
80.81.82.83.in-addr.arpa    name = ns1.obu4alka.ru.
Authoritative answers can be found from:

Как видим в ответе мы получили имя сервера по его адресу. Если у вас в ответ на nslookup так же все корректно отображается, значит вы все сделали правильно! Если нет, то проверяйте что сделали не так.

P.S. Также добавьте в файле resolv.conf свой nameserver

sudo nano /etc/resolv.conf
nameserver 80.81.82.83
nameserver 127.0.0.1
search obu4alka.ru

Для того чтобы ваш DNS сервер был виден из интернета, а также чтобы он обрабатывал все запросы по FQDN-имени (obu4alka.ru), у регистратора Вашего домена необходимо поменять NS сервера на IP вашего сервера DNS

Проверяем версию DNS сервера

dig @ns1.obu4alka.ru version.bind chaos txt

Примерный вывод команды:

; (1 s; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> @ns1.pro-gram.ru version.bind chaos txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36382
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
 
 
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;version.bind.            CH  TXT
;; ANSWER SECTION:
version.bind.        0   CH  TXT "DNS server v1.0"
;; AUTHORITY SECTION:
version.bind.        0   CH  NS  version.bind.
;; Query time: 0 msec
;; SERVER: 80.81.82.83#53(80.81.82.83)
;; WHEN: Sun Apr 11 09:16:23 +04 2019
;; MSG SIZE  rcvd: 84
Если есть вопросы, то пишем в комментариях.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

obu4alka.ru

Установка и настройка DNS-сервера BIND в Linux

BIND – наиболее распространенное open-source приложение, в котором реализованы протоколы DNS, предоставляющие возможность преобразования доменных имен в IP-адреса и наоборот.

Данная статья представляет собой руководство по быстрой настройке DNS-сервера в Linux при помощи

BIND. Мы не будем подробно разбирать, что такое система DNS и как она работает, а сосредоточимся на примере настройки своей зоны и файла конфигурации для домена/узла с поддержкой сервисов www и электронной почты.

В нашем примере мы будем использовать следующие параметры:
IP-адрес, на котором будет установлен сервер имен: 172.31.0.122
имя домена/узла: itproffi.ru
авторитативные сервера имен для зоны itproffi.ru: ns1.itproffi.ru (172.31.1.10) и ns2. itproffi.ru (172.31.1.11)
службы www и электронной почты для itproffi.ru будут использовать адрес 172.31.1.10

Установка сервера bind

Установка bind очень проста – нужно воспользоваться менеджером пакетов. В Debian и Ubuntu выполните следующую команду:

apt-get install bind9 dnsutils

В CentOS или Fedora:

yum install bind dnsutils

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

dig из этого пакета.

Создание файла зоны DNS

Дальнейшие примеры будут для Ubuntu/Debian, но также подходят и для Centos/RedHat, только директория с настройками зон в CentOS будет находиться в /etc/named/ , а основной файл конфигурации /etc/named.conf. Для начала нам потребуется создать новый файл зоны для домена itproffi.ru. Перейдите в директорию /etc/bind/. создайте в ней поддиректорию zones/master/ и перейдите в нее, выполнив следующую последовательность команд:

cd /etc/bind
mkdir -p zones/master
cd zones/master/

Директория /etc/bind/zones/master будет содержать файл зоны для домена itproffi.ru. При желании можно использовать другую директорию. Файл зоны db.itproffi.ru будет содержать запись DNS, которая поможет серверу имен установить соответствие полного доменного имени IP-адресу. Создайте этот файл со следующим содержимым:

;
; Файл данных BIND для itproffi.ru
;
$TTL 3h
@ IN SOA ns1.itproffi.ru. admin.itproffi.ru. (
1 ; серийный номер
3h ; обновление каждые 3 часа
1h ; повторная попытка через час
1w ; срок годности – 1 неделя
1h ) ; хранение кэша отказов 1 час;
@ IN NS ns1.itproffi.ru.
@ IN NS ns2.itproffi.ru.

itproffi.ru. IN MX 10 mail.itproffi.ru.
itproffi.ru. IN A 172.31.1.10
ns1 IN A 172.31.1.10
ns2 IN A 172.31.1.11
www IN CNAME itproffi.ru.
mail IN A 172.31.1.10
ftp IN CNAME itproffi.ru.

Рассмотрим ключевые строки этого файла:

  • Запись SOA: авторитативный сервер имен для itproffi.ru – это ns1.itproffi.ru, адрес ответственного за зону DNS администратора – [email protected]
  • Записи NS: два сервера имен для зоны itproffi.ru – ns[1,2].itproffi.ru
  • Запись MX: почтовый сервер для itproffi.ru. Число 10 означает уровень приоритета
  • Записи A: A означает «адрес» (address). Другими словами, ns1 в зоне itproffi.ru будет иметь адрес 172.31.1.10
  • Запись CNAME (Canonical Name – каноническое имя): привязывает одно доменное имя к другому (каноническому), например, устанавливает соответствие mail.itproffi.ru и itproffi.ru.

Настройка обратной зоны

На данном этапе DNS-сервер bind может выдать IP-адрес, связанный с узлом itproffi.ru. Теперь нам нужно научить наш сервер имен обратному процессу, то есть устанавливать соответствие имени IP-адресу. Для этого создадим еще один файл db.172.31.1 со следующим содержимым:

;
; Обратный файл данных BIND для 1.31.172.in-addr.arpa
;
$TTL 604800
1.31.172.in-addr.arpa. IN SOA ns1.itproffi.ru. admin.itproffi.ru. (
1 ; серийный номер
3h ; обновление каждые 3 часа
1h ; повторная попытка через час
1w ; срок годности – 1 неделя
1h ) ; хранение кэша отказов 1 час;
1.31.172.in-addr.arpa. IN NS ns1.itproffi.ru.
1.31.172.in-addr.arpa. IN NS ns2.itproffi.ru.
10.1.31.172.in-addr.arpa. IN PTR itproffi.ru.

Запись PTR: DNS-запись, используемая для определения соответствия IP-адреса имени узла.

Настройка файла конфигурации bind

На данный момент у нас должно быть два файла:

/etc/bind/zones/master/db.itproffi.ru
/etc/bind/zones/master/db.172.31.1

Теперь требуется вставить имена обоих файлов зоны в файл конфигурации bind /etc/bind/named.conf.local. Для этого добавьте в файл следующие строки:

zone "itproffi.ru" {
type master;
file "/etc/bind/zones/master/db.itproffi.ru";
};

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

Последний момент перед проверкой конфигурации – внести в файл named.conf.options IP-адрес стабильного DNS-сервера. Он будет использоваться, если локальный DNS-сервер не будет знать ответ на запрос разрешения имени. Часто этот адрес предоставляется интернет-провайдером, но если вы поклонник Google, можно указать адрес 8.8.8.8 или 8.8.4.4.

Замените следующий блок текста в файле named.conf.options:

// forwarders {
// 0.0.0.0;
// };

на блок текста с адресом стабильного DNS-сервера

forwarders {
8.8.4.4;
};

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

listen-on port 53 { any; };
allow-query { any; };

А лучше, для безопасности вместо any пропишите ваши сети с которых разрешено подключение

listen-on port 53 { 192.168.0.0/24; };
allow-query { 192.168.0.0/24; };

Если этого не сделать, то при попытке обращения к серверу с другого компьютера вы получите ошибку

Query refused

Проверка файлов зоны и конфигурации

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

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

named-checkconf

С этой командой работает простое правило: отсутствие результата – это хороший результат. Если команда ничего не возвращает, значит ошибок в ваших файлах конфигурации не обнаружено.

Для проверки файлов зоны DNS можно воспользоваться командой named-checkzone:

named-checkzone itproffi.ru /etc/bind/zones/master/db.itproffi.ru
zone itproffi.ru/IN: loaded serial 1
OK

Проверка обратной зоны

named-checkzone 1.31.172.in-addr.arpa /etc/bind/zones/master/db.172.31.1
zone 1.31.172.in-addr.arpa/IN: loaded serial 1
OK

Запуск и перезапуск сервера bind

Теперь мы можем запускать сервер bind:

/etc/init.d/bind9 start

Если сервер уже был запущен, его можно перезапустить командой restart:

/etc/init.d/bind9 restart

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

 rndc reload

Тестирование сервера bind

Для тестирования новой конфигурации сервера имен bind нам пригодится команда dig из пакета dnsutils. Эту команду можно запустить на любом компьютере с сетевым доступом к вашему DNS-серверу, но лучше всего начать тестирование с локального узла. В рассматриваемом нами примере IP-адрес сервера имен 172.31.0.122. Сначала проверим прямое разрешение имени (получение IP-адреса по доменному имени):

dig @172.31.0.122 www.itproffi.ru

Теперь проверим обратную зону:

dig @172.31.0.122 -x 172.31.1.10

Если вы получили аналогичные результаты, то зона DNS настроена правильно. Вместо команды dig для тестирования можно также использовать команду nslookup.

nslookup itproffi.ru 172.31.0.122

nslookup 172.31.1.10 172.31.0.122

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

itproffi.ru

Настройка репликации и передачи зон DNS


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

При развёртывании нескольких DNS-серверов в организации согласованность данных на таких серверах становится важным аспектом конфигурирования и управления DNS в сети. Чтобы DNS-серверы в организации обеспечивали синхронизированную текущую информацию для клиентов, нужно отконфигурировать репликацию и передачу зон.

Репликация зон — это процесс синхронизации данных зон, интегрированных в Active Directory. Передача зон — это синхронизация данных зон между  главной и дополнительной стандартной зоной. Эти два механизма основаны на  разных технологиях, поэтому настраиваются отдельно.

Настройка репликации зон, интегрированных в Active Directory

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

Репликация и раздел каталога приложений

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

Раздел — это структура данных в Active Directory, которая определяет  данные для репликации. По умолчанию контроллеры домена включают два  раздела каталога приложений, зарезервированные для данных DNS: DomainDnsZones и ForestDnsZones. Репликация раздела DomainDnsZones выполняется на всех контроллерах домена, также являющихся DNS-серверами в отдельном домене, а репликация раздела ForestDnsZones выполняется на всех контроллерах  домена, также служащих DNS-серверами в каждом домене леса Active Directory.

Каждый из этих разделов каталога приложений получает имя в соответствии с именем FQDN дочернего домена DNS. Эти разделы можно просмотреть в диспетчере DNS. Кроме того, каждая зона содержит имя DomainDnsZones, указывающее раздел, репликация которого выполняется лишь в локальных доменах.

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

Хранение данных DNS в разделе домена Данные зоны, интегрированной в Active Directory, хранятся в разделе домена вместе с остальными данными домена. В этой конфигурации репликация данных DNS выполняется не только на контроллерах домена, которые также являются DNS-серверами, но и па всех контроллерах локального домена. Однако при использовании этой опции  генерируется дополнительный трафик репликации. Ее следует применять для  репликации данных DNS на компьютерах Windows Server 2000.

Выбор области репликации зон

Раздел, в котором хранится зона, эффективно определяет область репликации для этой зоны, интегрированной в Active Directory. При использовании программы Dcpromo для назначения сервера контроллером нового домена в  разделе DomainDnsZones автоматически создается новая зона, интегрированная в Active Direcrory. Однако при создании новой зоны с помощью мастера создания новой зоны на странице Область репликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope), можно выбрать раздел для сохранения зоны.

На странице Область репликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope), представлены четыре опции.

■ Для всех DNS-серверов в этом лесу (То All DNS Servers In This Forest)

Новая зона сохраняется в разделе ForestDnsZones. Каждый контроллер  домена во всем лесу, где установлен DNS-сервер, получит копию этой зоны.

■ Для всех DNS серверов в этом домене (То All DNS Servers In This Domain)

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

■ Для всех контроллеров домена в этом домене (То All Domain Controllers In This Domain)

Зона сохраняется в разделе домена. Каждый контроллер локального домена получит копию этой зоны независимо от наличия па нем установленного DNS-сервера.

■ На все контроллеры домена, указанные в области данного раздела каталога (То All Domain Controllers Specified In The Scope Of This Directory Partition)

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

Область репликации созданной зоны можно изменить в любое время. Для этого на вкладке Общие (General) щелкните кнопку Изменить (Change) напротив параметра репликации.

Откроется диалоговое окно Изменение области видимости зоны репликации (Change Zone Replication Scope), в котором представлены те же опции выбора области репликации, что и на странице мастера создания новой зоны.

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

ПРИМЕЧАНИЕ: Повторное создание зон DomalnDnsZones и ForestDnsZones

Удаленные или поврежденные разделы каталога приложений можно воссоздать в диспетчере DNS, щелкнув правой кнопкой мыши узел сервера и применив команду Создать используемые по умолчанию разделы каталога приложений (Create Default Application Directory Partitions).

Создание настраиваемого раздела каталога приложения

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

dnscmd имя_сервера /createdirectorypartition hmp_FQDN

Затем перечислите в разделе другие DNS-серверы с помощью следующей команды:

dnscmd имя_сервера /enlistdirectorypartition имя_FQDN

Так, чтобы создать раздел каталога приложений DNSpartitionA на компьютере Server1 в домене Active Directory с именем microsoft.com, введите такую команду:

dnscmd server1 /createdirectorypartition DNSpartitionA.microsoft.com

ПРИМЕЧАНИЕ: Использование точки (.) для указания имени локального сервера

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

Чтобы перечислить в разделе каталога приложений компьютер Server2, введите такую команду:

dnscmd server2 /enlistdirectorypartition DNSpartitionA.microsoft.com

ПРИМЕЧАНИЕ: Кто может создавать раздел каталога приложений

Раздел каталога приложений может создать лишь член группы Администраторы предприятия (Enterprise Admins).

Созданный раздел каталога приложений появится в раскрывающемся  списке на странице Область репликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope) мастера создания новой зоны и в  диалоговом окне Изменение области видимости зоны репликации (Change Zone Replication Scope). Чтобы сохранить зону в новом разделе, выберите опцию На все контроллеры домена, указанные в области данного раздела каталога (То Аll Domain Controllers Specified In The Scope Of This Directory Partition), и в  раскрывающемся списке укажите этот раздел.

Передача зон

Если все DNS-серверы расположены на контроллерах доменов, для обеспечения согласованности данных зон среди всех DNS-серверов используется репликация Active Directory. Однако эта возможность недоступна при установке DNS-сервера на компьютере, не являющемся контроллером домена. В таком случае зону нельзя сохранять в Active Directory, вместо этого нужно использовать  стандартную зону, которая сохраняет данные в локальном текстовом файле на каждом DNS-сервере. Если в организации используется много DNS-серверов, то  исходные данные можно копировать в управляемые другими серверами  дополнительные зоны с правом только для чтения. Для того чтобы обеспечить  согласованность и обновление данных между основной и дополнительными зонами, нужно настроить передачу зон.

Передача зон, по сути, представляет собой извлечение данных, инициируемое в дополнительных зонах, копирование данных главной зоны, которая сама по себе может быть основной или еще одной дополнительной зоной. Главной зоне необязательно даже быть стандартной по отношению к дополнительной зоне — вы можете отконфигурировать дополнительную зону для основной зоны,  интегрированной в Active Directory. К примеру, у вас есть два сайта — один в Нью-Йорке, другой в Лос-Анджелесе, причем каждый сайт принадлежит  отдельному домену Active Directory. В каждом домене можно обеспечить разрешение имен для противоположного домена, не устанавливая новый контроллер домена и не управляя трафиком репликации между двумя сайтами.

Включение передачи зон

Передача данных для дополнительных зон может быть инициирована в любом из трех случаев.

■ По истечении интервала обновления начальной записи SOA основной зоны.

■ При загрузке дополнительной зоны сервером.

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

По умолчанию передача для всех зон отключена. Ее нужно включить на вкладке Передача зон (Zone Transfers) окна свойств зоны. Установив флажок разрешения передачи зон, можно выбрать одни из трех параметров передачи.

■ На любой сервер (To Any Server) Этот параметр обеспечивает минимальную безопасность. Поскольку передача зоны представляет собой копирование данных зоны, этот параметр позволяет кому угодно с сетевым доступом к DNS-серверу просмотреть содержимое зоны, включая имена всех серверов и компьютеров с их IP-адресами. Поэтому данный параметр следует  использовать только в частных сетях с высоким уровнем безопасности.

■ Только на серверы, перечисленные на странице серверов зон (Only To Servers Listed On The Name Servers Tab) Этот параметр позволяет выполнять передачу зон с записью NS только на те дополнительные DNS-серверы, которые полномочны для данных зон.

■ Только на серверы из этого списка (Only To The Following Servers) Этот параметр позволяет указать список дополнительных серверов, на которые будет выполняться передача зон. Для этих дополнительных серверов не требуется идентификация с помощью записи NS в зоне.

Настройка уведомлений

На вкладке Передача зон (Zone Transfers) можно также настроить уведомление, которое будет отправлено дополнительным серверам в случае изменений в основной зоне. Поскольку передача зон представляет собой операции PULL, их нельзя конфигурировать для переноса новых данных на дополнительные  серверы. Вместо этого при модификации данных основная зона отправляет  уведомление на все указанные серверы, управляющие дополнительными зонами. Дополнительная зона, получившая уведомление, инициирует передачу зоны.

Для настройки уведомлений на вкладке Передача зон (Zone Transfers) щелкните кнопку Уведомить (Notify). Откроется диалоговое окно Уведомление  (Notify), где можно указать дополнительные серверы, которые будут оповещаться при обновлении зоны на локальном главном сервере.

По умолчанию при включении передачи зон все серверы, перечисленные на вкладке Серверы имен (Name Servers), автоматически уведомляются об  обновлениях зоны.

Обновление дополнительной зоны вручную

Если щелкнуть дополнительную зону правой кнопкой мыши, откроется  контекстное меню, в котором можно использовать следующие операции для  обновления зоны.

■ Перезагрузка (Reload)

Перезагружается дополнительная зона из локального хранилища.

■ Передать зону с основного сервера (Transfer From Master)

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

■ Перезагрузить повторно зону с основного сервера (Reload From Master)

Выполняется передача зоны с главного сервера дополнительной зоны независимо от серийного номера в записи SOA дополнительной зоны.

Использование зон-заглушек

Зона-заглушка — это копия, которая содержит лишь основные записи главной зоны. Назначают зону-заглушку, чтобы локальный DNS-сервер мог пересылать запросы на уполномоченные серверы имен в главной зоне. Таким образом, зона-заглушка функционально идентична делегированию зон. Тем не менее,  поскольку зоны-заглушки могут инициировать и принимать передачу зон из главной (делегированной) зоны, они обеспечивают дополнительное информирование родительских зон об обновлениях в записях NS дочерних зон.

Зоны-заглушки можно использовать в следующих целях:

■ Обновление данных делегированной зоны

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

■ Разрешение имен

Зоны-заглушки позволяют DNS-серверу выполнять рекурсию, используя список серверов имен в зоне-заглушке и не запрашивая при этом Интернет или сервер в локальном пространстве имен DNS. В такой ситуации все зоны-заглушки развертываются не между родительской и  дочерней зонами, а в доменах большого леса Active Directory или пространстве имен DNS.

ПРИМЕЧАНИЕ: Делегированная зона

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

Пример зоны-заглушки

Предположим, вы работаете администратором DNS-сервера Dns1.microsoft.com, который уполномочен для зоны Microsoft.com. Ваша компания имеет дочерний домен Active Directory с именем India.microsoft.com, для которого выполняется делегирование. При начальном делегировании дочерняя зона, интегрированная и Active Directory, содержит только два полномочных DNS-сервера — 192.168.2.1 и 192.168.2.2. Позже администраторы домена India.microsoft.com развертывают дополнительные контроллеры домена и устанавливают роль DNS-сервер (DNS Server) на новых контроллерах. Однако администраторы не уведомили вас о том, что добавили полномочные DNS-серверы на свой домен. В результате на сервере Dns1.microsoft.com оказались не отконфигурированными записи новых DNS-серверов, уполномоченных для домена lndia.microsoft.com, и запросы  продолжают пересылаться лишь на два DNS-сервера, заданный в начальном  делегировании.

Эту проблему можно устранить, создав зону-заглушку на сервере Dns1. microsoft.com для домена India.microsoft.com. С помощью новой зоны-заглушки компьютер Dns1 посредством передачи зон изучает новые серверы имен,  уполномоченные для родительской зоны India.microsoft.com. Таким образом, сервер Dns1 сможет направлять запросы пространства имен Inclia.microsoft.com на все полномочные DNS-серверы дочерней зоны.

Другие примеры использования зон-заглушек

Зоны-заглушки могут использоваться для разрешения имен между доменами, предотвращая поиск родительского сервера в пространстве имен DNS. Зоны-заглушки, таким образом, заменяют дополнительные зоны в ситуациях, когда требуется обмен данными DNS между доменами без избыточности данных для главной зоны. Кроме того, зоны-заглушки оптимизируют процесс разрешения имен и снижают нагрузку сетевых ресурсов при передаче данных зон.

win-serv.blogspot.com

Настройка параметров зоны DNS для доменов :: ripnet.ru

Просмотр записей ресурсов

Чтобы просмотреть записи ресурсов в зоне DNS домена:

  1. Находясь на домашней странице, щелкните по нужному доменному имени.
  2. Нажмите DNS в группе Службы. На экране отобразятся все записи ресурсов для данного домена.

 

 

Добавление записей ресурсов

Чтобы добавить новую запись ресурса в зону:

  1. Находясь на домашней странице, щелкните по нужному доменному имени.
  2. Нажмите DNS в группе Службы.
  3. Щелкните по значку Добавить новую запись в группе Инструменты.
  4. Выберите тип записи ресурса и введите соответствующие данные:
    • Для записи типа A вам потребуется ввести доменное имя, для которого необходимо создать запись A. Если вам просто нужно определить запись A для основного домена, не заполняйте поле. Если вы определяете запись A для сервера имен, тогда следует ввести соответствующее значение для данного сервера имен (например, ns1). Затем вам необходимо указать соответствующий IP-адрес, который следует назначить для доменного имени.
    • Для записи типа NS вам потребуется ввести доменное имя, для которого необходимо создать запись NS. Если вам просто нужно определить запись NS для основного домена, не заполняйте поле. Затем введите имя сервера имен в соответствующем поле. Необходимо ввести имя полностью (например, ns1.mynameserver.com).
    • Для записи типа MX вам потребуется ввести доменное имя, для которого необходимо создать запись MS. Для основного домена поле можно не заполнять. Затем вам необходимо будет указать имя почтового сервера. Если вы пользуетесь удаленным почтовым сервером с именем ‘mail.myhostname.com’, то в поле следует указать ‘mail.myhostname.com’. После этого установите приоритет для почтового сервера. Выберите приоритет из выпадающего списка. 0 – это самый высокий приоритет, 50 – самый низкий. Помните, что вам также необходимо добавить соответствующую запись типа A и/или CNAME, если это требуется для удаленного почтового сервера.
    • Для записи типа CNAME вам сначала потребуется ввести альтернативное имя домена, для которого необходимо создать запись CNAME. Затем укажите имя домена, для которого будет создано альтернативное имя. Можно указать любое доменное имя. Не требуется, чтобы домен располагался на том же сервере.
    • Для записи типа PTR сначала необходимо указать IP-адрес / маску, для которой необходимо определить указатель. Затем введите имя домена, соответствующего этому IP-адресу.
    • Для записи типа TXT введите произвольную текстовую строку, которая может являться описанием или записью типа SPF.
  5. Нажмите OK, чтобы сохранить настройки.

 

 

Изменение записей ресурсов

Чтобы изменить свойства записи ресурса:

  1. Находясь на домашней странице, щелкните по нужному доменному имени.
  2. Нажмите DNS в группе Службы.
  3. Щелкните по ссылке в столбце Хост, соответствующей записи ресурса, которую требуется изменить.
  4. Внесите нужные изменения и нажмите OK.

 

Чтобы изменить параметры записи SOA (Start of Authority) для домена:

  1. Находясь на домашней странице, щелкните по нужному доменному имени.
  2. Щелкните по значку DNS.
  3. Нажмите Настройки SOA.
  4. Введите нужные значения:
    • TTL. Этот параметр определяет период времени, в течение которого другие DNS-сервера должны хранить запись в кэше. По умолчанию в Plesk это значение установлено равным одному дню.
    • Обновление. Этот параметр показывает, как часто вторичный сервер имен посылает запрос первичному серверу имен, чтобы получить информацию о возможных изменениях, которые были внесены в файл доменной зоны. По умолчанию в Plesk это значение установлено равным трем часам.
    • Повтор. Этот параметр определяет промежуток времени ожидания вторичного сервера перед повторной попыткой получить файл зоны в случае ошибки. Обычно это значение меньше интервала обновления. По умолчанию в Plesk это значение установлено равным одному часу.
    • Истечение. Определяет интервал времени, по истечении которого вторичный сервер прекращает отвечать на запросы, после того, как прошел интервал времени обновления, во время которого не удалось обновить файл зоны. По умолчанию в Plesk это значение установлено равным одной неделе.
    • Минимум. Это период времени, в течение которого вторичный сервер должен хранить в кэше отрицательный ответ. По умолчанию в Plesk это значение установлено равным трем часам.
  5. Нажмите OK.

 

Использование формата порядковых номеров, который рекомендуют IETF и RIPE, является обязательным для многих доменов, зарегистрированных в некоторых DNS-зонах верхнего уровня, преимущественно европейских. Если ваш домен зарегистрирован в одной из таких зон, и ваш регистратор отвергает ваш порядковый номер SOA, то использование формата порядковых номеров, рекомендуемого IETF и RIPE, должно помочь устранить эту проблему.

На серверах Plesk для настройки зон DNS применяется синтаксис временных меток UNIX. Временная метка UNIX — это число секунд с 1 января 1970 (эпоха Unix). Переполнение 32-разрядных временных меток наступит к 8 июля 2038.

RIPE рекомендует использовать формат YYYYMMDDNN, где YYYY — это год (четыре знака), MM — месяц (два знака), DD — день месяца (два знака) и NN — это версия за день (два знака). Переполнение формата YYYYMMDDNN не наступит до 4294 года.

Чтобы изменить формат порядкового номера Start of Authority (SOA) для домена на формат YYYYMMDDNN:

  1. Находясь на домашней странице, щелкните по нужному доменному имени.
  2. Щелкните по значку DNS.
  3. Нажмите Настройки SOA.
  4. Поставьте флажок в поле Использовать формат порядковых номеров, рекомендуемый IETF и RIPE.

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

  5. Нажмите OK.

ripnet.ru

Настройка услуги «DNS-хостинг» — RU-CENTER

Услуга «DNS-хостинг» — это современные DNS-серверы, а также редактор, позволяющий легко управлять содержанием файлов зон и настройками DNS-серверов. Услуга предоставляется для прямых или обратных доменов в любых зонах верхнего уровня, в том числе IDN-доменов. DNS-серверы расположены в городах по всему миру для обеспечения отказоустойчивости и наименьшего времени ответа. Заказать услугу «DNS-хостинг».

Перед началом работы с услугой «DNS-хостинг» необходимо делегировать домен, то есть указать в его настройках DNS-серверы RU-CENTER. При одновременном заказе в RU-CENTER домена и услуги DNS-хостинг делегирование домена производится автоматически. Если вы заказали DNS-хостинг после регистрации домена в RU-CENTER, то укажите список DNS-серверов в настройках домена.
Если домен находится на поддержке у стороннего Регистратора, указать DNS-серверы нужно на стороне этого Регистратора.

После делегирования домена настроить услугу «DNS-хостинг» вы можете по инструкции.

Список DNS-серверов услуги «DNS-хостинг»

ns8-l2.nic.ru      

91.217.21.1
ns4-l2.nic.ru      

91.217.20.1
ns3-l2.nic.ru

193.232.146.1
ns4-cloud.nic.ru

185.119.138.10
2a01:5b0:9::a
ns8-cloud.nic.ru

185.119.136.12
2a01:5b0:8::c
ns8-l3.nic.ru

91.217.21.5
ns4-l3.nic.ru

91.217.20.5
ns3-l3.nic.ru

193.232.146.5
ns34-cloud.nic.ru

185.119.136.11
2a01:5b0:8::b
ns38-cloud.nic.ru

185.119.138.11
2a01:5b0:9::b
ns8-l4.nic.ru

91.217.21.9
ns4-l4.nic.ru

91.217.20.9
ns3-l4.nic.ru

193.232.146.9
ns44-cloud.nic.ru

185.119.136.13
2a01:5b0:8::d
ns48-cloud.nic.ru

185.119.138.12
2a01:5b0:9::c
ns8-l5.nic.ru

91.217.21.13
ns4-l5.nic.ru

91.217.20.13
ns3-l5.nic.ru

193.232.146.13
ns54-cloud.nic.ru

185.119.136.10
2a01:5b0:8::a
ns58-cloud.nic.ru

185.119.138.13
2a01:5b0:9::d

www.nic.ru

Настройка дополнительного DNS-сервера в Windows Server

Настройка дополнительного DNS-сервера в Windows ServerДополнительные серверы обеспечивают отказоустойчивость DNS-службы сети. Если вы используете полную интеграцию с Active Directory, настраивать дополнительные серверы вам не нужно. Достаточно запустить службу DNS на нескольких контроллерах домена, и Active Directory будет реплицировать информацию DNS на все контроллеры. При использовании частичной интеграции следует настроить дополнительные серверы, чтобы уменьшить нагрузку на основной сервер. В небольшой или средней сети можно использовать в качестве дополнительных серверов DNS-серверы поставщика услуг Интернет. Свяжитесь с провайдером, чтобы узнать подробности.


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

Чтобы установить дополнительные серверы для повышения отказоустойчивости и балансировки нагрузки, выполните следующие действия:

1. Откройте консоль Диспетчер DNS (DNS Manager) и подключитесь к нужному серверу.

2. Щелкните правой кнопкой элемент сервера и выберите команду Создать новую зону (New Zone). Откроется Мастер создания новой зоны (New Zone Wizard). Щелкните Далее (Next).

3. На странице Тип зоны (Zone Туре) установите переключатель Дополнительная зона (Secondary Zone). Щелкните Далее (Next).

4. На дополнительных серверах используются зоны как прямого, так и обратного просмотра. В первую очередь создаются зоны прямого просмотра, поэтому установите переключатель Зона прямого просмотра (Forward Lookup Zone) и щелкните Далее (Next).

5. Введите полное DNS-имя зоны и щелкните Далее (Next).

6. В списке Основные серверы (Master Servers) введите ІР-адрес основного сервера зоны и нажмите Enter. Мастер попытается проверить сервер. Если произошла ошибка, убедитесь, что сервер подключен к сети и вы ввели правильный ІР-адрес. Если вы хотите скопировать данные зоны ИЗ других серверов на случай недоступности первого сервера, повторите этот шаг.

7. Щелкните Далее (Next) и Готово (Finish). В большой сети вам, возможно, потребуется настройка зон обратного просмотра на дополнительных серверах. Этот способ мы подробнее опишем в следующих постах…

logi.cc

Настройка Обратной DNS Зоны — PTR Запись

Что такое обратный DNS запрос?

Обратный DNS Запрос (Reverse DNS) — это преобразование IP-адреса в доменное имя, т.е. противоположное Обычному DNS Запросу, который преобразует доменное имя в IP-адрес.

Сравнение:

## DNS ЗАПРОС ##

# host centos.org
centos.org has address 72.232.194.162

## ОБРАТНЫЙ DNS ЗАПРОС ##

# host 72.232.194.162
162.194.232.72.in-addr.arpa domain name pointer www.centos.org.

Для чего служат обратные DNS?

Наличие обратного DNS является основным требованием для работы некоторых интернет протоколов. Также, очень часто, он используется как спам фильтр для проверки того, что IP-адрес, с которого пришло сообщение, совпадает с доменным именем, и в случае несовпадения письмо блокируется.

Кто управляет обратными DNS зонами?

Обратные DNS зоны управляются владельцами IP адресов (скорее всего Вашим провайдером).

Как узнать обратный DNS адрес?

Используя одну из следующих команд, Вы сможете узнать обратный DNS:

Используя команду ‘host’:

# host 72.232.194.162
162.194.232.72.in-addr.arpa domain name pointer www.centos.org.

Используя команду ‘nslookup’:

# nslookup 208.80.152.201
162.194.232.72.in-addr.arpa     name = www.centos.org.

Используя команду ‘dig’:

# dig -x 208.80.152.201
162.194.232.72.in-addr.arpa. 859 IN     PTR     www.centos.org.

Настройка обратной DNS зоны

Допустим нам необходимо создать PTR запись для IP-адреса. ‘192.168.0.5’. Он должен указывать на ‘имя.вашего.сайта’.

Добавьте новую зону в ‘named.conf’, как показано ниже:

zone "0.168.192.in-addr.arpa" {
type master;
file "/var/named/0.168.192.in-addr.arpa";
};

Создайте файл зоны ‘/var/named/0.168.192.in-addr.arpa’, и добавьте следующее содержание:


$TTL 3600
@          IN SOA нс0.днс.сервер. root.нс0.днс.сервер. (
              2012020801       ; Serial
              21600             ; refresh
              3600              ; retry
              3600000           ; expire
              86400 )           ; minimum

           IN  NS нс0.днс.сервер.
           IN  NS нс1.днс.сервер.

; ----------- ENREGISTREMENTS -----------
$ORIGIN 0.168.192.in-addr.arpa.
5                      IN PTR                  имя.вашего.сайта.
; ----------- ENREGISTREMENTS SPECIAUX -----------

Где ‘нс0.днс.сервер’ и ‘нс1.днс.сервер’ — Ваши DNS сервера.

Сохраните изменения и сконфигурируйте ‘named’:

# rndc reconfig

Проверьте PTR запись:

# dig -x  192.168.0.5 @нс0.днс.сервер +short
имя.вашего.сайта.

www.shellhacks.com

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *