Автор: Пользователь скрыл имя, 03 Октября 2012 в 01:41, отчет по практике
В процессе прохождения технологической практики мы должны получить достаточно полное представление о будущей профессии, а также понять взаимосвязь и направленность изучаемых по специальности дисциплин.
I. Введение
II. Сведения о компании «СофтЛайн Трейд»
О компании
История и развитие компании «СофтЛайн Трейд»
Цель компании
Softline – программное обеспечение, IT – сервисы, решения.
Компании разработчики ПО
Клиенты компании «СофтЛайн Трейд»
III. Задание и проделанная работа
Классификация сетевых протоколов
Запрос к DNS серверу
Настройка прямой и обратной зон
Синтаксис файла-зоны
Определение ответственного за DNS-зону
IV. Заключение
Наиболее изветсные сообщения ICMP, это пожалуй echo request и echo reply. Обычно они используются в целях тестирования.
UDP
Протокол UDP служит для передачи данных без коррекции ошибок. Есть целый класс данных в которых скорость передачи данных намного важнее качества. Например потоковое видео и аудио. Клиент переживёт потерю нескольких букв, но замедление потока не простит. Другой пример — система DNS. Серверы DNS обслуживают десятки тысяч запросов в секунду. Гарантированная доставка в таких условиях просто невозможна, так как контроль ошибок очень ресурсоёмок.
В задачу протокола UDP входит разбиение потока данных на пакеты. Каждый пакет имеет заголовок в котором указаны IP (или IPv6) адреса источника и назначения и порты источника и назначения. Номера портов идентифицируют программы на хосте источнике и на хосте назначения между которыми осуществляется передача данных.
Протокол UDP действует по
принципу «выстрелил и забыл». Он не
только не гарантирует доставку пакетов,
но даже не гарантирует, что доставленные
пакеты придут в том же порядке, в
котором они были высланы. Тем
не менее, в надёжных сетях во имя
роста производительности можно
в некоторых приложениях
TCP
И наконец, протокол TCP отличается
от протокола UDP тем, что в нём
действует механизм контроля ошибок.
Для реализации этого механизма
в заголовок добавлено
2. Запрос к серверу DNS
Итак, протоколы IP и IPv6 устроены таким образом, что адресация происходит при помощи числовых адресов. Нельзя сказать, что человека это должно как-то напрягать, ведь никто не протестует против применения семизначных, десятизначных и даже более длинных телефонных номеров. Однако иметь более мнемоничные адреса несомненно удобнее. Почти сразу, как только появился интернет, появились таблицы соответствия IP адресов и символьных имён машин. Эти таблицы и по сей день хранятся в файле /etc/hosts. Однако задача синхронизации данного файла между машинами очень скоро стала непомерно сложной. В настоящий момент можно с уверенностью сказать, что она вообще нереальна. Для решения этой проблемы возникла система DNS — распределённая база данных.
Распределённая, значит ни один сервер не содержит в себе сведений обо всём пространстве имён Интернета. Каждый сервер ответственен за свой участок этого пространства. Говорят, что данный сервер авторитетен для данной зоны.
Таким образом, пространство имён Интернета поделено на зоны. Каждый сервер может отвечать за ноль и более зон. Рассмотрим, что происходит когда некоторой машине надо узнать IP адрес машины www.dragonflybsd.org.
Первым делом наш сервер посылает запрос одному из корневых серверов DNS. Разумеется ни один из корневых серверов не знает ответа на этот вопрос. Больше того, ни один из них и не будет разбираться в вопросе, т.е. ни один из них не является рекурсивным. Зато они знают, какие сервера ответственны за зону org. И этой информацией делятся.
Вся информация полученная нашим сервером DNS надолго помещается в его кеш. Время хранения в кеше, зависит от настроек зоны, т.е. определяется не нашим DNS сервером, а теми серверами, которые ответственны за зону (в самом деле, только они могут знать насколько надёжны предоставленные ими данные). Некоторые серверы DNS могут существовать исключительно ради своего кеша и не иметь ни одной зоны, за которую они бы отвечали (так называемы кеширующие серверы).
Заметьте, что есть чёткая
иерархия зон, но нет иерархии серверов
DNS. Сервер DNS первым делом осуществляет
запрос к корневому серверу, а
вовсе не к «своему начальнику».
Понятие старшинства среди
|
В каждой зоне могут быть записи следующих типов:
Запись |
Описание |
SOA |
Определение параметров зоны DNS (таймауты, адрес ответственного лица) |
NS |
Определение DNS-серверов ответственных (авторитетных) за зоны, делегирование полномочий поддоменам. |
Записи типа SOA и NS обязательны, остальных записей может не быть вовсе. | |
A |
Преобразование имени в IP адрес |
AAAA или A6 |
Преобразование имени в IPv6 адрес |
PTR |
Преобразование IP адреса в имя |
MX |
Указание почтового сервера ответственного за зону |
KEY |
Открытый ключ шифрования для имени DNS |
CNAME |
Псевдоним, алиас, синоним. |
SRV |
Распределение нагрузки на сервис |
TXT |
Текстовая запись используется с самой разной целью |
HINFO |
Информация о машине, например архитектура и операционная система. |
(Таблица 2. Типы записей в файле зоны DNS)
3. Настройка прямой и обратной зон
Сначала зона должна быть объявлена
в конфигурационном файле сервиса named(8) — named.conf(5). Этот конфигурационный файл
может находиться в файле /etc/namedb/named.conf, а может в /var/named/etc/namedb/named.
Зона, оъявленная в BIND, может иметь один из следующих типов: master, slave, hint или forward. Зона hint содержит в себе адреса корневых серверов DNS, с которых начинает опрос рекурсивный сервер DNS. Эта зона практически не подвержена никаким изменениям и обычно не должна редактироваться администратором.
Зона типа master должна быть описана в файле.
Объявление зоны типа master:
...skip...
options {
directory "/etc/namedb";
...skip...
}
...skip...
zone "example.org." {
type master;
file "master/example.zone";
};
...skip...
Здесь сказано, что зона example.org. описана в файле master/example.zone. Этот адрес дан относительно каталога /etc/namedb .
Зону типа master редактирует администратор, но за эту зону может отвечать несколько серверов DNS. Для того, чтобы все они обладали одинаковой согласованной информацией, на всех прочих серверах DNS поднимается зона типа slave, которая синхронизируется с зоной типа master. Зона типа slave объявляется следующим образом:
zone "example.org." {
type slave;
file "slave/example.zone";
masters {
192.168.1.1;
};
};
Здесь сказано, что зона имеет тип slave, а сервер, с которого надо брать информацию о ней (master) имеет адрес 192.168.1.1. Информация о зоне (файл зоны) будет сохраняться в файле slave/example.zone. Последняя опция необязательна, если файл не указан, информация будет храниться в памяти и при перезагрузке сервера DNS пропадёт.
Зона типа forward применяется в редких случаях, когда надо заставить наш сервер DNS делать запрос о зоне для которой он не авторитетен не к одному из корневых серверов, перечисленных в зоне hint, а к некоторому конкретному серверу. Например, пусть DNS A, расположенный на некотором предприятии, описывает локальную зону local. и делегирует зону finans.local. серверу DNS B. Поскольку сервер A не авторитетен для зоны finans.local., при попытке разрешить имя major-buhg.finans.local., он обратится к корневому серверу DNS (несмотря на то, что он сам делегировал зону finans.local. серверу B) и потерпит неудачу, так как зоны local. с точки зрения корневых серверов не существует. Поэтому на сервере A мы должны описать зону finans.local. типа forward для того, чтобы он переадресовывал запросы к этой зоне на авторитетный для неё сервер B:
zone "local." {
type master;
file "master/local.zone";
};
zone "finans.local." {
type forward;
masters {
192.168.1.2; // server B
};
};
В свою очередь, на сервере B нам, вероятно, надо указать опцию forwarders, в которой указать сервер A, тогда опрос сервер B будет производить не с корневых серверов, а с сервера A и разрешение имён находящихся в зоне local. будет работать корректно. Кроме того, такое действие полезно, если на предприятии поднято несколько серверов DNS, а выход в Интернет на брандмауэре разрешён только серверу A.
...skip...
options {
directory "/etc/namedb";
forwarders {
192.168.1.1; // server A
};
...skip...
}
4. Синтаксис файла зоны
Файл зоны состоит из перечня записей различного типа. Обязательных записей в этом файле всего две: запись типа SOA и запись типа NS в которой указан сервер DNS ответственный за данную зону.
В каждой записи имеется необязательное поле, в котором указывается время жизни данной записи в кешах серверов DNS. Чтобы не указывать эту величину в каждой строке (как правило нет никакого смысла делать различные времена жизни для разных записей) её можно указать в самом начале файла, задав переменную $TTL.
Все адреса в файле зоны должны заканчиваться на точку (т.н. формат FQDN: fully qualified domain name — полностью описанное имя домена). Если имя не кончается на точку, к нему дописывается содержимое переменной $ORIGIN. Если данная переменная не задана явно, то в ней содержится имя зоны, т.е. то, что объявлено в файле named.conf(5).
Другая интересная переменная — $INCLUDE позволяет включить внутрь одного файла зоны другой файл.
Комментарии в файле зоны начинаются с символа ;.
Первая запись в файле зоны — запись типа SOA. помимо необязательного поля TTL в записи SOA имеется десять обязательных полей, поэтому записать её в одну строку весьма затруднительно. Для того, чтобы запись типа SOA можно было написать в несколько строк, применяются круглые скобки. запись не кончится, пока не закроется круглая скобка.
Пример файла зоны с описанием:
$TTL 36000
@ IN SOA ns.example.ru. root.example.ru. (
IN NS ns.example.ru.
IN NS ns1.example.ru.
IN NS ns2.otherplace.ru.
IN MX 5 smtp.example.ru.
IN MX 15 smtp.otherplace.ru.
ns IN A 192.168.0.1
ns1 IN A 192.168.0.2
smtp IN A 192.168.0.1
www IN A 192.168.0.3
site1 IN CNAME www
site2 IN CNAME www
В приведённом примере сперва задана переменная $TTL, затем сделано двенадцать записей: первая запись типа SOA, три типа NS, две типа MX, четыре типа A и две типа CNAME.
SOA