Разрешение доменное имя в ip адрес

Хотя нам — людям нравится давать названия вещам, компьютеры в действительности больше любят числа. В TCP/IP сетях (которые составляют Интернет), мы называем машину определенным именем — и каждая машина живет в определенной области — «домене». Например, моя рабочая станция Linux называется archenland, и постоянно находится в домене interweft.com.au . Читабельный для человека адрес таким образом — archenland.interweft.com.au (такая запись известна также как FQDN — полностью квалифицированное имя домена).

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

Трансляция имени машины (и домена) в адрес, фактически используемый в Интернет, — это задача машин, которые предоставляют Domain Name Service (обслуживание доменных имен).

Как это происходит:

ваша машина должна знать IP адрес какого-то компьютере. Приложение, требующее эту информацию запрашивает ‘resolver’ на вашем Linux PC, чтобы предоставить эту информацию;
resolver делает запрос к локальному файлу хостов (/etc/hosts и/или серверу доменных имен, которые могут дать такую информацию (точнее поведение resolver’а определено в /etc/host.conf);
если ответ найден в файле хостов, то ответ возвращается;
если определен сервер доменных имен, то ваш PC делает запрос этой машине;
если DNS машина уже знает IP адрес для требуемого имени, то она возвращает его. Если нет, то делает запрос другим серверам доменных имен в Интернет, чтобы найти информацию. Сервер доменных имен затем послыает эту информацию обратно на запрашивающий resolver — который в свою очередь передает информацию запросившему приложению.

Когда вы устанавливаете PPP соединение, вы должны сообщить вашей Linux машине, где она может получить информацию по имени хоста по IP адресу (разрешение адреса) так, чтобы вы могли использовать имена машин, а ваш компьютер мог транслировать их в IP адреса, которые требуются для работы.

Один из способов состоит в том, чтобы прописать каждый хост, с которым вы хотите общаться в файл /etc/hosts (что нереально, если вы соединяетесь с Интернет); другой — использовать машинный IP адрес вместо имени (тоже невозможно, кроме самых маленьких LAN).

Самый лучший способ состоит в том, чтобы установить Linux так, чтобы он мог автоматически получить информацию об адресе по имени. Эту услугу предоставляет система сервера доменных имен (DNS). Все, что необходимо, это ввести IP адрес(а) серверов доменных имен в ваш файл /etc/resolv.conf .

Служба поддержки пользователей вашего PPP сервера должна обеспечить вас IP адресами DNS (необходим только один — но два адреса дают некоторую избыточность в случае отказа одного из них).

Как упоминалось выше, Linux не может устанавливать IP адрес сервера имен тем же способом, что и MS WINDOWS 95. Так что вы должны настоять (вежливо), чтобы ваш ISP обеспечил вас этой информацией!

Ваш /etc/resolv.conf должен выглядеть примерно так:

Отредактируйте этот файл (создайте в случае необходимости) так, чтобы прописать информацию, которую дал ваш ISP. Он должен иметь следующие права владения и доступа: Если вы уже настроили /etc/resolv.conf, потому что вы находитесь в LAN, просто добавьте IP адреса PPP DNS серверов к вашему существующему файлу.

Вы должны также проверить, что ваш файл /etc/host.conf правильно настроен. Он должен выглядеть примерно так

Эти строки сообщают resolver’у, что сперва надо искать информацию в файле хостов, а потом уже посылать DNS запросы. Next Previous Contents

Разрешение доменное имя в ip адрес

Изначально домены общего назначения предназначались для объединения доменов нижних уровней, принадлежащих организациям и учреждениям США. Поэтому в силу традиции большая часть доменов, зарегистрированных за организациями других государств, входят не в домены общего назначения, а в так называемые национальные домены. Однако ничто не мешает какой-нибудь компании, например, Российской, зарегистрировать домен второго уровня в домене «com». Исключением являются только домены «mil» и «gov», которые используются только учреждениями и организациями США.

Во вторую группу включены национальные домены (Country Code TLDs, ccTLDs). Имя каждого такого домена состоит из двух символов и представляет собой сокращение названия государства (так называемый «код страны»), которому принадлежит домен, например, «ru» означает Россия. Список национальных доменов разработан и утвержден Национальным Институтом Стандартов США (ISO 3166-1).

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

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

имя может состоять только из букв латинского алфавита, цифр и символа «-» (дефис);
длина имени не может превышать 63 символов.

Кроме того, доменные имена являются нечувствительными к регистру символов, входящих в его состав. Это означает, что последовательности символов «Com», «COM», «cOm», «com» и т.п. обозначают одно и тоже имя.

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

В процессе разрешения имен DNS участвуют три основных составляющих:

программа-клиент (resolver), которой требуется найти по доменному имени IP-адрес;
сервер имен (name server), или DNS-сервер, — программа, осуществляющая по запросу клиента поиск IP-адреса на основе предложенного доменного имени;
часть иерархического пространства имен DNS, обслуживаемая сервером имен и представленная в его локальной базе данных, называемая зоной ответственности (zone of authority).

Важным преимуществом DNS является то, что каждый конкретный сервер имен не должен содержать в своей локальной базе данных описание всей иерархии имен DNS. Как правило, организация, регистрирующая свое доменное имя, должна иметь DNS сервер, в базе данных которого представлено только пространство имен, принадлежащих ее домену. Например, если в домене «fio.ru» имеется только два узла — «www» и «center», то в базе данных сервера имен этого домена может присутствовать всего две записи для указанных имен. Кроме того, если домен содержит в себе домены нижних уровней, то каждый такой «субдомен» может иметь свой собственный сервер имен, освобождая тем самым от необходимости обслуживать свое подпространство имен DNS-сервер родительского домена. Таким образом, продолжая пример, сервер имен домена «ru» не имеет в своей базе данных информации об узлах «www» и «center» домена «fio.ru». Такая передача полномочий по управлению именами части зоны называется делегированием.

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

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

Разрешение доменное имя в ip адрес

4.3.3 Разрешение доменных имён

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

Различные типы именных серверов:

Локальный именной сервер — именной сервер, адрес которого сконфигурирован в рабочей станции. К этому серверу обращается клиент вначале с запросом на разрешение DNS-имени.
Корневой именной сервер (Root Name Server) — если же локальный сервер не знает ответ, то он выполняет итеративные запросы к корневому серверу и т. д. точно так же, как это делал клиент в первом варианте; получив ответ, он передает его клиенту, который все это время просто ждал его от своего локального DNS-сервера.
Авторитетный сервер имен (Authoritative Name Server) — сервер, администрирующий определённую зону пространства имён. Другие серверы могут получить копию пространсва имён зоны, но не могут в него вносить изменения.

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

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

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

Рисунок 4 ‑ 9 . DNS разрешение имени

Рисунок 4 ‑ 10 . Разрешение имён путём итераций запросов корневому серверу
(Источник: http://commons.wikimedia.org/wiki/File:Dns-wikipedia.gif)

Обработка запроса заканчивается с загрузкой результата в буфер имён клиентской машины. Сделанная запись в буфер имеет определённое время действия («срок годности») или TTL (Time to Live). Запись значения TTL устаревает с течением времени и, если запрос обрабатывается посредством нескольких DNS серверов, то каждый сервер заносит в буфер полученное значение записи TTL на момент занесения. Такой механизм обеспечивает то, что циркулирующая DNS запись соответствует действительному значению в зоне сервера. Ответ DNS сервера может быть и негативным, который также заносится в буфер клиента. В такой ситуации до того как сделать новый запрос надо локальный буфер имён обнулить (Windows’is ipconfig /flushdns).

Протокол TCP/IP, служба DNS

4.2 Служба DNS (домены, зоны; зоны прямого и обратного просмотра; основные и дополнительные зоны; рекурсивный и итеративный запросы на разрешение имен).

Историческая справка: Систему доменных имен разработал в 1983 году Пол Мокапетрис. Тогда же было проведено первое успешное тестирование DNS, ставшей позже одним из базовых компонентов сети Internet. С помощью DNS стало возможным реализовать масштабируемый распределенный механизм, устанавливающий соответствие между иерархическими именами сайтов и числовыми IP-адресами.

В 1983 году Пол Мокапетрис работал научным сотрудником института информатики (Information Sciences Institute, ISI ), входящего в состав инженерной школы университета Южной Калифорнии ( USC ). Его руководитель, Джон Постел, предложил Полу придумать новый механизм, устанавливающий связи между именами компьютеров и адресами Internet, — взамен использовавшемуся тогда централизованному каталогу имен и адресов хостов, который поддерживала калифорнийская компания SRI International.

«Все понимали, что старая схема не сможет работать вечно, — вспоминает Мокапетрис. — Рост Internet становился лавинообразным. К сети, возникшей на основе проекта ARPANET, инициированного Пентагоном, присоединялись все новые и новые компании и исследовательские институты».

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

«Как только организация подключалась к сети, она могла использовать сколь угодно много компьютеров и сама назначать им имена», — подчеркнул Мокапетрис. Названия доменов компаний получили суффикс .com , университетов — .edu и так далее.

Первоначально DNS была рассчитана на поддержку 50 млн. записей и допускала безопасное расширение до нескольких сотен миллионов записей. По оценкам Мокапетриса, сейчас насчитывается около 1 млрд. имен DNS, в том числе почти 20 млн. общедоступных имен. Остальные принадлежат системам, расположенным за межсетевыми экранами. Их имена неизвестны обычным Internet-пользователям.

Новая система внедрялась постепенно, в течение нескольких лет. В это время ряд исследователей экспериментировали с ее возможностями, а Мокапетрис занимался в ISI обслуживанием и поддержанием стабильной работы «корневого сервера», построенного на мэйнфреймах компании Digital Equipment. Копии таблиц хостов хранились на каждом компьютере, подключенном к Internet, еще примерно до 1986 года. Затем начался массовый переход на использование DNS.

Необходимость отображения имен сетевых узлов в IP-адреса

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

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

Использование локального файла hosts и системы доменных имен DNS для разрешения имен сетевых узлов

На начальном этапе развития сетей, когда количество узлов в каждой сети было небольшое, достаточно было на каждом компьютере хранить и поддерживать актуальное состояние простого текстового файла, в котором содержался список сетевых узлов данной сети. Список устроен очень просто — в каждой строке текстового файла содержится пара «IP-адрес — имя сетевого узла». В системах семейства Windows данный файл расположен в папке %system root%system32driversetc (где %system root% обозначает папку, в которой установлена операционная система). Сразу после установки системы Windows создается файл hosts с одной записью 127.0.0.1 localhost .

С ростом сетей поддерживать актуальность и точность информации в файле hosts становится все труднее. Для этого надо постоянно обновлять содержимое этого файла на всех узлах сети. Кроме того, такая простая технология не позволяет организовать пространство имен в какую-либо структуру. Поэтому появилась необходимость в централизованной базе данных имен, позволяющей производить преобразование имен в IP-адреса без хранения списка соответствия на каждом компьютере. Такой базой стала DNS (Domain Name System) — система именования доменов, которая начала массовую работу в 1987 году.

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

Служба DNS: пространство имен, домены

DNS — это иерархическая база данных , сопоставляющая имена сетевых узлов и их сетевых служб IP-адресам узлов. Содержимое этой базы, с одной стороны, распределено по большому количеству серверов службы DNS, а с другой стороны, является централизованно управляемым. В основе иерархической структуры базы данных DNS лежит доменное пространство имен (domain namespace), основной структурной единицей которого является домен, объединяющий сетевые узлы (хосты), а также поддомены. Процесс поиска в БД службы DNS имени некоего сетевого узла и сопоставления этому имени IP-адреса называется «разрешением имени узла в пространстве имен DNS».

Служба DNS состоит из трех основных компонент:

Пространство имен DNS и соответствующие ресурсные записи (RR, resource record) — это сама распределенная база данных DNS;
Серверы имен DNS — компьютеры, хранящие базу данных DNS и отвечающие на запросы DNS-клиентов;
DNS-клиенты (DNS-clients, DNS-resolvers) -компьютеры, посылающие запросы серверам DNS для получения ресурсных записей.

Пространство имен DNS — иерархическая древовидная структура, начинающаяся с корня, не имеющего имени и обозначаемого точкой «.». Схему построения пространства имен DNS лучше всего проиллюстрировать на примере сети Интернет (рис. 4.8).

Для доменов 1-го уровня различают 3 категории имен:

Разрешение доменное имя в ip адрес

Вопрос

Проблема следующего рарактера

Имеется сервер 2012 с установленным Exchange 2013. также 2 контролера домена 2012 и 2008R2 на обеих DNS

ping IP все нормально

ping Comp не находит

ping Comp.domain.loc тоже не находит

nslookup Comp все четка

nslookup Comp.domain.loc тоже все нормально

nslookup IP тоже без проблем

В DNS-е все записи есть прямая и обратная не пойму вчем проблема может кто поможет !

Ответы

Скорее всего проблема в Primary DNS Suffix.

Без ipconfig /all действительно трудно что-то диагностировать.

Microsoft Certified Do Nothing Expert

Помечено в качестве ответа Sancho-paso 14 марта 2013 г. 8:19

Все ответы

Фразы «все четка» и «не находит» малоинформативны. Выложите результаты работы команд:

Изменено Daemon-GTC 7 марта 2013 г. 4:47

Скорее всего проблема в Primary DNS Suffix.

Без ipconfig /all действительно трудно что-то диагностировать.

Microsoft Certified Do Nothing Expert

Помечено в качестве ответа Sancho-paso 14 марта 2013 г. 8:19

Настройка протокола IP для Windows

Имя компьютера . . . . . . . . . : SA52-PC
Основной DNS-суффикс . . . . . . : ksc-rostov.loc
Тип узла. . . . . . . . . . . . . : Гибридный
IP-маршрутизация включена . . . . : Нет
WINS-прокси включен . . . . . . . : Нет
Порядок просмотра суффиксов DNS . : ksc-rostov.loc

Ethernet adapter Подключение по локальной сети:

DNS-суффикс подключения . . . . . : ksc-rostov.loc
Описание. . . . . . . . . . . . . : Atheros AR8151 PCI-E Gigabit Ethernet Con
troller (NDIS 6.20)
Физический адрес. . . . . . . . . : C8-60-00-56-E5-D8
DHCP включен. . . . . . . . . . . : Да
Автонастройка включена. . . . . . : Да
Локальный IPv6-адрес канала . . . : fe80::5414:3784:e518:a6c0%11(Основной)
IPv4-адрес. . . . . . . . . . . . : 192.168.220.105(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Аренда получена. . . . . . . . . . : 11 марта 2013 г. 17:36:34
Срок аренды истекает. . . . . . . . . . : 19 марта 2013 г. 17:37:40
Основной шлюз. . . . . . . . . : 192.168.220.3
DHCP-сервер. . . . . . . . . . . : 192.168.220.2
IAID DHCPv6 . . . . . . . . . . . : 248012800
DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-18-B9-40-54-C8-60-00-56-E5-D8

DNS-серверы. . . . . . . . . . . : 192.168.220.220
192.168.220.2
80.254.111.254
NetBios через TCP/IP. . . . . . . . : Включен

0 0 голоса

Рейтинг статьи

Читать еще: Процессы перемагничивания ферромагнетика домены