Система доменных имен ЕИС кафедры

Аннотация

С начала 2005 года ведутся активные работы по созданию Единой информационной среды (ЕИС) кафедры ЭВА. На данный момент ЕИС представляет собой информационную систему со сложной архитектурой, включающую множество разнообразных программно-сетевых компонентов.

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

Since the beginning of 2005 the work is underway towards the construction of sub-faculty EVA’s Integrated Information Environment. At present, IIE is a large sophisticated information system consisting of numerous soft - and hardware components.

Information exchange and access to IT-resources are provided by networks with the use of numerous IT-technologies. One of the main tasks of networking is domain names resolution to IP-addresses. The correct functioning of DNS appeared to be a non-trivial problem, in view of LAN’s complicated logical structure. The present article provides the description of methods and instruments used for its solution.

Введение. Система доменных имен.

DNS (Domain Name Sytem) - это система отображения IP-адресов сетевых узлов на их символьные имена и наоборот (RFC 1034, RFC 1035). Служба DNS представляет собой иерархическую структуру серверов, где каждый сервер отвечает за определенную зону - т. е. свою часть дерева доменных имен, хранит соответствующие базы данных, содержащие пары значений имя-адрес для "прямых зон" и адрес-имя для "обратных зон", и отвечает на запросы. Каждый DNS-сервер помимо непосредственно отображений для узлов своей зоны содержит информацию о серверах, обслуживающих подзоны и о сервере(ах) надзоны, т. е. сервере(ах) более высокого уровня.

НЕ нашли? Не то? Что вы ищете?

Серверы самого верхнего уровня называются корневыми, обслуживают корень всей DNS и знают о своих подзонах - .com, .ru, .edu, .net и т. д. Т. к. вышестоящие серверы делегируют нижестоящему серверу полномочия по обслуживанию определенных зон, достаточно знать IP-адрес только сервера надзоны (обычно это DNS-сервер провайдера), чтобы получить информацию об узлах и сетях, не имеющих отношения к данной сети.).

Основные понятия

Домен - централизованно администрируемая область пространства доменных имен в DNS.

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

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

! ! ! Различие между доменом и зоной. Домен - это поддерево дерева доменных имен. Зона - это часть дерева, за которую отвечает тот или иной DNS-сервер (см. ниже таблицу поддоменов и зон домена *****).

DNS-сервер - предназначен для разрешения доменных имён в IP-адреса; обеспечивает хранение одной или нескольких зон и обрабатывает запросы к базе данных DNS.

    Первичный (главный) DNS-сервер для зоны - DNS-сервер, обеспечивающий хранение полной исходной информации об этой зоне; содержит базу данных официально утвержденных пар имен и адресов хостов и иной информации об обслуживаемых системах; способен давать авторитетные ответы на запросы о системах, отнесенных к ее зоне ответственности. Каждый домен обслуживается минимум одним первичным сервером. Вторичный (подчиненный) DNS-сервер для зоны - DNS-сервер, получающий полную информацию об этой зоне с другого DNS-сервера; идентичен главному во всем, за исключением зоны ответственности, которая не определяется его собственной базой данных, а задается главным сервером. Наличие вторичного сервера не является обязательным, но повышает производительность и отказоустойчивость DNS-системы. Кэширующий сервер не обладает базой данных; он выполняет запросы для клиентов и помещает ответы в собственный кэш, со временем накапливая значительный объем данных. Главное назначение кэширующего сервера — повышение производительности.

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

Рекурсивный запрос - как правило выполняется DNS-клиентом и требует в качестве ответа непосредственных результатов поиска (все действия с целью получения ответа на запрос клиента сервер берет на себя).

Итеративный запрос - последовательный запрос, выполняемый от сервера к серверу (в ответ сервер может вернуть как требуемые данные, так и адрес следующего сервера).

Авторитетный ответ (authoritative answer) - ответ на DNS-запрос, поступивший от сервера, непосредственно отвечающего за зону, для хоста которой запрашивалась информация(т. е. отображение для запрашиваемого хоста содержится в его базе данных). Если же ответ поступил от сервера, не отвечающего за зону (например, данные были извлечены из кэша), такой ответ будет помечен как неавторитетный(non-authoritative answer).

