Содержание
Введение
1. DNS-СЕРВЕР
2. База данных DNS
3. Система русских доменных имен
4. Принципы работы динамического DNS
Заключение
Список использованной литературы
DNS - Domain Name Service Служба Доменных Имен, предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.
DNS была разработана для именования машин в глобальной сети. Основной особенностью глобальной сети является распределенное администрирование, когда один администратор физически не может уследить за выделением имен. Поэтому Служба Доменных Имен функционирует на принципе делегирования полномочий. Каждая машина либо знает ответ на вопрос, либо знает кого спросить. При правильном функционировании система замкнута, т.е. если запрошенная информация имеется у кого-либо, то она будет найдена и сообщена клиенту, либо, если вопрос не имеет ответа, клиент получит сообщение о невозможности получения ответа на вопрос.
У каждого компьютера в Интернете есть два основных идентификатора: доменное имя (например, www.listsoft.ru) и IP-адрес (например, 127.0.0.1). Приблизительность заключается в том, что, во-первых, IP-адресов у компьютера может быть несколько (мало того, что у каждого интерфейса свой адрес, так еще и несколько адресов могут "висеть" на одном интерфейсе); во-вторых, имен тоже может быть несколько, причем они могут связываться как с одним, так и с несколькими IP-адресами; в-третьих, у компьютера может и не быть доменного имени... Словом, ясно, что картина уже начинает запутываться.
Цель контрольной работы.
Доменные имена. Как работает DNS-сервер
Основной задачей DNS-сервера является трансляция доменных имен в IP-адреса и обратно.
Как было сказано выше, основной задачей DNS-сервера является трансляция доменных имен в IP адреса и обратно. На заре становления Интернета (когда он еще был ARPANET'ом) это решалось ведением длинных списков, включающих все компьютеры сети, причем копия такого списка должна была присутствовать на каждом компьютере. Понятно, что с ростом сети эта технология перестала удовлетворять кого бы то ни было - ведь эти файлы надо было еще и синхронизировать, не говоря уж об их размере... Некоторые "пережитки" этого метода можно обнаружить и сейчас: существует файл HOSTS (и в UNIX, и в Windows), в котором можно прописывать адреса серверов, с которыми вы регулярно работаете (кстати, именно его использование лежит в основе многих "ускорителей Интернета" - такие программы просто записывают адреса серверов, к которым вы обращаетесь, в файл HOSTS и при следующем обращении берут данные из него, не тратя время на запрос к DNS-серверу).
На смену "однофайловой" схеме пришел DNS - иерархическая структура имен. Существует "корень дерева" с именем "." (точка). Так как корень един для всех доменов, то точка в конце имени обычно не ставится (но она используется в описаниях DNS - тут надо быть очень внимательным!). Ниже корня лежат домены первого уровня. Их немного - com, net, edu, org, mil, int, biz, info, gov (есть еще несколько) и домены государств, например, ru. Еще ниже находятся домены второго уровня, например, listsoft.ru. Еще ниже - третьего и т.д.
DNS-сервер работает как хороший компьютерщик: он всегда либо знает ответ, либо знает у кого спросить...
Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".
Имеется некий домен верхнего уровня, обозначаемый точкой: ". ". Имеется девять серверов (по крайней мере на моем Name-сервере записано столько), которые отвечают за эту зону. Они не знают ни одного доменного имени - они только авторизуют серверы верхних зон. Серверы верхних зон тоже гнушаются хранить информацию о конкретных машинах и передают это право нижележащим серверам. Тут уже появляются первые упоминания о конкретных машинах, равно как и происходит авторизация нижележащих серверов.
Мне неизвестна ни одна машина с доменным именем из одного сегмента; очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко, а из шести и более мне неизвестны.
Допустим, клиент запросил адрес "www.организация. город. страна". Поиск информации по доменному имени происходит следующим образом:
Клиент спрашивает своего сервера.
Если тот является сервером данной зоны, то ответит, на чем все заканчивается.
Сервер спрашивает корневой сервер.
Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна".
Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город, страна".
Тот в свою очередь отсылает запрос серверу зоны "организация. город. страна", который сообщит нужную информацию.
Это приближенная модель, которая тем не менее позволяет представить работу системы DNS.
Однако эту стройную картину искажают системы кэширования и вторичных серверов. Дело в том, что получив ответ на свой вопрос, DNS-сервер получает также некоторое число, которое говорит ему о том, по истечении какого времени эта информация должна считаться устаревшей. Таким образом, все серверы, участвовавшие в поиске ответа на вопрос, заданный клиентом, могут (и скорее всего будут) помнить как ответ на заданный вопрос, так и путь, по которому шел поиск. При следующих запросах, имеющих общую правую часть с недавно сделанными запросами, поиск будет упрощен (ускорен).
Кроме того, большинство зон имеет вторичные серверы, которые содержат копии данных с первичных серверов. Сервер вышележащей зоны может направить запрос как первичному серверу, так и любому из вторичных, основываясь на своих соображениях о том, какой из них ближе.
Хочу обратить особое внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран. Имена серверов выглядят так:
http://ftp. freebsd.org/ - первичный сервер в США
Таким образом, машины, находящиеся в России оказались произвольно (по воле DNS-мастера из университета Bercley) включенными в домен freebsd. org; однако, они также состоят в своих зонах. Система DNS позволяет любому DNS-мастеру включить любой сервер в свою зону, хотя это включение никого ни к чему не обязывает.
Однако, некоторым сервисам этого недостаточно - так E-mail требует, чтобы машина, принимающая письмо, признала своим адрес, указанный в качестве пункта назначения. Протокол HTTP 1.1 (в 1.0 этого не было) требует, чтобы в HTTP-запросе указывался не путь к файлу, отсчитанный от корня сервера (хотя такие запросы тоже признаются), но и имя сервера; при этом сам сервер знает, какие имена - его, а остальные обрезает и обслуживает в соответствии с HTTP 1.0.
Делегирование зоны... in-addr. arpa дается только от провайдера вместе с IP-адресами. Собственно, это связано с предназначением ReverceDNS - сообщать доменное имя по IP-адресу. Наверняка мастер зоны freebsd. org держит Reverce-зону для IP-номеров, выделенных университету Bercley; но все эти серверы (кроме сервера, расположенного в университете) не входят в эту Reverce-зону, а значит, ему неподконтрольны.
Одна из проблем состоит в том, что Reverce-зону можно выделить только на сеть класса A, B или C (на 16777216, 65536 или 256 адресов) и никак иначе. Можно получить права на несколько зон одного или разных классов, но что делать тем, кому выделили меньше 256 адресов? А ведь в условиях исчерпания адресного пространства не редкость выделения пула уже на 16 адресов
Как правило, провайдер предоставляет клиенту целый комплекс услуг. В число оказываемых DNS-услуг входят:
делегирование зоны... in-addr. arpa клиентам, имеющим пул адресов, кратный 256.
регистрация доменного имени клиента у держателя той зоны, в которой клиент хочет зарегистрироваться;
поддержание вторичного сервера прямой и обратной DNS-зон клиента;
поддержание первичного сервера этих зон, если клиент по какой-либо причине не поддерживает их сам (особенно это относится к случаю виртуальных зон и к случаю выделения малого пула адресов);
Политика и стратегия назначения имен
Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегистрированы следующие "организационные" зоны:
com - commercial (коммерческие)
edu - educational (образовательные)
gov - goverment (правительственные)
mil - military (военные)
net - network (организации, обеспечивающие работу сети)
org - organization (некоммерческие организации)
Иерархичность DNS-серверов - штука довольно интересная, если проследить прохождение запроса. При установке (точнее, при настройке) клиенту указывается как минимум один DNS-сервер (как правило, их два) - его адрес выдается провайдером. Клиент посылает запрос этому серверу. Сервер, получив запрос, либо отвечает (если ответ ему известен), либо пересылает запрос на "вышестоящий" сервер (если он известен) или на корневой (каждому DNS-серверу известны адреса корневых DNS-серверов). Так выглядит "восходящая иерархия". Затем запрос начинает спускаться вниз - корневой сервер пересылает запрос серверу первого уровня, тот - серверу второго уровня и т.д. Таким образом, каждый DNS-сервер работает как хороший компьютерщик: он всегда либо знает ответ, либо знает, у кого спросить...
Помимо "вертикальных связей", у серверов есть еще и "горизонтальные" отношения - "первичный - вторичный". Действительно, если предположить, что сервер, обслуживающий какой-то домен и работающий "без страховки" вдруг перестанет быть доступным, то все машины, расположенные в этом домене, окажутся недоступны! Именно поэтому при регистрации домена второго уровня выдвигается требование указать минимум два сервера DNS, которые будут этот домен обслуживать.
Рекурсивные сервера удобно использовать в локальных сетях
DNS-сервера бывают рекурсивные и нерекурсивные. Первые всегда возвращают клиенту ответ - они самостоятельно отслеживают отсылки к другим DNS-серверам и опрашивают их. Нерекурсивные сервера возвращают клиенту эти отсылки, так что клиент должен самостоятельно опрашивать указанный сервер. Рекурсивные сервера удобно использовать на низких уровнях, в частности, в локальных сетях. Дело в том, что они кэшируют все промежуточные ответы, и при последующих запросах ответы будут возвращаться намного быстрее. Нерекурсивные сервера обычно стоят на верхних ступенях иерархии - поскольку они получают очень много запросов, то для кэширования ответов никаких ресурсов не хватит.
Использование "пересыльщиков" ускоряет разрешение имен
Полезным свойством DNS является умение использовать "пересыльщиков" (forwarders). "Честный" DNS-сервер самостоятельно опрашивает другие сервера и находит нужный ответ, но если ваша сеть подключена к Интернету по медленной (например, dial-up) линии, то этот процесс может занимать довольно много времени. Вместо этого можно перенаправлять все запросы, скажем, на сервер провайдера, а затем принимать его ответ. Использование "пересыльщиков" может оказаться интересным и для больших компаний с несколькими сетями: в каждой сети можно поставить относительно слабый DNS-сервер, указав в качестве "пересыльщика" более мощную машину, подключенную по быстрой линии. При этом все ответы будут кэшироваться на этом мощном сервере, что ускорит разрешение имен для целой сети.
Для каждого домена администратор ведет базу данных DNS. Эта база данных представляет собой набор простых текстовых файлов, расположенных на основном (первичном) сервере DNS (вторичные сервера периодически копируют к себе эти файлы). В файлах конфигурации сервера указывается, в каком именно файле содержатся описания каких зон, и является ли сервер первичным или вторичным для этой зоны.
Элементы базы DNS часто называют RR (сокращение от Resource Record). Базовый формат записи выглядит так:
[имя] [время] [класс] тип данные
Имя может быть относительным или абсолютным (FQDN - Fully Qualified Domain Name). Если имя относительное (не заканчивается точкой - помните про корневой домен?), то к нему автоматически добавляется имя текущего домена. Например, если в домене listsoft.ru я опишу имя "www", то полное имя будет интерпретироваться как "www.listsoft.ru." Если же это имя указать как "www.listsoft.ru" (без последней точки), то оно будет считаться относительным и будет интерпретировано как "www.listsoft.ru. listsoft.ru."
Время задает интервал времени в секундах, в течение которого данные могут сохраняться в кэше сервера.
класс определяет класс сети. Практически всегда это будет IN, обозначающее INternet.
Тип может быть одним из следующих:
SOA - определяет DNS зону
NS - сервер имен для зоны
A - преобразование имени в IP-адрес
PTR - преобразование IP-адреса в имя
MX - почтовая станция
CNAME - имена машины
HINFO - описание "железа" компьютера
TXT - комментарии или какая-то другая информация
Есть также некоторые другие типы, но они намного менее распространены.
В записях можно использовать символы # и; для комментариев, @ для обозначения текущего домена, () - скобки - для написания данных на нескольких строках. Кроме того, можно использовать метасимвол * в имени. Порядок записей не имеет значения за одним исключением: запись SOA должна идти первой. Дальнейшие записи считаются относящимися к той же зоне, пока не встретится новая запись SOA. Как правило, после записи зоны указывают записи DNS-серверов, а остальные записи располагают по алфавиту, но это не обязательно.
SOA - описание зоны
Теперь попробуем рассмотреть записи. Первой описываем зону:
mycompany.ru. IN SOA ns. mycompany.ru. admin. mycompany.ru. (1001; serial
21600; Refresh - 6 часов
1800; Retry - 30 мин
1209600; Expire - 2 недели
432000); Minimum - 5 дней
Сначала идет имя домена: mycompany.ru. (обратите внимание на точку в конце имени). Вместо имени можно было (и чаще всего так и делают) поставить знак @.
ns. mycompany.ru. - основной сервер имен
admin. mycompany.ru. - почтовый адрес администратора в формате имя (точка) машина
затем в круглых скобках идут поля, необходимые для правильного "восприятия" вашей зоны другими серверами. Первое число - serial - является "версией" файла зоны. При внесении изменений это число надо увеличить - если вторичный сервер увидит, что его версия зоны меньше, чем у первичного сервера, то он перечитает данные. Типичной ошибкой является обновление зоны без обновления этого числа. Очень удобно в качестве serial использовать текущую дату, например, 2003040401 - 4 апреля 2003 года, первое обновление.
Refresh говорит вторичным серверам, как часто они должны проверять значение serial.
Retry говорит о том, как часто вторичный сервер должен пытаться прочитать данные, если первичный сервер не отвечает.
Expire говорит вторичным серверам, в течение какого времени они должны обслуживать домен, если первичный сервер не отвечает. По истечении этого времени вторичные сервера будут считать свои данные устаревшими.
Minimum задает время жизни записей по умолчанию для данной зоны.
NS описывает сервера имен
Теперь опишем сервера имен, обслуживающие наш домен:
mycompany.ru. IN NS ns. mycompany.ru.
mycompany.ru. IN NS ns. provider.ru.
Здесь ничего сложного нет. Так как имя зоны совпадает с указанным в поле имя записи SOA, то его можно оставить пустым.
A описывает хосты
Дальше идут записи A, описывающие ваши компьютеры и позволяющие преобразовать имена в IP-адреса.
major IN A 192.168.0.1
colonel IN A 192.168.0.2
IN HINFO "2xPIV-1.7 Win2K"
general. mycompany.ru. IN A 192.168.0.3
Здесь сложного тоже ничего нет - имена могут быть относительные или "абсолютные", можно добавить записи о конфигурации машины (пропущенное имя в записи HINFO говорит о том, что имеется в виду предыдущее имя). Не забудьте добавить записи
localhost. IN A 127.0.0.1
localhost IN CNAME localhost.
mycompany.ru. IN A 192.168.0.1
Первая отдает адрес 127.0.0.1 любой машине, запросившей имя localhost, вторая - localhost. mycompany.ru, а третья говорит, куда послать клиента, который хочет попасть на mycompany.ru
C помощью CNAME можно задавать короткие имена серверов
Записи CNAME позволяют дать машинам удобные или значащие имена. Например:
ftp IN CNAME general говорит, что ftp. mycompany.ru живет по адресу 192.168.0.3. CNAME удобно использовать, если вы меняете имя машины, но хотите оставить доступ для клиентов, которые помнят старое имя. Удобный трюк с использованием CNAME заключается в назначении коротких имен часто используемым адресам. Например, прописав ls IN CNAME www.listsoft.ru., вы сможете заходить на ListSoft просто набирая ls в качестве адреса.
MX описывает пересылку почты.
Записи MX нужны для того, чтобы указать, куда пересылать почту. В этих записях добавляется приоритет - чем он меньше, тем выше приоритет машины. Приоритеты нужны для того, чтобы можно было задать несколько записей и перенаправить почту на альтернативный сервер, если основной не работает. MX запись должна быть указана для домена в целом и, возможно, для каждой машины в отдельности. Сложного тут тоже ничего нет за одним исключением: очень часто встречается неправильно использование метасимвола "*". Запись "*. mycompany.ru." означает не "любая машина домена mycompany.ru", а "любая машина, которая еще не была описана". Причем, даже если использовалась не MX, а, например, A-запись, то звездочка все равно не будет работать для этой машины. Более подробно почитать об использовании метасимволов можно в RFC 1034, раздел 4.3.3 В принципе, метасимволы нужны только для того чтобы принимать почту для сети, находящейся за брандмауэром и чтобы пересылать почту в сети, не подключенные к Интернету (например, работающие через UUCP). Так как записи DNS меняются довольно редко, то имеет смысл прописать MX записи для всех машин, описанных записями A.
mycompany.ru. IN MX 10 relay
mycompany.ru. IN MX 20 mycompany.ru.
mycompany.ru. IN MX 30 mail. provider.ru.
general. mycompany.ru. IN A 192.168.0.3
IN MX 10 mycompany.ru.
Реверсная зона позволяет определить имя по адресу
На этом создание файла зоны можно считать законченным. Но остается более увлекательное занятие: описание реверсной зоны. Если предыдущий файл позволяет определить IP-адрес по имени, то теперь надо сделать так, чтобы по IP-адресу можно было "вычислить" имя. Отсутствие реверсной зоны является довольно типичной ошибкой и может приводить к самым разным ошибкам - начиная от сбоев FTP-серверов и заканчивая классификацией отправленных писем как спама.
PTR преобразовывает адрес в имя.
Для обратного преобразования используются записи PTR. Но не торопитесь их вписывать - тут есть одна хитрость: они пишутся в отдельном специальном домене верхнего уровня, с названием IN-ADDR. ARPA. Домен этот был создан для того, чтобы и для прямого, и для обратного преобразований можно было использовать одни и те же программные модули. Дело в том, что "мнемонические" имена пишутся слева направо: www.listsoft.ru означает, что www находится в listsoft, а listsoft - в ru. IP-адреса пишутся наоборот: 195.242.9 4 означает, что машина 4 находится в подсети 9, которая является частью 195.242 И для сохранения "единого стиля" адресов для обратного преобразования используются имена вида 4.9 242.195. IN-ADDR. ARPA (обратите внимание, что IP-адрес записан в обратном порядке).
Итак, мы создаем еще один файл зоны (для зоны, например, 0.168.192. IN-ADDR. ARPA), копируем в него запись SOA (а заодно и NS), после чего начинаем писать:
1 IN PTR major. mycompany.ru.
2 IN PTR colonel. mycompany.ru.
Можно задавать не только относительные, но и абсолютные имена:
3.0.168.192. IN-ADDR. ARPA. IN PTR general. mycompany.ru.
Не забудьте еще задать обратное преобразование для 127.0.0.1.
Обратите внимание на то, что право на ведение "прямого" домена не зависит от провайдера - его выдает организация, ведающая распределением имен в нужном вам домене. А вот пул IP-адресов находится в ведении провайдера, и именно провайдер делегирует (или не делегирует) вам права на ведение реверсной зоны. В связи с тем, что зачастую клиентам выдается не целая сеть класса "C", а ее часть, то и реверсная зона находится на сервере провайдера. Так что вам придется наладить с ним взаимодействие в области обновления данных.
Настройте трансфер зоны.
Напоследок - одно маленькое замечание. Исследование DNS является одним из первых этапов "изучения сети" при подготовке ее взлома. Чаще всего используется перенос зоны, при котором все записи зоны передаются на компьютер "исследователя", где он их может изучать в спокойной обстановке. Поэтому имеет смысл (помимо всего прочего) настроить брандмауэр на запрет TCP-соединений по 53 порту с несанкционированных адресов (в запросах на определение имен используется UDP, а для переноса зоны - TCP).
Каким образом она работает, рассказывает ведущий специалист web-студии "Дизайн-Бюро" Константин Шепелин (начало смотрите в предыдущем номере).
Система доменных имен - DSN - является основой удобного доступа к серверам Интернет, позволяя использовать вместо их подлинных цифровых адресов (IP) легко запоминаемые словесные обозначения, например www.1ru.ru вместо 64.45.60.67. Однако по существующим стандартам доменные имена, т.е. фрагменты интернет-адресов в текстовой форме, должны состоять из символов ASCII-кода, букв латиницы и цифр, причем допускаются дефисы внутри имен. Технология, предлагаемая компанией VeriSing, позволяет обойти это ограничение. Для того, чтобы использовать символы национальных алфавитов, в том числе и русского, их нужно перекодировать в Unicode, что, кстати, решает проблему наличия множества кодировок, а затем по специальному алгоритму преобразуются в уникальную последовательность "разрешенных" ASCII-символов. Например, слово "банк" преобразуется в AQYTAPJ2. К этой строке, однозначно соответствующей кириллической записи, добавляется специальный префикс BQ - (с двумя дефисами). Он служит для того, чтобы отличать преобразованные доменные имена от случайных наборов ASCII-символов. Такой формат записи называется RACE (Row-based ASCII Compatible Encoding). В результате адрес сайта www.россия. org преобразуется в www.BQ--ARAD4QKBHBHQ. ORG. Именно RACE-адрес домена хранится в базах данных DNS, благодаря чему перестройка существующей мировой системы доменных серверов и замена программного обеспечения на вашем веб-сайте не требуется.
В настоящее время для работы с мультиязыковыми доменнными именами на компьютере клиента (например, посетителя сайта) должна быть установлена специальная программа, преобразующая символы национального алфавита в RACE-формат, который и используется при запросе к DNS.
В дальнейшем поддержка мультиязыковых доменов будет встраиваться непосредственно в операционные системы и браузеры. Для разработчиков ПО, желающих обеспечить поддержку национальных доменных имен в своих продуктах, компания VeriSing разработала бесплатный набор библиотек (SDK).
Учитывая сложность внедрения новой системы доменных имен, компания разделила ее тестовую эксплуатацию и ввод в строй на несколько этапов. Уже сейчас вы можете зарегистрировать доменное имя имя на русском языке, однако его делегирование будет произведено только по завершению создания необходимой инфраструктуры.
На первом этапе все зарегистрированные национальные имена в RACE-формате размещаются в виде доменов третьего уровня в тестовой зоне mltbd.com/net/org. Зарегистрировав сайт www.РОССИЯ. org, вы сможете увидеть в сети виртуальный сервер BQ--ARAD4QKBHBHQ. mltbd. org. Поскольку DNS не учитывает разницу между заглвными и строчными символами, то верхний регистр используется просто для упрощения восприятия. На страничке по этому адресу содержится краткая информация о ходе тестирования и подтверждение достижения зарегистрированного домена. На втором этапе созданные в зоне mltbd.com/net/org поддомены будут делегированы владельцам соответствующих доменов второго уровня.
Таким образом, набрав в браузере www.BQ--ARAD4QKBKBHBH. mltbd. org, пользователь попадает на сайт www.РОССИЯ. org, а точнее, на страницу, определяемую сервером имен РОССИЯ. org. И, наконец, третий этап - это непосредственное делегирование доменов в зонах.com,. net и. org, т.е. адрес www.BQ--ARAD4QKBHBHQ. org приведет пользователя непосредственно на сайт www.РОССИЯ. org/.
Компьютер, подключающийся к сети Интернет, независимо от существующих на нем настроек, видится всем остальным по некоторому IP-адресу. Этот адрес может быть постоянным, прописанным в настройках компьютера и не изменяющийся при подключении к Сети, а может быть динамическим, присваиваемым ему на текущий сеанс связи провайдером. Во втором случае этот адрес при каждом подключении может оказываться отличным от предыдущего. Если же вы хотите, чтобы к вашему компьютеру могли обращаться ваши друзья или иные посетители, его IP-адрес должен быть постоянным.
Да, интернет-сервисы могут располагаться не только на специально выделенных для этого серверах, но и на домашних компьютерах. На таком компьютере может размещаться сайт, каталог файлов или картинок, почтовый или игровой сервер. Но если ваш IP-адрес будет динамическим, то при каждом подключении к Сети вам нужно будет посылать его своим постоянным посетителям, чтобы они могли попасть на ваш сайт. К тому же, подключаться к сайту им придется по IP-адресу, а не по его названию. Что делать, чтобы избежать подобной проблемы?
Один способ - приобрести у провайдера постоянный адрес и использовать его. Весьма простая ситуация, но не бесплатная. За такое "удовольствие" придется выкладывать вполне ощутимую сумму. Но в последние годы появились иные возможности обеспечить доступ к компьютеру из Интернета, не требующие при этом обращения к провайдеру. Появившиеся службы (Dynamic DNS сервисы) позволяют это делать для динамически выделяемых адресов. Базовые услуги ими, как правило, предоставляются бесплатно, а вот за дополнительные возможности придется платить.
Сервис DDNS состоит из двух компонент. Первая - специальное ПО, работающее на удаленном компьютере. Вторая - клиентская программа, устанавливаемая на рабочее место. Первая компонента отвечает за взаимодействие со своим DNS, настройкой и поддержкой пользовательских аккаунтов. Клиентская часть обеспечивает связь с серверной, передает ей текущее значение выделенного для данного соединения адреса, обеспечивает некоторые дополнительные настройки.
Суть решения заключается в следующем. Клиент сервиса создает на нем свою учетную запись и либо регистрирует субдомен на базе домена сервиса, либо прописывает уже имеющееся у владельца имя домена (можно регистрировать на сервисе и те домены, о которых уже имеется запись на DNS-серверах, но их потребуется откорректировать). При регистрации субдомена заполняются данные, какие обычно заполняются при регистрации. Требуется это для того, чтобы занести в службе имен (DDNS) информацию в необходимом виде и объеме. После этого выполняется запись сведения о домене с учетом IP-адреса, по которому пользователь в момент регистрации подключался к сервису. Так домен оказывается связанным с адресом. После этого пользователь скачивает и устанавливает клиентскую часть. При подключении к Интернету она связывает выделенный на данную сессию адрес с зарегистрированным доменом. При изменении адреса сведения, записанные в DDNS, обновляются. Теперь любой желающий, набрав в строке браузера адрес вашего сайта, попадет на ваш компьютер.
Небольшое отступление. Такой вариант оказывается очень удобным при наличии ADSL-подключения, когда у компьютера долгое время остается один и тот же адрес, а переподключения бывают весьма редкими. При подключении к Сети с помощью модема ситуация несколько усложняется тем, что смена IP-адреса бывает намного чаще, к тому же, в промежутках между подключениями связанный с доменом адрес будет выдаваться кому-либо иному. В результате посетители домена будут получать сообщение о том, что искомая страница не найдена. Но на такие издержки приходится идти, если используется только модемное соединение.
Размещая интернет-сервисы на своем домашнем компьютере, нельзя забывать о необходимости его защиты. Как только вы предоставите возможность доступа извне, к вам начнут "заходить" не только посетители, но и любители легкой наживы, распространители троянов, вирусов и прочих гадостей. Поэтому в обязательном порядке необходимо устанавливать как антивирусное ПО, так и файрволы. Но в этом случае потребуется дополнительная настройка. Вам придется открыть для доступа порты, к которым вы привяжете свои сервисы. Это могут быть как стандартные порты (например, порт 80 для веб-сервера), так и нестандартные (прежде чем назначать нестандартные, порты убедитесь, что сервис DDNS поддерживает перенаправление запросов со стандартных портов на нестандартные). Наиболее часто переназначение стандартного порта требуется в случае установки почтового сервера. Провайдеры, как правило, запрещают доступ к 25 порту, поэтому его приходится переназначать на другой порт.
Есть отличия в настройке файрволов, основанных на использовании прокси или без него. В первом случае требуется настройка клиента на использование прокси и выдача ему "разрешения" на выход в Интернет. В случае использования файрвола, работающего на основе NAT, достаточно лишь указать его адрес в настройках клиентской программы.
Как уже говорилось, клиентская часть служит для передачи на сервис текущего значения IP-адреса. Но иногда возникают ситуации, что клиент вначале обнаруживает локальный IP-адрес компьютера и пытается передать на сервис его, а не тот адрес, который выдает провайдер. Для того чтобы избежать подобной ситуации, нужно внести локальный адрес в список игнорируемых адресов при настройке клиента.
Рассмотрим, какие услуги и возможности предлагают DDNS-сервисы. Возьмем, к примеру, сервис Dynu.com.
Поддержка доменов.
Бесплатный сервис обеспечивает поддержку поддоменов в доменах dynu.com и dynu. net. Домены в зонах *.com, *. net, *. biz, *. co. jp, *. de и других поддерживаются в платном сервисе.
Динамическое обновление IP-адресов.
Клиентская часть сервиса есть для таких платформ, как Windows 9x/NT/2000/XP, Mac OS, Mac OS X, Linux, FreeBSD, Solaris, Unix.
Поддержка поддоменов (алиасов) зарегистрированного домена
Бесплатный сервис обеспечивает поддержку таких алиасов, как ftp, mail, www и иных, привязанных к одному и тому же адресу. А платный сервис позволяет связывать любые поддомены с различными IP-адресами (например, если ваш веб-сервер и почтовый сервер размещены на различных компьютерах, имеющих раздельное подключение к Интернету).
Поддержка протокола SSL.
Перенаправление HTTP-порта.
Позволяет перенастроить стандартный HTTP-порт (80) на любой другой. Ваш веб-сервер, соответственно, должен быть настроен на нужный порт.
Онлайн-перенаправление.
В то время, когда вы подключены к сервису, позволяет перенаправлять пользователей, запрашивающих вашу страницу, на любой другой сайт.
Распределение нагрузки на сервер.
При большой посещаемости вашего ресурса в платной версии сервиса имеется возможность использовать технологию RoundRobin. Она заключается в создании нескольких записей доменного имени с привязкой каждой из них к отдельному IP-адресу. Таким образом, посетители будут перенаправляться на различные компьютеры в зависимости от их загрузки.
Другим популярным сервисом считается DNS2Go. Большинство предоставляемых услуг являются бесплатными. По своей функциональности сервис очень близок к сервису Dynu.com, а вот бесплатных возможностей дает несколько больше. Кроме уже перечисленных возможностей, DNS2Go предоставляет услуги по перенаправлению электронной почты (услуга - платная). Она включает защиту от вирусов и спама, перенаправление почты, пересылку на иной адрес, хостинг почтового сервера. Услуга может быть полезной тем, кто не может держать установленный на домашнем компьютере почтовый сервер, постоянно подключенный к Интернету.
Все компьютеpы, объединенные в Internet, pаботают над упpавлением собственных опеpационных систем, но все они общаются между собой на едином языке компьютеpных сетей ТСР/IP (пpотокол упpавления пеpедачей над пpотоколом Internet). По сути это два пpотокола TCP/IP.
IP - (Internet Protocol) - опpеделяет, как будет выглядеть инфоpмация во вpемя путешествия по суше и что с ней делать, а также опpеделяет как pаботает система адpессации.
Каждый компьютеp в сети имеет свой адpес (4 цифpы) ТСР пpотокол - для опpеделения типа инфоpмации, содеpжащейся в пакете данных, а также следует, чтобы данные обязательно дошли до адpессата.
TCP пpотокол - опpеделения типа инфоpмации, содеpжащейся в пакете данных, а также следит, чтобы данные обязательно дошли до адpессата. Имена сеpвеpов в Internet опpеделяются, как стpоки, напpимеp, jsc. nasa. gov, однако, это не является действительной частью пpотокола TCP/IP. Существует унивеpсальный внешний механизм пpеобpазования таких имен в IP адpеса, котоpые понимает TCP/IP. Этот механизм называется Системой Доменных Имен (DSN), Т.о. нет необходимости знать IP адpеса компьютеpов, к котоpым мы хотим обpатиться. Напpимеp, если компьютеp А хочет знать IP-адpес компьютеpа jsc. nasa. gov, то он делает запpос на глобальный сеpвеp DNS. Этот сеpвеp не знает IP-адpеса, но зато знает сеpвеp-DNS, котоpый знает все адpеса, заканчивающиеся на nasa. gov и пеpесылает запpос на этот локальный сеpвеp, котоpый и сообщает А необходимый IP-адpес.
1. Информатика: Учебник/под ред. Н.В. Макаровой. - М.: Финансы и статистика, 2000. - 768 с.
2. Информатика. Базовый курс. Учебник для Вузов / под ред. С.В. Симоновича, - СПб.: Питер, 2000.
3. Денисов А., Вихарев И., Белов А. Самоучитель Интернет. - Спб: Питер, 2001. - 461 с.
4. Коцюбинский А.О., Грошев С.В. Современный самоучитель работы в сети Интернет. М.: Триумф, 2007.
5. Основы современных компьютерных технологий: Учебное пособие / под. ред. Хомоненко. - СПб.: КОРОНА, 2005.
6. Симонович С.В., Евсеев Г.А., Практическая информатика, Учебное пособие. М.: АСТпресс, 2005.
7. Савельев А.Я., Сазонов Б.А., Лукьянов Б.А. Персональный компьютер для всех. Хранение и обработка информации. Т.1 М.: Высшая школа, 2001.
8. Тюрин Ю.Н., Макаров А.А. Статистический анализ данных на компьютере. Под ред.В.Э. Фигурнова. М.: ИНФРА-М, 1998.
9. Фигурнов В.Э. IBM PC для пользователя. М.: Инфра-М, 2001 г.
10. Фролов А.В., Фролов Г.В. Глобальные сети компьютеров. Практическое введение в Internet, E-Mail, FTP, WWW и HTML. М.: Диалог-МИФИ, 2006.
|
