Отображение символьных имён на IР-адреса

Если IР работает с 32-битными IР-адресами хостов-отправителей и хостов-получателей, то пользователи компьютеров предпочитают иметь дело с понятными именами, а не IР-адресами.

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

Для преобразования имени хоста в IР-адрес в сетях TCP/IP используются следующие средства:

· Файлы HOSTS, представляющие собой текстовые файлы со списками имен хостов и соответствующих им IР-адресов;

· Серверы DNS, на которых хранятся базы данных, содержащие соответствия доменных имён хостов их IР-адресам;

· Средства разрешения имен NetBIOS.

Один из распространённых способов преобразования хост-имени в IР-адрес заключается в использовании локальной базы данных, связывающей IР-адреса с хост-именами. В большинстве систем эта база данных содержится в файле HOSTS. Файл HOSTS содержит информацию о том, какой IР-адрес связывается с тем или иным именем.

Когда компьютеру требуется найти другой компьютер в сети, он сначала обращается к локальному файлу HOSTS. Этот файл обрабатывается раньше запроса к DNS и потому имеет приоритет, которым можно воспользоваться не только для того чтобы ускорить обращения к нужным сайтам, но и предотвратить посещение не шибко нужных. Так же, управляя этим файлом, можно перенаправлять запросы нежелательных страниц на некоторый другой сайт (например, сайт МВД). Ещё одно любопытное применение этого файла ­для создания быстрого доступа к какому-то определённому сайту. Сделав соответствующую запись в фале HOSTS, можно попасть на этот сайт путём ввода всего одного символа в адресную строку браузера.

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

Файл HOSTS представляет собою простой текстовый файл, содержащий по одной записи на строку, состоящую из IР -адреса, имени хоста и необязательного списка псевдонимов. Поля отделяются пробелами или табуляцией, а поле адреса должно начинаться в первой колонке. Все, что следует после символа 1 # 1, расценивается как комментарий и игнорируется. Имя хоста может быть полностью квалифицированным (например, uits.msou.ru) или заданным относительно локального домена (например, просто uits). Поскольку компьютер может выполнять в сети разные задачи, каждому IР -адресу в списке файла HOSTS могут быть сопоставлены несколько имен хостов, в зависимости от желания пользователей. Например:

# HOSTS file # # # IP FQDN Comment # # Пример IP-адреса с несколькими именами: 2.54.94.97 email.acme.ru #Почтовый сервер 2.54.94.97 www.acme.ru #Сервер Web 2.54.94.97 ftp.acme.ru #Сервер FTP # 127.0.0.1 www.porno.ru #Запрет на доступ к сайту porno.ru # 216.239.39.99 G # Вход на сайт пойсковой машины # google.com, набрав символ “G” #

Точно так же, как с МАС-адресами хостов, бывает необходимо отобразить IР-адрес на символьное имя. Поэтому файл HOSTS имеет компаньона - файл NETWORKS, который отображает сетевой адрес на имя хоста. Его синтаксис следующий:

<Символьное ИМЯ> <IP address> # Комментарии

Итак, разрешение имени начинается в тот момент, когда пользователь вводит команду, где указывает имя узла назначения. На первом шаге компьютеры пытаются разрешить имя хоста в IР -адрес с помощью файла HOSTS. Если это не удаётся, то посылается запрос к серверам DNS.

Серверы DNS являются фундаментальной частью средств, обеспечивающих разрешение имён в сетях TCP/IP. Каждый DNS -сервер содержит часть базы данных с именами хостов, которым сопоставлены в соответствие IР -адреса. Вся база данных распределена по административным доменам сети Iпternet. для работы с этой базой данных используется система DNS, определённая стандартами RFC-1034 и -1035.

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

Разрешение имен при помощи сервера DNS очень напоминает разрешение средствами файла HOSTS. Серверы просматривают свои зоны, также называемые файлами баз данных DNS, или просто db-файлами. Зоны содержат записи ресурсов, которые и составляют информацию, связанную с DNS­ доменом. Например, одни записи ресурсов связывают понятные пользователю имена с IР - адресами, а другие - IР -адреса с именами. Некоторые записи ресурсов не только содержат информацию о серверах в DNS -доменах, но и позволяют определить домены, указывая полномочные серверы. Записи ресурсов имеют следующийсинтаксис:

Владелец TTL Класс Тип Данные

· Владелец (Owпer) – имя хоста или DNS-домена, которому принадлежит эта запись ресурсов;

· TTL (время жизни) – 32-битное целое число, представляющее интервал времени в секундах, в течение которого DNS­-сервер или интерпретатор должен кэшировать эту запись до того, как её отбросить;

· Класс (Class) – определяет используемое семейство протоколов;

· Тип (Туре) – определяет тип записи ресурсов;

· Данные (RDATA) – данные записи ресурсов. Например, запись ресурса адреса (А) сопоставляет полное доменное имя с IP-адресом, благодаря чему интерпретаторы могут получить IР-адреса по именам.

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

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

При обработке рекурсивного запроса серверу часто требуется посылать несколько запросов, чтобы получить окончательный ответ. Сервер кэширует всю принимаемую в ходе этого процесс а информацию на период, указываемый в возвращаемых данных. Этот период называется временем жизни (Time-To-­Live, TTL) и выражается в секундах. Значение TTL определяется администратором сервера основной зоны, содержащей искомые данные. Меньшие значения TTL прибавляют уверенность в том, что информация о домене соответствует действительности при её частом изменении, но повышают нагрузку на сервер имён и увеличивают трафик в Интернете. Как только данные помещены в кэш DNS - сервера,последний хранит их в течение заданного TTL. Включая в ответ данные из кэша, DNS - сервер сообщает оставшееся время жизни этих данных.

Существуют также итеративные запросы, которые должны оставаться локальными по нескольким причинам, чаще всего из-за недоступности другого сервера DNS. Выдавая итеративный запрос, DNS - клиентдаёт возможность серверу вернуть наиболее полезный ответ, который тот может подготовить на основе имеющейся в его зоне или кэше информации. Если запрашиваемый DNS - серверне имеет точной информации о запрашиваемом имени, то наиболее полезной информацией, которую он способен вернуть, будет ссылка (referral), т.е. указатель на DNS - сервер, полномочный для более низкого уровня пространства доменных имён. DNS - клиентможет затем запросить DNS - сервер, на который он получил ссылку. Клиент продолжает этот процесс, пока не найдёт полномочный для запрашиваемого имени DNS - сервер, пока не возникнет ошибка или пока не истечёт время ожидания. Этот процесс называют «просмотром дерева», и такой тип запросов обычно используется DNS­ -сервером, пытающимся выполнить рекурсивный запрос DNS - клиента.

За каждую зону DNS отвечает не менее двух серверов. Один из них является первичным (primary), остальные – вторичными (secoпdary). Первичный сервер содержит оригинальные файлы с базой данных DNS для своей зоны. Вторичные серверы получают эти данные по сети от первичного сервера и периодически запрашивают первичный сервер на предмет обновления данных. С точки зрения обслуживания клиентских запросов первичный и вторичные серверы идентичны, все они выдают авторитативные ответы. Рекомендуется, чтобы первичный и вторичные серверы находились в разных сетях – для увеличения надежности обработки запросов на случай, если сеть одного из серверов становится недоступной. Серверы DNS не обязаны находиться в том домене, за который они отвечают.

В системе DNS существует более гибкий протокол динамического редактирования базы данных хост-uмен - DHCP (Dyпamic Host Coпfiguratioп Protocol, определённый в RFC-2163 ). Основным назначением DHCP является динамическое назначение IР -адресов. Однако, кроме динамического, DHCP может поддерживать и более простые способы ручного и автоматического статического назначения адресов.

В ручной процедуре назначения адресов активное участие принимает администратор, который предоставляет DHCP - серверуинформацию о соответствии IР - адресовфизическим адресам или другим идентификаторам клиентов. Эти адреса сообщаются клиентам в ответ на их запросы к DHCP ­- серверу.

При автоматическом статическом способе DHCP - серверприсваивает IP ­- адрес и, возможно, другие параметры конфигурации клиента из пула наличных IP - адресовбез вмешательства оператора. Границы пула назначаемых адресов задает администратор при конфигурировании DHCP - сервера. Между идентификатором клиента и его IP - адресомпо-прежнему, как и при ручном назначении, существует постоянное соответствие. Оно устанавливается в момент первичного назначения сервером DHCP IP - aдpecaклиенту. При всех последующих запросах сервер возвращает тот же самый IР - адрес.