Кэш DNS-сервера помогает сделать поиск запрашиваемых данных более эффективными. Сервер кэширует ответы в каждой точке поиска. Например, если после связи с узлом www. обратиться к другому серверу. com, локальный DNS-сервер уже будет знать адрес сервера домена. com.

Алиас (псевдоним) - дополнительное доменное имя узла, ссылающееся на основное доменное имя и соотвественно связанный с ним IP-адрес. Должно принадлежать тому же домену, что и основное имя.

Процесс разрешения DNS-запроса

DNS-сервер (или представление DNS-сервера), отвечающий за определенную зону, имеет свой IP-адрес. При необходимости произвести какое-либо из DNS-преобразований ("адрес в имя", "имя в адрес") хост обращается к своему DNS-серверу через протокол UDP на порт 53.

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

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

Именно такая схема работы DNS-серверов реализована в ЕИС кафедры.

Пример: Порядок разрешения DNS-запроса

Хост ***** желает узнать IP-адрес хоста achinoam. .

Host1 отправляет запрос своему DNS-серверу 192.168.201.1, отвечающему за домен *****. Если у сервера нет в кэше требуемых данных, он перенаправляет запрос форвардеру - DNS-серверу ns. ***** (80.250.162.178), отвечающему за локальный домен ***** и за разрешение запросов "во внешний мир". Если форвардер не находит запрашиваемых данных ни в своей БД, ни в кэше, он обращается к серверу, стоящему иерархически выше, т. е. отвечающему за "наддомен". В данном случае это сервер, отвечающий за зону ru, который также не содержит в БД данных о запрашиваемом хосте. Сервер ru. передает запрос корневому серверу доменной системы (на самом деле таких серверов 13, все данные на них идентичны), адреса корневых серверов известны каждому DNS-серверу. Корневой сервер, как минимум, может ответить адресом сервера, отвечающего за зону com. Но допустим, в его кэше оказался адрес сервера, отвечающего за . На самом деле корневые серверы отвечают не только за корень доменной системы, но и за большинство доменов верхнего уровня, следовательно, они могут непосредственно делегировать полномочия серверам доменов второго уровня - например, . Ns. ***** повторяет запрос, адресуя его серверу, отвечающему за , в базе которого содержится отображение для требуемого хоста achinoam. . Получив IP-адрес achinoam. *****, форвардер ns. ***** возвращает его клиенту. Затем форвардер ns. ***** записывает данные об этом хосте в свой кэш. Таким образом достигается локализация кэша.

Также кэшируются и все дополнительные данные, полученные в процессе обработки запроса - например, адрес сервера - в случае запроса на хост этого домена izubr. , DNS=-сервер сможет сразу обратиться к нему без промежуточных запросов.

Преобразование "доменное имя в IP-адрес" выполняется всякий раз при попытке установления TCP/IP-соединения с хостом, если указано доменное имя этого хоста. Некоторые программы выполняют также и обратное DNS-преобразование. Эти операции скрыты от пользователя.

DDNS

Поддержка DNS-сервером механизма динамического редактирования базы данных зоны (dynamic update, RFC 2136) позволяет хостам, авторизованным для выполнения этой операции, вносить изменения в DNS-таблицу. Это значит, что по запросу от такого хоста записи в базе данных DNS-сервера могут создаваться и удаляться "на лету". Сообщения update отправляются серверу, отвечающему (authoritative) за данную зону (при этом неважно, первичный этот сервер или вторичный: вторичные сервера перенаправят сообщение первичному).

Механизм динамического редактирования базы данных используется (в ЕИС кафедры) VPN-сервером (конкретно демоном pppd) и DHCP-сервером. После выдачи динамического IP-адреса pppd и DHCP-сервер регистрируют его в DNS. ПО, реализующее PPP и DHCP, включает встроенные функции, формирующие сообщения update.

Подробнее см. ниже, разделы DHCP+DNS и PPPD+DNS.

nslookup

Программа nslookup' позволяет произвести DNS-преобразования в явном виде. Например:

%nslookup www.

Server: ns. *****

Address: 80.250.162.178

non-authtoritative answer:

Name: www.

Address: 204.9.177.18

Вывод программы означает, что был опрошен сервер ns. ***** (его IP-адрес 80.250.162.178) и получен ответ IP (www. ) = 204.9.177.18. Ответ помечен как "неавторитетный", поскольку данные были получены через последовательные запросы к другим DNS-серверам, а не взяты из локальной БД DNS-сервера ns. *****

Пример обратного преобразования:

%nslookup 204.9.177.18

Server: ns. *****

Address: 80.250.162.178

Non-authoritative answer:

18.177.9.204.in-addr. arpa name = .

Authoritative answers can be found from:

177.9.204.in-addr. arpa nameserver = .

177.9.204.in-addr. arpa nameserver = .

Программа nslookup работает также в режиме командной строки. Необходимые команды:

    server [имя_опрашиваемого_сервера]
    lserver [имя_опрашиваемого_сервера]

- сменить опрашиваемый DNS-сервер. Например:

%nslookup

> server *****

Default server: *****

Address: 192.168.201.1#53

Без аргумента - установить сервер по умолчанию ("свой" сервер).

Все запросы (кроме команды lserver) отправляются к опрашиваемому серверу, установленному в данный момент.

Nslookup позволяет напрямую обращаться с запросами к серверам, непосредственно отвечающим за ту или иную зону. Если же ответ поступил от сервера, не отвечающего за зону, для хоста которой запрашивалась информация (например, данные были извлечены из кэша), такой ответ будет помечен как "non-authoritative answer".

server и lserver отличаются тем, что при смене сервера командой server адрес нового сервера преобразуется с помощью текущего сервера, а команда lserver производит то же преобразование с помощью сервера, установленного для nslookup по умолчанию - "своего" сервера. Это имеет значение, когда текущий сервер по какой-либо причине не отвечает на запросы.

    set type=тип_данных

-установить запрос данных определенного типа. Например:

> set type=NS

> *****

означает запрос списка DNS-серверов, отвечающих (authoritative) за домен *****. (Запрос в этом случае должен состоять из имени домена, а не отдельного хоста.) Полученный ответ:

Server: *****

Address: 192.168.201.1#53

Non-authoritative answer:

***** nameserver = *****.

***** nameserver = ns. *****.

Authoritative answers can be found from:

ns. ***** internet address = 80.250.162.178

***** internet address = 85.30.199.61

Возможные типы данных: • SOA (Start Of Authority) - заголовок зоны, • NS (Name Server) - сервер DNS, • A (Address) - IP-адрес, если указано доменное имя, или доменное имя, если указан IP-адрес (выбрано по умолчанию), • MX (Mail Exchanger) - обработчик почты, • CNAME (Canonical Name) - каноническое имя, • PTR (Pointer) - запрос по обратной зоне, • ANY - все записи.

Подробнее о типах данных см. конфигурационные файлы DNS-сервера BIND

Другие команды nslookup:

    set recurse - отправлять рекурсивные запросы (выбрано по умолчанию). set norecurse - отправлять итеративные запросы. set domain=имя_домена - установить имя домена, добавляемое к неполностью определенным доменным именам (по умолчанию берется из /etc/resolv. conf). set debug - подробно показывать содержимое поступающих ответов. set nodebug - отменить set debug (отменено по умолчанию). set d2 - подробно показывать содержимое отправляемых запросов. set nod2 - отменить set d2 (отменено по умолчанию). set all - показать значения всех опций. ls имя_домена - вывести список хостов указанного домена, например ls *****. Предварительно следует переключиться на опрос сервера, отвечающего (authoritative) за данный домен. В целях безопасности некоторые серверы не выполняют эту команд (запрещена пересылка баз данных зоны). help - помощь. exit - выход.

Система доменных имен ЕИС кафедры

DNS-сервер, установленный на сервере-роутере:

    разрешает адреса узлов внешней сети (Интеренет) устанавливает соответствие доменным именам компьютеров аудиторных сетей и беспроводного сегмента, их IP-адреса при VPN-подключении устанавливает соответствие именам авторизовавшихся пользователей ЕСП или других подсетей ЛВС кафедры их внутриканальные IP-адреса.

