Какработает DNS

Обратный поиск

После обнаружения IP-адреса, принадлежащего хосту, иногда желательно
выяснить каноническое имя хоста, соответствующее данному адресу. Это
называется reverse mapping (обратное отображение) и
используется несколькими сервисами, чтобы проверить идентичность клиента. При
использовании файла , обратный поиск
заключается просто в проверке этого файла. В DNS, конечно, не проводится
просмотр всего адресного пространсва. Вместо этого создана специальная
область in-addr.arpa, она содержит IP-адреса
всех хостов в перевернутой записи. Например, IP-адрес
149.76.12.4 соответствует имени
4.12.76.149.in-addr.arpa. Тип записи ресурса,
связывающий это имя с каноническим именем, называется PTR.

Создание зоны полномочий обычно означает, что ее администраторам дают
полный контроль над тем, как назначать адреса и имена хостов. Так как они
обычно управляют одной или более IP-сетями или подсетями, одна зона DNS может
охватывать несколько IP-сетей. Отдел физики, например, включает подсети
149.76.8.0,
149.76.12.0 и 149.76.14.0.

Как следствие, новые зоны должны быть записаны в
in-addr.arpa домена: 8.76.149.in-addr.arpa
, 12.76.149.in-addr.arpa и
14.76.149.in-addr.arpa. Иначе, установка
нового хоста в лаборатории Collider требовала бы обращения к родительской
области, чтобы отметиться в ее файле in-addr.arpa
. Зональная база данных для подсети 12 показана в
.
Соответствующие склеенные записи в базе данных зоны родителя показаны в
.

Пример 6-6. Выдержка из файла named.rev для подсети 12

 ; the 12.76.149.in-addr.arpa domain.
 @  IN  SOA  niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
                      1999090200 360000 3600 3600000 3600
            }
 2        IN     PTR       otto.physics.groucho.edu.
 4        IN     PTR       quark.physics.groucho.edu.
 5        IN     PTR       down.physics.groucho.edu.
 6        IN     PTR       strange.physics.groucho.edu.

Пример 6-7. Выдержка из файла named.rev для сети 149.76

 ; the 76.149.in-addr.arpa domain.
 @  IN  SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
                      1999070100 360000 3600 3600000 3600
                  }
 ...
 ; subnet 4: Mathematics Dept.
 1.4        IN     PTR      sophus.maths.groucho.edu.
 17.4       IN     PTR      erdos.maths.groucho.edu.
 23.4       IN     PTR      gauss.maths.groucho.edu.
 ...
 ; subnet 12: Physics Dept, separate zone
 12         IN     NS       niels.physics.groucho.edu.
            IN     NS       gauss.maths.groucho.edu.
 niels.physics.groucho.edu. IN  A 149.76.12.1
 gauss.maths.groucho.edu. IN  A   149.76.4.23
 ...

Одно важное следствие этого то, что зоны могут создаваться только как
наборы IP-сетей и даже более того, количество нулевых битов в маске подсети
должно быть кратно 8. Все подсети в университете Groucho Marx имеют сетевую
маску 255.255.255.0, так что зона
in-addr.arpa может быть создана для каждой
подсети

Однако, если сетевая маска будет
255.255.255.128, создание зон для подсети
149.76.12.128 будет невозможно, потому что нет никакого способа
сообщить DNS, что область 12.76.149.in-addr.arpa
была раздроблена на две зоны с именами хостов от
1 до 127 и от
128 до 255
соответственно.

HINFO информация о хосте

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

Поле обозначает доменное имя хоста,
— аппаратную платформу, —
ОС хоста. Значения полей и
стандартизированы, их следует брать из RFC
1700.

ПРИМЕР ЗАПИСИ HINFO

[][][]HINFO

pc1HINFOIBM-PCMSDOS
rs1HINFOIBM-RS/6000AIX

MX (почтовый шлюз)

В примере показано, что если почта
предназначена для домена komtek.dp.ua, то она
доставляется на машину unix1.komtek.dp.ua. Если же
почта предназначена для любого компьютера
домена, имя которого оканчивается на -dos, то
она направляется на unix2.komtek.dp.ua.

ПРИМЕР ЗАПИСИ MX

[][][]MX 