При динамическом распределении адресов DHCP - сервервыдает адрес клиенту на ограниченное время, что дает возможность впоследствии повторно использовать IР - адресадругими компьютерами. Динамическое разделение адресов позволяет строить IР - сеть, количество узлов в которой намного превышает количество имеющихся в распоряжении администратора IP­ -адресов.

DHCP обеспечивает надежный и простой способ конфигурации сети TCP/IP, гарантируя отсутствие конфликтов адресов за счет централизованного управления их распределением. Администратор управляет процессом назначения адресов с помощью параметра "продолжительности аренды" (lease duratioп), которая определяет, как долго компьютер может использовать назначенный IР - адрес, перед тем как снова запросить его от сервера DHCP в аренду.

Однако использование DHCP несет в себе и некоторые проблемы. Во-­первых, это проблема согласования информационной адресной базы в службах DHCP и DNS. Во-вторых, нестабильность IP - адресовусложняет процесс управления сетью. И, наконец, централизация процедуры назначения адресов снижает надежность системы: при отказе DHCP - серверавсе его клиенты оказываются не в состоянии получить IР -адреси другую информацию о конфигурации.

Итак, на втором шаге, серверы DNS ищут имя хоста в базе данных и разрешают его в IP - aдpec. После того как имя узла разрешено, по протоколу ARP определяется адрес сетевого адаптера. Если узел назначения находится в локальной сети, то это реализуется при помощи кэша ARP или широковещания. Если же узел получатель находится в удаленной сети, то ARP получает адрес маршрутизатора, который может перенаправить запрос. Когда же сервер DNS находится в удалённой сети, тогда перед разрешением имени ARP должен получить адрес сетевого адаптера маршрутизатора.

Если сервер DNS не может разрешить имя узла, то узел-отправитель обращается к своим средствам разрешения NetBIOS имен. В противном случае, когда эти средства недоступны, процесс прекращается и генерируется сообщение об ошибке.

Структуризация сетей IP с помощью масок.

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

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

Маска – это число, двоичная запись которого содержит единицы в тех разрядах, которые должны интерпретироваться как номер сети.

Например, для стандартных классов сетей маски имеют следующие значения:

255.0.0.0 - маска для сети класса А,

255.255.0.0 - маска для сети класса В,

255.255.255.0 - маска для сети класса С.

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

Пусть, например, маска имеет значение 255.255.192.0 (11111111 11111111 11000000 00000000). И пусть сеть имеет номер 129.44.0.0 (10000001 00101100 00000000 00000000), из которого видно, что она относится к классу В. После наложения маски на этот адрес число разрядов, интерпретируемых как номер сети, увеличилось с 16 до 18, то есть администратор получил возможность использовать вместо одного, централизованно заданного ему номера сети, четыре:

129.44.0.0 (10000001 00101100 00000000 00000000)

129.44.64.0 (10000001 00101100 01000000 00000000)

129.44.128.0 (10000001 00101100 10000000 00000000)

129.44.192.0 (10000001 00101100 11000000 00000000)

Например, IР -адрес 129.44.141.15 (10000001 00101100 10001101 00001111), который по стандартам IP задает номер сети 129.44.0.0 и номер узла 0.0.141.15, теперь, при использовании маски, будет интерпретироваться как пара:

129.44.128.0 - номер сети, 0.0.13.15 - номер узла.

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

Еще один пример. Пусть некоторая сеть относится к классу В и имеет адрес 128.10.0.0 (рисунок 3.9). Этот адрес используется маршрутизатором, соединяющим сеть с остальной частью интерсети. И пусть среди всех станций сети есть станции, слабо взаимодействующие между собой. Их желательно было бы изолировать в разных сетях. Для этого сеть можно разделить на две сети, подключив их к соответствующим портам маршрутизатора, и задать для этих портов в качестве маски, например, число 255.255.255.0, то есть организовать внутри исходной сети с централизовано заданным номером две подсети класса С (можно было бы выбрать и другой размер для поля адреса подсети). Извне сеть по-прежнему будет выглядеть, как единая сеть класса В, а на местном уровне это будут две отдельные сети класса С. Приходящий общий трафик будет разделяться местным маршрутизатором между подсетями.

(subnetworking mask)

Рис.3.9 Пример использования масок для структурирования сети

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

Дата добавления: 2013-12-12