ЕИС кафедры состоит из внутренней сети, включающей аудиторные сети, ЕСП, беспроводной сегмент) и сети, непосредственно находящейся в Интернет, содержащей web - и mail - серверы и другие ключевые узлы ЛВС.

Имена хостов внутренней и внешней сетей разрешаются независимо разными представлениям (view) DNS-сервера (по сути разными серверами) - внешним и внутренними.

Схема1. Зоны ответственности системного DNS-сервера

Image: DNS.jpg

Внешнее представление DNS-сервера

    Для разрешения имен хостов ЛВС, непосредственно доступных из Интернет (внешней сети). При запросах изнутри и извне. Для разрешения имен хостов других доменов (находящихся вне зон ответственности DNS-сервера). В данном случае передает рекурсивный запрос дальше по цепочке DNS-серверов.
    Отвечает сразу за несколько доменов. Таким образом имеет несколько зон ответственности, для каждой из которых является первичным.
    Дает авторитетные ответы на запросы о хостах, информация о которых содержится в его базе данных, т. е. принадлежащих к-л из его зон ответственности.

Зоны ответственности внешнего представления DNS-сервера*

    localhost ***** server. ***** vps. ***** ***** ***** ***** eqc. ***** fiorentini. su ***** ***** *****

* Опущена большая часть персональных доменных имен

см. конфигурацию внешнего представления DNS-сервера /etc/bind/views/ext. view

Внешнее отображение DNS-сервера "слушает" внешний IP-адрес сервера-роутера 80.250.162.178, к которому можно непосредственно обращаться из внешней глобальной сети.

Сервер отвечает за разрешение хостов, доступных из Интернет, которые имеют постоянные статически назначенные внешние IP-адреса. Следовательно,

! ! ! Все записи в базу данных (DNS-таблицу) внешнего отображения DNS-сервера заносятся статически администратором сети.

Т. е. нет динамического добавления записей (посредством связи с DHCP или PPP).

Основная хона отвественности внешнего отображения DNS-сервера - кафедральный домен ***** и его поддомены vps. ***** (VPS-серверы) и server. *****.

*****

База данных домена (зоны) ***** содержит отображения для ключевых узлов ЛВС кафедры.

Из Интернет доступны ключевые узлы ЛВС кафедры:

Таблица1. Хосты зоны отвественности *****

ns2 85.30.199.61 Вторичный DNS-сервер

ns 80.250.162.178 Первичный DNS-сервер (внешнее представление)

router 80.250.162.178 Сервер-роутер

wi-fi-net 80.250.162.179 IP для NATа некафедральных пользователей Wi-Fi

ms 80.250.162.180 Почтовый сервер

ws1 80.250.162.181 Web-сервер1

ws2 80.250.162.182 Web-сервер2

video 80.250.162.182 -

linux-server 80.250.162.184 Сервер для практики студентов (работа на ОС Linux)

video-server 80.250.163.82 Видео-сервер

dchub 80.250.163.83 Сервер пиринговой сети

У этих узлов есть псевдонимы (алиасы), которые служат для обращения к разного вида ресурсам и сервисам: Web-ресурсам портала Auditory, VPN-серверу для доступа в ЕСП кафедры, серверу пиринговой сети.

Таблица2. Алиасы ключевых узлов ЛВС кафедры

***** (Web-сервер2)*

ms. ***** (Почтовый сервер)

birthday

lists

blog

mail

city

mailserver

eva

qwetest

eva-dev

name.vps. ***** (Виртуальный частный сервер)**

ez_pub

burn

forum

library

forum2

jabber

games

router. ***** (Сервер-роутер)

hwost

vpn

ie

kuteam

life

moscow

news

paritet

photo

phpLDAPAdmin

phpMyAdmin

startup

testing

time-management

wi-fi

wiki

www

journal

* Опущена большая часть персональных доменных имен.

** Вместо name подставить псевдоним.