komtek.dp.ua.MX10unix1.komtek.dp.ua.
*-dos.komtek.dp.ua.MX10unix2.komtek.dp.ua.

Таким образом, письмо, отправленное по
адресу:

1. alex@komtek.dp.ua, переадресуется alex@unix1.komtek.dp.ua;
2. vad@pc-dos.komtek.dp.ua, переадресуется vad@unix2.komtek.dp.ua;
3. dba@host1.komtek.dp.ua, попадет к dba@host1.komtek.dp.ua.

Если администратор определяет несколько
записей MX, то для указания порядка опроса
почтовых шлюзов используется число (в
примере — 10) первым опрашивается шлюз с
меньшим числом.

PTR (указатель)

Прежде чем рассматривать записи с
ресурсом типа PTR, следует остановиться на
поиске доменного имени хоста по его IP-адресу
(так называемое обратное преобразование).

Структура имен в доменной системе
построена так, что, продвигаясь вдоль
иерархического дерева DNS, за счет
последовательного обращения к серверам
имен IP-адрес хоста можно найти по его имени (прямое
преобразование). А вот доменное имя хоста по
его IP-адресу в такой системе найти довольно
трудно.

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

Например, сеть cso.uiuc.edu имеет сетевой адрес
128.174 (вернее, 128.174.0.0, это IP-сеть класса B).
Внутри этой сети имеется хост vmd.cso.uiuc.edu с IP-адресом
128.174.5.98. Тогда для всей сети вспомогательный
домен будет 174.128.in-addr.arpa. Имя хоста в этом
домене будет 98.5.174.128.in-addr.arpa.

Ресурсы с записью типа PTR служат для
отображения этих специальных доменных имен
в обычные. Поле обозначает
специальное доменное имя (в домене IN-ADDR.ARPA),
а поле — официальное доменное имя
хоста.

ПРИМЕР ЗАПИСИ PTR ДЛЯ ХОСТА

[][][]PTR

98.5.174.128.in-addr.arpa.PTRvmd.cso.uiuc.edu.
51.0.0.10.in-addr.arpa.PTRsri-nic.arpa.

Вспомогательный домен IN-ADDR.ARPA
используется также для указания шлюза (маршрутизатора)
для сетей. Шлюз представляет собой хост,
соединяющий несколько IP-сетей. Для него
существуют обычные записи PTR хоста, но,
кроме того, имеются специальные записи PTR,
представляющие IP-сети целиком. Эти записи
включают только первые 1, 2 или 3 байта (октета)
IP-адреса сети в зависимости от класса IP-сети
(A, B или C).

Допустим, имеется шлюз gw.komtek.dp.ua,
объединяющий сети класса A, B и C и имеющий
соответствующие IP-адреса: 12.2.0.7, 129.14.1.3 и
194.140.13.2. Ниже представлены записи A и PTR для
данного шлюза.

ПРИМЕР ЗАПИСЕЙ PTR И A ДЛЯ ШЛЮЗА

;Записи A
gw.komtek.dp.ua.A192.168.1.7
A192.168.2.3A194.140.13.2
; Записи PTR для шлюза 
7.1.168.192.in-addr.arpa.PTRgw.komtek.dp.ua.
3.2.168.192.in-addr.arpa.PTRgw.komtek.dp.ua.
2.13.140.194.in-addr.arpa.PTRgw.komtek.dp.ua.
; Записи PTR для сетей
1.1.168.192.in-addr.arpa.PTRgw.komtek.dp.ua.
2.168.192.in-addr.arpa.PTRgw.komtek.dp.ua.
13.140.194.in-addr.arpa.PTRgw.komtek.dp.ua.

Зачем нужны DNS-сервера и что это такое

Когда интернет только формировался, то было решено внедрить такую вещь, как домены. Фактически, это имя для узла сети (компьютера, сервера или в более общем смысле слова — хоста).

Дело в том, что на технологическом уровне все устройства в любой сети уже имеют уникальные имена (идентификаторы или IP), но они мало подходят для использования их людьми, ибо представляют из себя набор цифр (читайте про то, что такое АйПи и MAC адреса).

Система же доменных имен оперирует уже полноценными именами (буквы латиницы, цифры, тире и нижнее подчеркивание допускается при их формировании). Их гораздо легче запомнить, они несут смысловую нагрузку (доменное имя моего блога ktonanovenkogo.ru о чем-то уже говорит, а реальный его АйПи 109.120.169.66 малоинформативен) и ими проще оперировать.

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

Вот именно на этих ДНС-серверах (иногда их еще называют NS от Name Server, т.е server имен) и держится весь интернет (как плоский мир на трех китах, стоящих на черепахе). Сервер, если вы помните, это просто служебный компьютер не требующий непосредственного участия человека в своей работе (настроили его — он и пашет в режиме 24 на 7). И таких DNS-серверов в сети очень много.

Как работает DNS и причем тут файл Hosts?

На заре интернета ДНС вообще не существовало. Но как же тогда работала сеть? Как браузер понимал, что ktonanovenkogo.ru — это то же самое, что IP адрес 109.120.169.66? За это дело тогда (да и сейчас тоже) отвечал так называемый файл Hosts, где были прописаны все хосты тогда еще маленького интернета.

Такой файл находился (и сейчас находится) на каждом компьютере пользователя (на вашем тоже он есть) подключенного к сети (как его найти смотрите по приведенной выше ссылке).

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

109.120.169.66 ktonanovenkogo.ru

Любой браузер (что это такое?) на любом компьютере (даже сейчас) при вводе в адресную строку УРЛа (что это такое?) прежде всего обращается к файлу Hosts на предмет поиска там введенного доменного имени, и лишь не найдя там нужной записи обращается за этой информацией к ближайшему DNS-серверу (как правило, это сервак вашего интернет-провайдера).

Сейчас файл Hosts стал рудиментом (пережитком прошлого) и там обычно есть только одна запись (127.0.0.1 localhost) означающая, что локальным хостом нужно считать данный компьютер.

Правда иногда его используют вирусы и другие зловреды, чтобы вместо одного сайта вы попадали на другой (про фишинг слышали?) — ведь для этого достаточно добавить всего одну строчку в файл Hosts (можете сами прописать в нем, например, «109.120.169.66 yandex.ru» и вместо Яндекса браузер вам будет упорно открывать мой блог). Вот именно поэтому его целостность охраняют большинство антивирусов.

Динамическая система DNS

В прошлом сложность работы с DNS состояла в том, что вся зонная информация должна была вводиться вручную. До выхода документа RFC 2136 не существовало никакого способа автоматического обновления зонной информации DNS-сервера. В документе RFC 2136 описано, как DNS-серверы должны быть сконфигурированы, чтобы автоматически принимать обновления к записям ресурсов в зонных файлах. Эта опция называется динамической службой DNS (DDNS).
DNS-серверы Windows Server 2003 поддерживают динамическую службу DNS. По умолчанию все клиенты Windows 2000 и Windows XP Professional, а также Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition автоматически обновляют свои записи ресурсов в DNS. Windows 2000 и контроллеры домена Windows Server 2003 автоматически регистрируют SRV-записи на DNS-серверах, которые используются для поиска контроллеров домена. DNS-серверы Windows Server 2003 будут
также принимать динамическую регистрацию записей с серверов динамической конфигурации хостов (DHCP). DHCP-сервер Windows Server 2003 может конфигурироваться для автоматического обновления DNS-записей для любого из его клиентов, включая Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Me или Microsoft Windows NT.

Одна из проблем динамической системы DNS связана с безопасностью. Без какого-либо контроля над тем, кому позволено обновлять записи ресурсов DNS, любой, имеющий доступ к вашей сети, потенциально может создать запись ресурса в ваших зонных файлах DNS, а затем использовать эту запись для переадресации сетевого трафика. Чтобы решить эту проблему в системе DNS Windows Server 2003 существуют безопасные обновления. Безопасные обновления имеются только в интегрированных зонах Active Directory. С помощью безопасных обновлений вы можете управлять тем, кому дается право регистрировать и обновлять DNS-записи. По умолчанию члены группы Authenticated Users (Уполномоченные пользователи) имеют право обновлять свои записи в системе DNS. Вы можете изменить это, изменяя список управления доступом ACL (ACL — Access Control List) для DNS-зоны.
Динамическая система DNS уменьшает объем работы, который должен делать администратор DNS. Далее вы узнаете, что Active Directory Windows Server 2003 требует присутствия SRV-записи каждого контроллера домена в зонной информации, поэтому поддержка динамических обновлений является важным свойством DNS-системы Windows Server 2003.

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

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

Делегированные зоны

Поскольку система DNS использует иерархическое пространство имен, должен существовать механизм соединения разных уровней иерархии. Например, если клиент соединяется с сервером, который является полномочным для домена первого уровня сот, и запрашивает сервер в домене Contoso.com, corn-сервер должен уметь определять, какой сервер имен является полномочным для домена Contoso.com. Это возможно при помощи записей делегирования (delegation records).
Запись делегирования представляет собой указатель на домен низшего уровня, который идентифицирует сервер имен для домена низшего уровня. Например, на рисунке 3-4 показано, что DNSl.Contoso.com является полномочным сервером имен для домена Contoso.com. DNS2 и DNS3 являются полномочными серверами имен для домена NAmerica.Contoso.com. Сервер DNS1 считается полномочным для домена NAmerica.Contoso.com, но он не имеет всех записей ресурса дочерних доменов. Однако сервер DNS1 использует запись делегирования, указывающую на DNS2 и DNS3 как на серверы имен для дочернего домена. Когда клиент соединяется с сервером DNS1, запрашивая информацию об NAmerica.Contoso.com, сервер перешлет клиента на сервера имен дочернего домена.

Процесс разрешения имен

Иерархическое пространство имен DNS и распределенная база данных используются тогда, когда клиент пробует найти IP-адрес ресурса в интернете. Используя пример из предыдущего раздела (см. рис. 3-1), предположим, что клиент DNS (назовем его преобразователем), расположенный в какой-то точке земного шара, хочет соединиться с веб-сервером, имеющим адрес www.NAmerica.Contoso.com. Для получения IP-адреса выполняются следующие действия.

1. Клиент-преобразователь посылает рекурсивный запрос об IP-адресе на свой сконфигурированный DNS-сервер (обычно это DNS-сервер провайдера службы интернета). Рекурсивный запрос может иметь только два возможных ответа: IP-адрес, запрашиваемый клиентом, или сообщение об ошибках, указывающее, что информация не может быть найдена.
2. Если DNS-сервер провайдера имеет необходимую информацию в своем кэше, то он возвращает IP-адрес пользователю. Если нужной информации нет, то он пробует найти информацию, посылая итерационный запрос на другой сервер. Ответом на итерационный запрос может быть или разрешенное имя, запрашиваемое клиентом, или переадресация на другой DNS-сервер, который сможет выполнить запрос. В нашем примере DNS-сервер провайдера посылает итерационный запрос корневому серверу об IP-адресе, который соответствует www.NAmerica.Contoso.com.
3. Корневой сервер не может ответить на запрос, но в ответ он присылает список серверов, ответственных за домен высшего уровня сот. Этот процесс предоставления списка альтернативных DNS-серверов для дальнейшего контакта называется направлением (referral). DNS-сервер интернет-провайдера посылает итерационный запрос одному из этих серверов с просьбой об IP-адресе.
4. Сервер сот дает в ответ список серверов, которые являются ответственными за домен Contoso.com. Далее DNS-сервер провайдера посылает запрос DNS-серверу Contoso.com, который дает в ответ имена DNS-серверов, управляющих доменом NAmerica.Contoso.com.
5. DNS-сервер NAmerica.Contoso.com содержит всю информацию об этом домене, и он посылает DNS-серверу провайдера IP-адрес нужного хоста.
6. DNS-сервер провайдера отвечает на рекурсивный запрос, который он получил от клиента-преобразователя, и посылает IP-адрес запрошенного Web-сервера.
7. Компьютер клиента соединяется с www.NAmerica.Contoso.com.
8. Этот процесс происходит очень быстро и может не включать некоторые шаги. Когда DNS-сервер разрешает любой тип имени, он сохраняет эту информацию в кэше в течение определенного периода. Если кто-то искал этот же сайт раньше в этот день и DNS-сервер провайдера разрешил это имя, то он просмотрит свой кэш и даст ответ немедленно.

Формат DNS-сообщений

Рис. 4.4.12.3. Формат DNS-сообщений

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

Рис. 4.4.12.4. Назначение битов поля флаги.

Таблица 4.4.12.2. Коды поля флаги

Типы записей DNS и их создание

Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Например, запрос A-записи на имяreferrals.icann.org вернет его IP адрес —192.0.34.164

Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернет его IPv6 адрес — 2001:7fd::1

Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя

Запись MX (mail exchange) или почтовый обменник указывает сервер обмена почтой для данного домена.

Запись NS (name server) указывает на DNS-сервер для данного домена.

Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в reverse форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например, (на момент написания), для IP адреса192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

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

SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.

SRV-запись — стандарт в DNS, определяющий местоположение, то есть имя хоста и номер порта серверов для определенных служб. Определяется в RFC 2782.

Создание записи типа “SRV”

1) В DNS можно создать запись “SRV” Для этого нужно выбрать пункт меню “Другие новые записи”

2) В появившемся списке нужно найти запись типа SRV.

3) Заполнить необходимые поля, такие как (Служба для которой создается SRV-запись, Протокол, Приоритет, Вес и Порт), а так же нужно указать узел службы.

Домен — доменное имя, для которого эта запись действует.

Служба — указывается символьное имя службы.

Протокол — транспортный протокол используемый сервисом, как правило TCP или UDP.

Приоритет — приоритет целевого хоста, более низкое значение означает более предпочтительный.

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

Порт — Порт TCP или UDP, на котором работает сервис.

Узел этой службы — канонические имя машины, предоставляющей сервис.

Запись SRV — Позволяет администраторам использовать несколько серверов для одного домена DNS, просто перенося службу TCP/IP с одного узла администрирования на другой, и назначать некоторые узлы-поставщики служб в качестве основных серверов служб, а другие узлы — в качестве вспомогательных или архивных.

DNS-клиенты, используя SRV-запросы, обращаются за определенной службой TCP/IP и протоколом, направляются на определенный домен DNS и получают имена всех доступных серверов. RFC 2052

Создание записи типа “А” или “AAAA”

1) В DNS создается запись узла, тип записи “A”. IPv4

В которой определяется соответствие имени и IP адреса.

Видео демонстрация создания записи “A” для IPv4.

Запись типа “АААА” — это тоже самое, что и запись типа “А” только для IPv6 .

Как работает сеть

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

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

Файл hosts

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

Замена Ip в файле hosts

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

Зачем в интернете нужны DNS-серверы

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

Каждую точку подключения (клиентский компьютер) идентифицировали в сети при помощи IP-адреса. Что расшифровывается как Internet Protocol Address – адрес интернет-протокола.

IP-адрес выглядит примерно, как номер сотового телефона:

• 59.109.189
• 59.110.48
• 59.109.207

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

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

По-английски Domain Name System или сокращенно DNS.

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

• Сервера доменных имен верхнего уровня – COM, RU и так далее.
• Сервера со списками доменных имен второго уровня – google.com.
• Сервера доменов третьего уровня – api.google.com.

Самую верхнюю позицию в иерархии занимают корневые DNS-сервера, на которых хранятся списки серверов доменных имен верхнего уровня. Корневых ДНС-серверов во всем мире чуть более 10 штук.

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

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

И вот таким образом поиск IP-адреса по заданному браузером доменному имени происходит до тех пор, пока нужный сайт не будет обнаружен на одном из ответственных за его хранение серверов DNS.

Пример работы, как браузер находит сайт

Чтобы понять, как все это работает, давайте рассмотрим на конкретном примере поиска какого-либо сайта.

Такой достаточно сложный алгоритм поиска IP адреса сайта по доменному имени получается потому, что сегодня интернет-ресурсов во всемирной сети уже более миллиарда.

Hosts-файл

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

Это обычный текстовый файл, но не имеющий расширения txt. Дело в том, что Hosts-файлы могут присутствовать на компьютерах и других операционных систем, а не только Windows.

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

Hosts-файл содержит список сопоставления доменных имен известных пользователю интернет-ресурсов и их IP-адресов.

127.0.0.1 localhost

Сначала прописывается IP-адрес, а затем название интернет-ресурса.

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

Указанная выше запись из Hosts-файла означает, что по такому IP адресу находится сам пользовательский компьютер. В большинстве случаев на современных персональных компьютерах эта запись является единственной.

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

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

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

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

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

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