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

Идея работы списка рассылки состоит в том, что существует некий адрес электронной почты, который на самом деле является общим адресом многих людей - подписчиков этого списка рассылки. Вы посылаете письмо на этот адрес, например на адрес [email protected] (это адрес списка рассылки, посвященного обсуждению проблем локализации операционных систем класса UNIX), и Ваше сообщение получат все люди, подписанные на этот список рассылки.

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

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

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

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

Введение

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

ИСТОРИЯ

Доменная система имен была изобретена Полом Макпэтрисом по просьбе Джона Постэла в 1983 году, он же и выполнил первую ее реализацию. В 1984 году 4 студента из Беркли – Дуглас Тэрри, Марк Пэинтер, Дэвид Риггл и Содни Зу написали первую UNIX реализацию, которую они назвали Интернет Сервер Доменных Имен Беркли (Berkeley Internet Name Domain Server или сокращенно BIND). В 1985 году код этой реализации был существенно переписан Кевином Данлэпом, а в 1990 она была портирована на Windows NT. На данный момент BIND является самым используемым DNS сервером в мире.

Основные понятия Domain Name System

Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов.

«Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечают за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на сайте корневых серверов .

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

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

Каждый узел в иерархии DNS отделен от своего родителя точкой. Доменное имя начинается с точки (корневого домена ) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.е. доменное имя полностью отражаетструктуру иерархии DNS . Последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не site.nam e. , а site.name ).

Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN .

FQDN (англ. Fully Qualifed Domain Name , полностью определённое имя домена) - это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого . Своеобразный аналог абсолютного пути в файловой системе.

Давайте разберем вышесказанное на примере имени домена www.mydomain.com:

Максимальный размер FQDN - 255 байт, с ограничением в 63 байта на каждое имя домена.

Еще есть т.н. зарезервированные доменные имена, определенные в RFC 2606 (Reserved Top Level DNS Names - зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. К таким именам относятся например example.com, example.org и example.net, а также test, invalid и др.

Принципы работы DNS

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

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

Данная схема является наиболее распространенной в сети и выглядит следующим образом:

• Шаг 1. Браузер ищет IP-адрес домена в локальном кеше и если он не найден, обращается к местному серверу доменных имен (сервер провайдера интернета) за IP- адресом, сообщая ему доменное имя.
• Шаг 2. Сервер провайдера определяет, что адрес не входит в данный домен и обращается за адресом сервера запрашиваемого домена к корневому серверу доменных имен.
• Шаг 3. Корневой сервер доменных имен сообщает местному серверу доменных имен адрес сервера доменных имен требуемого домена.
• Шаг 4. Местный сервер доменных имен запрашивает удаленный сервер на предмет разрешения запроса своего клиента (браузера).
• Шаг 5. Удаленный сервер сообщает IP-адрес местному серверу.
• Шаг 6. Местный сервер сообщает IP-адрес браузеру.
• Шаг 7. Браузер обращается по полученному IP-адресу на хостинг-сервер сайта.
• Шаг 8. Хостинг-сервер отдает сгенерированные по запросу данные.

Вот как происходит определение IP-адреса test-site.ru:

Loading root server list (static data): -> a.root-servers.net (198.41.0.4) -> b.root-servers.net (192.228.79.201) -> c.root-servers.net (192.33.4.12) -> d.root-servers.net (128.8.10.90) -> e.root-servers.net (192.203.230.10) -> f.root-servers.net (192.5.5.241) -> g.root-servers.net (192.112.36.4) -> h.root-servers.net (128.63.2.53) -> i.root-servers.net (192.36.148.17) -> j.root-servers.net (192.58.128.30) -> k.root-servers.net (193.0.14.129) -> l.root-servers.net (199.7.83.42) -> m.root-servers.net (202.12.27.33) Sending request to "f.root-servers.net" (192.5.5.241) Received referral response - DNS servers for "ru": -> e.dns.ripn.net (193.232.142.17) -> d.dns.ripn.net (194.190.124.17) -> a.dns.ripn.net (193.232.128.6) -> b.dns.ripn.net (194.85.252.62) -> f.dns.ripn.net (193.232.156.17) Sending request to "f.dns.ripn.net" (193.232.156.17) Received referral response - DNS servers for "test-site.ru": -> ns2.test-site.ru (5.9.195.91) -> ns1.test-site.ru (5.9.195.90) Sending request to "ns2.test-site.ru" (5.9.195.91) Timeout waiting for response Sending request to "ns1.test-site.ru" (5.9.195.90) Received authoritative (AA) response: -> Answer: A-record for test-site.ru = 5.9.195.90 -> Authority: NS-record for test-site.ru = ns1.test-site.ru -> Authority: NS-record for test-site.ru = ns2.test-site.ru -> Additional: A-record for ns1.test-site.ru = 5.9.195.90 -> Additional: A-record for ns2.test-site.ru = 5.9.195.91

Хранение информации на DNS-серверах

На DNS-серверах информация хранится в виде ресурсных записей.

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

Запись ресурса состоит из следующих полей:

• имя (NAME) - доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.
• Time To Live (TTL) - дословно «время жизни» записи, время хранения записи в кэше DNS (после указанного времени запись удаляется), данное поле может не указываться в индивидуальных записях ресурсов, но тогда оно должно быть указано в начале файла зоны и будет наследоваться всеми записями.
• класс (CLASS) - определяет тип сети, (в 99,99% случаях используется IN (что обозначает - Internet). Данное поле было создано из предположения, что DNS может работать и в других типах сетей, кроме TCP/IP)
• тип (TYPE) - тип записи, синтаксис и назначение записи
• данные (DATA) - различная информация, формат и синтаксис которой определяется типом.

При этом, возможно использовать следующие символы:

• ; - Вводит комментарий
• · # - Также вводит комментарии (только в версии BIND 4.9)
• @ - Имя текущего домена
• () - Позволяют данным занимать несколько строк
• * - Метасимвол (только в поле имя)

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

• A - (address record/запись адреса ) отображают имя хоста (доменное имя) на адрес IPv4. Для каждого сетевого интерфейса машины должна быть сделана одна A-запись .

  Пример : test-site.ru. A. 5.9.195.90. IN. 3600.

• MX (mail exchange ) - указывает хосты для доставки почты, адресованной домену. При этом поле NAME указывает домен назначения, поля TTL, CLASS- стандартное значение, поле TYPE принимает значение MX, а поле DATA указывает приоритети через пробел - доменное имя хоста, ответственного за прием почты.

  Пример :

  test-site.ru. MX. 10. mx.yandex.ru. IN. 3600.

  NAME	TTL	CLASS	TYPE	DATA
  MX.YANDEX.RU	3600	IN	MX	10

• NS (name server/сервер имён ) указывает на DNS-сервер, обслуживающий данный домен. Вернее будет сказать - указывают сервера, на которые делегирован данный домен. Если записи NS относятся к серверам имен для текущей зоны, доменная система имен их практически не использует. Они просто поясняют, как организована зона и какие машины играют ключевую роль в обеспечении сервиса имен.

  Пример :

  test-site.ru. NS. ns1.test-site.ru. IN. 3600.
  test-site.ru. NS. ns2.test-site.ru. IN. 3600.

  NAME	TTL	CLASS	TYPE	DATA
  TEST-SITE.RU.	3600	IN	NS	NS1.TEST-SITE.RU
  TEST-SITE.RU.	3600	IN	NS	NS2.TEST-SITE.RU

• PTR (pointer ) - Записи PTR связывают IP-адрес с именем хоста в домене обратного поиска (in-addr.arpa). Запись содержит IP-адрес и имя хоста, соответствующее этому адресу. Имя хоста задается в формате полностью определенного доменного имени. Многие сайты в качестве меры безопасности запрещают доступ со стороны компьютеров, у которых существуют расхождения между записями А и PTR, поэтому следите за тем, чтобы содержимое записей PTR синхронизировалось с записями А.
• SOA (Start of Authority/начальная запись зоны ) - описывает основные/начальные настройки зоны, можно сказать,определяет зону ответственности данного сервера. Для каждой зоны должна существовать только одна запись SOA и она должна быть первая.Поле NAME содержит имя домена/зоны, поля TTL, CLASS - стандартное значение, поле TYPE принимает значение SOA, а поле DATA состоит из нескольких значений, разделенных пробелами:

  - имя главного DNS (Primary Name Server)

  - адрес администратора зоны

  Далее - серийный номер файла зоны (Serial number ) . При каждом внесении изменений в файл зоны данное значение необходимо увеличивать, это указывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону.

  Далее - значения таймеров (Refresh - указывает, как часто вторичные серверы должны опрашивать первичный, чтобы узнать, не увеличился ли серийный номер зоны, Retry - время ожидания после неудачной попытки опроса, Expire - максимальное время, в течение которого вторичный сервер может использовать информацию о полученной зоне, Minimum TTL - минимальное время, в течение которого данные остаются в кэше вторичного сервера).

  Пример :

  test-site.ru. SOA. test-site.ru. root.test-site.ru. 2013112923. 10800. 3600. 604800. 86400. IN. 3600.

  NAME	TTL	CLASS	TYPE	DATA (в соответствии с порядком выше)
  TEST-SITE.RU.		IN	SOA	test-site.ru	root.test-site.ru	2013112923	10800.3600.604800.86400
  				test-site.ru. root.test-site.ru. 2013112923. 10800. 3600. 604800. 86400

• SRV (server selection ) - указывают на сервера, обеспечивающие работу тех или иных служб в данном домене (например Jabber и Active Directory).

Делегирование доменов

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

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

Делегирование домена производится при помощи изменения NS – записей домена, в которых указывается адрес DNS-сервера, который принадлежит третьему лицу и отвечает за поддержание доменной зоны. Диапазоны IP-адресов делегируются с помощью доменной зоны in-addr.arpa.

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

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

Регистрация доменных имен

В двух словах хотел бы затронуть вопросрегистрации доменных имен .

Регистрация доменов - это действие, посредством которого клиент сообщает регистратору, каким DNS-серверам следует делегировать поддомен, и также снабжает регистратора контактной и платежной информацией. Регистратор передает информацию в соответствующий реестр. Чаще всего, это процесс внесения в реестр зоны первого уровня (то есть в TLD зоны ru, com или др.), записи о новом доменном подимени.

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

Уровни доменов, для которых необходима обязательная регистрация лица, ответственного за домен, следующие:

• корневой домен
• все домены первого уровня (TLD)
• некоторые домены второго уровня (например, com.ru или co.uk)

Регистратором для корневого домена является организация ICANN . Чтобы стать регистратором доменов в зонах второго уровня (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs ...), необходимо получить аккредитацию ICANN.

Ссылки:

https://www.nic.ru/whois/ - проверка доменов (основные сведения)

http://www.cy-pr.com/tools/dns/ - расширенные сведения по ДНС

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

Опытные вебмастеры призывают верить в специализацию и опираться на принцип «мухи отдельно, котлеты отдельно». Хостинг нужно покупать у тех компаний, для которых его продажа – основная цель, а домены – у официальных регистраторов или реселлеров. К счастью, в процедуре делегирования имени сайта нет ничего сложного. Достаточно всего один раз разобраться, как привязать домен к хостингу – затем эта работа будет выполняться «на автомате».

Что значит делегировать домен?

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

Проверить, привязано ли имя, довольно легко. Можно задействовать сервис от официального регистратора доменов REG.RU . Необходимо пройти по этой ссылке https://www.reg.ru/whois/ и прописать интересующее сочетание в строке. Мы хотим проанализировать домен lubanyaiashina.ru .

Нажимаем «Проверить ». Сервис сообщает нам, что домен куплен, а также предоставляет полную информацию о нём: какая компания его продала, когда закончится его регистрация и когда она была произведена.

Чуть ниже самого адреса видна отметка «домен не делегирован». Это значит, что привязка к хостингу ещё не осуществлялась.

Как делегировать домен на хостинг?

Имя, которое мы анализировали, зарегистрировано организацией «Nethouse.Домены ». Поэтому на примере именно этого продавца мы и будем рассматривать, как привязать домен к хостингу. Если вы пользуетесь услугами другой организации, ничего страшного – процедура делегирования имени везде происходит примерно одинаково.

1. Узнайте адреса DNS своего хостера . Обычно эта информация поступает на электронную почту пользователя, когда тот вносит оплату за услуги. Если по какому-то недоразумению письмо затерялось, можно уточнить необходимые сведения самостоятельно. Рекомендуется зайти на сайт компании, предоставляющей хостинг, и попробовать поискать информацию в справочном разделе (который обычно носит название «FAQ»). Скажем, адреса провайдера Beget.ru являются такими: ns1.beget.ru и ns2.beget.ru . Обратите внимание: обычно DNS-адреса всего два, но может быть и больше.

2. Смените адреса в панели управления доменом. На сайте «Nethouse » для этого необходимо сначала перейти в раздел «Управление доменами ».

Затем нужно отметить галочкой привязываемое доменное имя, кликнуть на кнопку «Управление » и выбрать пункт «Сменить DNS-серверы ».

3. Пропишите адреса первичного и вторичного ДНС-адресов. Затем нажмите «Сохранить».

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

Как настроить домен на хостинге?

Скорректировать параметры на странице управления доменом недостаточно – необходимо также закрепить имя на сайте хостера. Так как настроить домен на сервере? Рассмотрим на примере портала провайдера TimeWeb .

1. Зайдите в панель управления хостингом и проследуйте в раздел «Домены и поддомены » в меню, расположенном слева. На выбор вам будут представлены две опции: «Зарегистрировать новый домен » и «Разместить домен на NS серверах » (видно на фото выше). Выбирайте вторую.

2. Введите имя сайта в специальное поле и кликните на кнопку «Разместить на NS серверах».

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

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