Пояснения к таблице алиасов:

    Алиасы Web-сервера2 предназначены для адресации сайтов портала Auditory. Алиасы Почтового сервера предназначены для обращения к web-интерфейсу почтовой службы, ????????????? Алиасы VPS являются краткими именами, которыми удобнее пользоваться при обращении с персональному виртуальному серверу. Алиас роутера используется при обращении к VPN-серверу, обеспечивающему подключение к ЕСП кафедры.

server. *****.

Таблица3. Хосты зоны отвественности server. *****

server. ***** 80.250.162.181

router 80.250.162.178

wi-fi-gw 80.250.162.179

mail 80.250.162.180

ws1 80.250.162.181

ws2 80.250.162.182

la2 80.250.162.183

dnat1.router 80.250.163.82

dnat2.router 80.250.163.83

vps. *****.

Таблица4. Хосты зоны отвественности vps. *****

vps. ***** 80.250.162.181

linux-server 80.250.162.184

stels ws1.server. *****.

srvstat ws1.server. *****.

consult ws1.server. *****.

library ws1.server. *****.

jungle ws1.server. *****.

trash ws1.server. *****.

burn ws1.server. *****.

jabber CNAME dnat2.router. server. *****.

Домен ***** состоит из 14 поддоменов; 2 описанных выше (vps. ***** и server. *****) используются для именования хостов, доступных из Интернет и обслуживаются внешним отображением DNS-сервера. 13 используются для именования хостов внутренних подсетей ЛВС кафедры и клиентов, подключившихся к ЕСП кафедры по VPN; ответственность за каждый из этих поддоменов делегирована соответствующему внутреннему представлению DNS-сервера. При этом внешний DNS-сервер, ответственный за наддомен *****, не содержит в описании своей зоны информации о внутренних серверах и не передает им запросы извне, т. е. имена этих 12 "приватных" поддоменов разрешаются только при запросах изнутри ЛВС кафедры, более того, при запросе от хоста той же подсети (если прямо направлены на IP-адрес соответствующего внутреннего представления DNS-сервера).

Например, если хост ***** обратится с запросом о разрешении имени хоста ***** в его IP-адрес, он не получит ответа. Запрос поступит на DNS-сервер, отвечающий за зону ***** (192.168.201.1), и содержащий только отображения для хостов этой зоны. Он передаст запрос форвардеру - внешнему отображению DNS-сервера, который будет искать информацию о хосте ***** в зоне наддомена *****. А он - см. выше - не содержит адреса внутреннего сервера, отвественного за зону ***** (*****, 192.168.207.1), который содержит отображение для этого хоста. Т. е. имя хоста ***** можно было бы разрешить только обращаясь из сети 507 аудитории, по умолчанию на DNS-сервер *****.

Таким образом, в домене ***** 15 зон: 1 "главная" зона ***** обслуживается внешним отображением DNS-сервера и содержит информацию о делегировании полномочий для поддоменов vps. ***** и server. *****, 2х зон ответственности того же сервера.

(см. конфигурацию BIND, "делегирование зон")

13 зон, представляющих внутренние подсети ЛВС кафедры и ЕСП, обслуживаются независимо соотвествующими внутренними представлениями DNS-сервера.

Внутренние представления DNS-сервера

Внутренних представлений DNS-сервера 12 (по числу поддоменов *****), какждое суть отдельный DNS-сервер, отвечающий за свой поддомен.

    Для разрешения имен хостов ЛВС кафедры (внутренней сети)соответственно. При запросах изнутри ЛВС.
    Каждое внутреннее представление отвечает за свой поддомен ***** (представляющий какую-либо подсеть ЛВС кафедры (т. е. каждая подсеть представляет собой зону ответственнности соответствующего представления.

Пример: Сеть 510 аудитории (VLAN1) представляет собой домен ***** (соответственно, один из поддоменов *****). За этот домен отвечает соотвествующее внутреннее представление DNS-сервера - ***** (IP 192.168.201.1). Таким образом домен ***** - зона ответственности этого DNS-сервера.

Локальные поддомены *****

Таблица5. Внутренние представления DNS-сервера

Поддомен (зона)

IP-адрес сервера (внутреннего представления)

VLAN/подсеть

*****

192.168.201.1

vlan1/ауд.510,504-k (студенческий центр, админ. часть ауд.504)

*****

192.168.202.1

vlan2/ауд. 502

*****

192.168.203.1

vlan3/ауд. 503

*****

192.168.204.1

vlan4/ауд.504 (учебная)

*****

192.168.205.1

vlan5/ауд. 505

*****

192.168.206.1

vlan6/ауд. 506

*****

192.168.207.1

vlan7/ауд. 507

504-v. *****

192.168.208.1

vlan8/ауд. 504-v (видеостудия)

*****

192.168.209.1

vlan9/ауд. 225 (учебная)

wi-fi. *****

192.168.211.1

vlan11/Wi-Fi ( беспроводной сегмент)

knet. *****

10.0.0.1

vlan12/(ЕСП)

vpn. wi-fi. *****

192.168.213.1

vlan13/Wi-Fi для некафедральных пользователей


В зонах, относящихся к внутренним сетям (аудиторные сети, ЕСП кафедры, беспроводной сегмент ЛВС) присутствуют только записи, соответствующие этим зонам. Для разрешения внешних имён внутреннее представление передает запрос на внешнее представление, где присутствуют записи обо всех зонах (см. конфигурацию BIND, конфиги представлений views).

Таким образом происходит локализация кэша – история разрешения всех имен хранится в одном месте – файле кэша внешнего представления DNS-сервера.

Статически назначенные адреса

Домен *****

***** 192.168.201.1

athlon 192.168.201.87

domain 192.168.201.254

livecd 192.168.201.88

ns* 192.168.201.1

router 192.168.201.1

Домен *****

***** 192.168.202.1

domain 192.168.202.254

ns 192.168.202.1

router 192.168.202.1

Домен *****

*****. 192.168.203.1

ns 192.168.203.1

router 192.168.203.1

domain 192.168.203.254

Домен *****

*****. 192.168.204.1

ns 192.168.204.1

router 192.168.204.1

domain 192.168.204.254

Домен 504-v. *****

504-v. *****. 192.168.208.1

ns 192.168.208.1

router 192.168.208.1

domain 192.168.208.254

Домен *****

*****. 192.168.205.1

ns 192.168.205.1

router 192.168.205.1

domain 192.168.205.254

Домен *****

*****. 192.168.206.1

ns 192.168.206.1

router 192.168.206.1

domain 192.168.206.254

Домен *****

*****. 192.168.207.1

ns 192.168.207.1

router 192.168.207.1

domain 192.168.207.254

Домен *****

*****. 192.168.209.1

ns 192.168.209.1

router 192.168.209.1

domain 192.168.209.254

Домен wi-fi. *****

wi-fi. *****. 192.168.211.1

ns 192.168.211.1

router 192.168.211.1

domain 192.168.211.254

terminal 192.168.211.136

Домен wi-fi. vpn. *****

wi-fi. vpn. *****. 192.168.213.1

ns 192.168.213.1

router 192.168.213.1

Домен knet. *****

Доменное имя IP-адрес Синопсис

knet. *****. 10.0.0.1

ns. knet. *****. 10.0.0.1 DNS-сервер ЕСП кафедры

router. knet. *****. 10.0.0.1 Имя роутера в ЕСП

225.knet. *****. 10.0.0.9 VPN-сервер knet.225

502.knet. *****. 10.0.0.2 VPN-сервер knet.502

503.knet. *****. 10.0.0.3 VPN-сервер knet.503

504.knet. *****. 10.0.0.4 VPN-сервер knet.504

504-v. knet. *****. 10.0.0.8 VPN-сервер knet.504-v

505.knet. *****. 10.0.0.5 VPN-сервер knet.505

506.knet. *****. 10.0.0.6 VPN-сервер knet.506

507.knet. *****. 10.0.0.7 VPN-сервер knet.507

510.knet. *****. 10.0.0.1 VPN-сервер knet.510

wi-fi. knet. *****. 10.0.0.10 VPN-сервер knet. wi-fi


* ns+имя зоны - имена DNS-серверов, ответственных за соответствующую зону.

Динамически назначаемые адреса (DDNS)

DNS-сервер ЕИС поддерживает механизм DDNS (Dynamic DNS), благодаря чему записи в него могут быть добавлены не только статически администратором, но и динамически DHCP- и VPN-серверами.


Image: DDNS.jpg

DHCP+DNS

Посредством связки DHCP – DDNS реализуются следующие функции:

1. При подключении компьютера к аудиторной сети, если адрес ему выделяется средствами DHCP, запись об этом компьютере динамически добавляется в зону сеть. ***** (сеть = 510, 502, 503, 504, 505, 506, 507, 225, 504-v) соответствующего внутреннего представления DNS-сервера (192.168.20х.1).

2. При подключении клиента к беспроводному сегменту сети запись о хосте клиента динамически добавляется в зону wi-fi. ***** соответствующего DNS-сервера (192.168.211.1) и удаляется при отключении клиента (т. е. запись сохраняется только на время сеанса связи).


Доменное имя для хостов в обоих случаях формируется следующим образом:

имя_хоста + имя_зоны_DNS

Пример: При подключении хоста trash к Wi-Fi DHCP-сервер выделил ему IP-адрес 192.168.211.173. Соотвественно, в файл зоны wi-fi. ***** DNS-сервера 192.168.211.1 будет добавлено отображение:

trash. wi-fi. ***** 192.168.211.173

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

PPPD+DNS

Посредством связки PPP – DDNS реализуются следующие функции:

1. При подключении клиента к ЕСП кафедры запись об этом клиенте динамически добавляется в зону knet. ***** внешнего представления DNS-сервера (80.250.162.178).

2. При VPN-подключении клиента к какой-либо подсети ЛВС кафедры запись о нем динамически добавляется в зону сеть. ***** (сеть = 510, 502, 503, 504, 505, 506, 507, 225, 504-v, wi-fi) соответствующего внутреннего представления DNS-сервера (192.168.20х.1).

3. При VPN-подключении некафедрального клиента к vpn. wi-fi запись о нем динамически добавляется в зону wi-fi. vpn. ***** соответствующего внутреннего представления DNS-сервера (192.168.213.1).

В каждом из этих случаев запись сохраняется только на время сеанса связи.

Доменное имя для хостов в обоих случаях формируется следующим образом:

Имя. Фамилия + имя_зоны_DNS

где Имя. Фамилия - личные данные (логин) подключившегося по VPN клиента, сообщенные им и проверенные при авторизации.

В соответствие имени ставится выделенный VPN-сервером (внутриканальный) IP-адрес.

Пример1: При подключении пользователя Olga. Belova к ЕСП кафедры pppd выделил ему IP-адрес 10.0.6.2. Соотвественно, в файл зоны knet. ***** DNS-сервера 10.0.0.1 будет добавлено отображение:

Olga. Belova. knet. *****. 10.0.6.2

Пример2: При VPN-подключении пользователя Olga. Belova к сети 510 аудитории (VLAN1)ы pppd выделил ему IP-адрес 192.168.201.241. Соотвественно, в файл зоны ***** DNS-сервера 192.168.201.1 будет добавлено отображение.

olga. *****. 192.168.201.241

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


Функция update специально конфигурируется при настройке соответствующего ПО.

Заключение

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

Технология «представлений» позволяет разделить пространства имен внутри кафедральной ЛВС и снаружи, что является дополнительным средством обеспечения безопасности и логической сегментации сети.

Технология DDNS является важнейшим компонентом мониторинга, позволяя отслеживать подключившихся по VPN клиентов. Кроме того, динамическое добавление/удаление записей в базу DNS сильно упрощает администрирование сети.

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

Литература

1.  Олиферы "Компьютерные сети", Питер, 2006

2.  Ли Альбетц, "DNS и BIND, Символ-плюс, 2004

3.  http://solaris. *****/docs/RUS/dns1/
Максим Мамаев "DNS-доменная служба имен"

4.  RFC 1034 Domain Names — Concepts and Facilities
RFC 1035 Domain Names — Implementation and Specification
RFC 1995 Incremental Zone Transfer in DNS
RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE)