Отчёт о прохождении производственно-технологической практики на примере компании «СофтЛайн Трейд»

Автор: Пользователь скрыл имя, 03 Октября 2012 в 01:41, отчет по практике

Краткое описание

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

Оглавление

I. Введение
II. Сведения о компании «СофтЛайн Трейд»
О компании
История и развитие компании «СофтЛайн Трейд»
Цель компании
Softline – программное обеспечение, IT – сервисы, решения.
Компании разработчики ПО
Клиенты компании «СофтЛайн Трейд»
III. Задание и проделанная работа
Классификация сетевых протоколов
Запрос к DNS серверу
Настройка прямой и обратной зон
Синтаксис файла-зоны
Определение ответственного за DNS-зону
IV. Заключение

Файлы: 1 файл

Анисимов.docx

— 333.69 Кб (Скачать)

NS

В записи типа NS, в данном примере, отсутствует первое поле. Это  значит, что оно будет взято  из предыдущей записи. Таким образом, все три записи NS относятся к  зоне example.ru. и описывают три сервера авторитетных для данной зоны. Два из них будут slave, а один, упомянутый в записи SOA — master.

Поле с классом записи (IN) так же как и TTL необязательное, и тоже, как и TTL могло бы отсутствовать.

В остальном синтаксис  достаточно прост, назначение данной записи — перечислить ответственные за зону сервера DNS, поэтому обязательных полей здесь два: тип записи и имя сервера.

Разумеется сервер DNS не обязан находиться в описываемой зоне. В данном случае упомянут один сервер DNS из другой зоны otherplace.ru. Если сервер находится в нашей зоне, мы должны ниже, в записи типа A указать его адрес, если он в другой зоне, то его адрес должны указать там. Тем не менее нет никаких причин не включить этот сервер ещё и в нашу зону. Это удобнее, так как мы, в этом случае можем сами указать соответствующий IP.

Запись типа MX

Здесь описано какие хосты ответственны за приём почты направляющейся в домен example.ru. Если такой записи нет вообще, то почту будет принимать машина с именем example.ru. Если таких записей много, то сперва будет предпринята попытка доставить почту на машину с самым низким значением поля с приоритетом, затем, в случае неуспеха, на машину со следующим приоритетом и так далее.

Итак, данная запись отличается только тем, что в ней добавлено  поле с приоритетом записи, сразу  после типа записи MX.

Запись типа A

Данная запись указывает  соответствие между именем и адресом IP. В случае, если в файле зоны имеется несколько записей с одинаковым именем, но разными адресами, например:

www       IN        A         192.168.0.1

www       IN        A         192.168.0.2

www       IN        A         192.168.0.3

                 


...адреса будут выдаваться  сервером DNS циклически: в ответ на  первый запрос о имени www.example.ru сервер DNS даст адрес 192.168.0.1, следующему клиенту дадут адрес 192.168.0.2 и дальше по кругу. Это один из способов распределения нагрузки между различными серверами. К сожалению, это не самый удачный способ распределения нагрузки: при аварии на одном из серверов, даже если принять оперативные меры по редактированию файла зоны, в многочисленных кешах ещё долго будет сидеть информация о неработающем сервере и треть клиентов продолжит получать неправильную информацию. Снижение TTL на данные записи приведёт к увеличению нагрузки на систему DNS и в конечном итоге приведёт к замедлению обслуживания клиентов.

CNAME

Запись типа CNAME указывает  на то, что данные имена это имена  одной и той же машины. Такие  записи удобны, например, при создании виртуальных веб-серверов.

SRV

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

;; _служба._протокол.имя   [ttl]   IN SRV приоритет вес   порт   сервер

_http._tcp.www                     IN SRV     0       1    80     www.server.ru.

                                   IN SRV     0       3    8080   old.server.ru.

                 


В приведённом примере  браузер должен осуществить запрос с целью определить на каком сервере и на каком порту обслуживают злужбу http по протоколу tcp. Как результат он получает информацию о том, что эти запросы обслуживают две машины: www.server.ru и old.server.ru. Причём первая обслуживает 25% запросов и работает на порту 80, а вторая обслуживает 75% запросов и работает на порту 8080. Распределение нагрузки осуществляется на основе поля «вес» на добровольной основе, т.е. дано на откуп клиенту.

Поле «приоритет» имеет  то же значение, что и для записи MX. Клиент должен обращаться к записи с наименьшим числом в поле «приоритет», и переходить к записи с большим приоритетом, только если сервера из записей с меньшим недоступны.

Имя службы и протокола  должно начинаться с подчерка, чтобы  не перепутать их с обычными именами.

TXT

Текстовая запись. В ней  может находиться самая разнообразная  информация. Например стихи:

poem    IN      TXT     ( "The Road goes ever on and on"

                        "Down from the door where it began."

                        "Now far ahead the Road has gone,"

                        "And I must follow, if I can,"

                        "Purshuing it with eager feet,"

                        "Until it joins some larger way"

                        "Where many paths and errands meet."

                        "And whither then? I cannot say." )

                 


Ёмкость этой записи — пара килобайт. Мы вполне можем использовать её для хранения коротких стихотворений, создав доменные имена для разных поэтов... Однако у этой записи есть множество других, более полезных применений. В некоторых случаях в ней хранят публичные ключи. Старые версии BIND хранили в записях TXT информацию о том, кому можно отвечать на запросы к зоне (в новых версиях это делается при помощи директивы allow-query).

Итак, администратор должен уметь не только определять IP адрес  машины, но и запрашивать записи о зоне определённого типа. Для  осуществления этих запросов существует три команды: host(1), dig(1), nslookup(1).

 

host(1)

Программа host(1) существует во многих вариантах. В FreeBSD она умеет сообщать практически ту же информацию, что и dig(1), но в других системах это может быть не так. Здесь мы приведём примеры на базе FreeBSD, как наиболее полные.

Запрос IP по адресу:

$ host mail.ru

mail.ru has address 194.67.57.26

mail.ru mail is handled (pri=10) by mxs.mail.ru

       


Как видно, нам сообщили не только IP машины mail.ru, но и некоторую  дополнительную информацию (имя почтовой машины и её приоритет). Эта информация приходит от сервера DNS в том же UDP пакете и её получение не требует  со стороны программы host(1) никаких специальных действий. И всё же, некоторые варианты этой программы могут не сообщать всей информации.

Программе можно явно указать  сервер DNS, в этом случае запрос будет  сделан к нему:

$ host mail.ru 194.67.23.130

Using domain server 194.67.23.130:

 

mail.ru has address 194.67.57.26

mail.ru mail is handled (pri=10) by mxs.mail.ru

       


И наконец, можно запросить  конкретный тип записи:

$ host -t NS mail.ru

mail.ru name server ns2.mail.ru

mail.ru name server ns3.mail.ru

mail.ru name server ns4.mail.ru

mail.ru name server ns5.mail.ru

mail.ru name server ns.mail.ru

mail.ru name server ns1.mail.ru

$ host -t SOA mail.ru

mail.ru start of authority      ns.mail.ru hostmaster.mail.ru (

                        3209013119      ;serial (version)

                        300     ;refresh period

                        900     ;retry refresh this often

                        172800  ;expiration period

                        300     ;minimum TTL

                        )

       


Опция -v включает режим verbose.

$ host -t NS -v mail.ru

Trying null domain

rcode = 0 (Success), ancount=6

The following answer is not authoritative:

The following answer is not verified as authentic by the server:

mail.ru 16141 IN        NS      ns4.mail.ru

mail.ru 16141 IN        NS      ns5.mail.ru

mail.ru 16141 IN        NS      ns.mail.ru

mail.ru 16141 IN        NS      ns1.mail.ru

mail.ru 16141 IN        NS      ns2.mail.ru

mail.ru 16141 IN        NS      ns3.mail.ru

Additional information:

ns.mail.ru      153899 IN       A       194.67.23.130

ns1.mail.ru     299802 IN       A       194.67.57.103

ns2.mail.ru     167593 IN       A       194.67.57.104

ns3.mail.ru     278118 IN       A       194.67.23.17

ns4.mail.ru     278118 IN       A       194.67.57.4

ns5.mail.ru     278118 IN       A       194.67.23.232

$ host -t SOA -v mail.ru

Trying null domain

rcode = 0 (Success), ancount=1

The following answer is not authoritative:

The following answer is not verified as authentic by the server:

mail.ru 21455 IN        SOA     ns.mail.ru hostmaster.mail.ru (

                        3209013119      ;serial (version)

                        300     ;refresh period

                        900     ;retry refresh this often

                        172800  ;expiration period

                        300     ;minimum TTL

                        )

For authoritative answers, see:

mail.ru 15127 IN        NS      ns.mail.ru

mail.ru 15127 IN        NS      ns1.mail.ru

mail.ru 15127 IN        NS      ns2.mail.ru

mail.ru 15127 IN        NS      ns3.mail.ru

mail.ru 15127 IN        NS      ns4.mail.ru

mail.ru 15127 IN        NS      ns5.mail.ru

Additional information:

ns.mail.ru      152885 IN       A       194.67.23.130

ns1.mail.ru     298788 IN       A       194.67.57.103

ns2.mail.ru     166579 IN       A       194.67.57.104

ns3.mail.ru     277104 IN       A       194.67.23.17

ns4.mail.ru     277104 IN       A       194.67.57.4

ns5.mail.ru     277104 IN       A       194.67.23.232

       


В последнем случае нам  даже явно рекомендуют обращаться за информацией на авторитетные серверы  и указывают их адреса. С опцией -v отчёт программы host(1) становится похож на отчёт dig(1) (см. ниже) и начинает повтрять синтаксис файла зоны.

dig(1)

Утилита dig(1) более «разговорчива». Одна из особенностей её отчётов состоит в том, что они даются сразу в формате файла зоны:

$ dig mail.ru

 

; <<>> DiG 8.3 <<>> mail.ru

;; res options: init recurs defnam dnsrch

;; got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9099

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6

;; QUERY SECTION:

;;      mail.ru, type = A, class = IN

 

;; ANSWER SECTION:

mail.ru.                1h56m42s IN A   194.67.57.26

 

;; AUTHORITY SECTION:

mail.ru.                4h21m12s IN NS  ns2.mail.ru.

mail.ru.                4h21m12s IN NS  ns3.mail.ru.

mail.ru.                4h21m12s IN NS  ns4.mail.ru.

mail.ru.                4h21m12s IN NS  ns5.mail.ru.

mail.ru.                4h21m12s IN NS  ns.mail.ru.

mail.ru.                4h21m12s IN NS  ns1.mail.ru.

 

;; ADDITIONAL SECTION:

ns.mail.ru.             1d18h37m10s IN A  194.67.23.130

ns1.mail.ru.            3d11h8m53s IN A  194.67.57.103

ns2.mail.ru.            1d22h25m24s IN A  194.67.57.104

ns3.mail.ru.            3d5h7m29s IN A  194.67.23.17

ns4.mail.ru.            3d5h7m29s IN A  194.67.57.4

ns5.mail.ru.            3d5h7m29s IN A  194.67.23.232

 

;; Total query time: 9 msec

;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2

;; WHEN: Wed Apr  5 14:37:57 2006

;; MSG SIZE  sent: 25  rcvd: 244

 

       


Символ ; в файле зоны является комментарием. Заметим, что мы не требовали от программы dig(1) информацию о серверах NS, и всё же он запросил её у сервера DNS. Разумеется, это не вся информация о зоне.

Запрос информации о записях SOA и MX.

$ dig MX mail.ru

 

; <<>> DiG 8.3 <<>> MX mail.ru

;; res options: init recurs defnam dnsrch

;; got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28695

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 7

;; QUERY SECTION:

;;      mail.ru, type = MX, class = IN

 

;; ANSWER SECTION:

mail.ru.                4h6m37s IN MX   10 mxs.mail.ru.

 

;; AUTHORITY SECTION:

mail.ru.                4h6m37s IN NS   ns2.mail.ru.

mail.ru.                4h6m37s IN NS   ns3.mail.ru.

mail.ru.                4h6m37s IN NS   ns4.mail.ru.

mail.ru.                4h6m37s IN NS   ns5.mail.ru.

mail.ru.                4h6m37s IN NS   ns.mail.ru.

mail.ru.                4h6m37s IN NS   ns1.mail.ru.

 

;; ADDITIONAL SECTION:

mxs.mail.ru.            2h4m39s IN A    194.67.23.20

ns.mail.ru.             1d18h22m35s IN A  194.67.23.130

ns1.mail.ru.            3d10h54m18s IN A  194.67.57.103

ns2.mail.ru.            1d22h10m49s IN A  194.67.57.104

ns3.mail.ru.            3d4h52m54s IN A  194.67.23.17

ns4.mail.ru.            3d4h52m54s IN A  194.67.57.4

ns5.mail.ru.            3d4h52m54s IN A  194.67.23.232

 

;; Total query time: 2 msec

;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2

;; WHEN: Wed Apr  5 14:52:31 2006

;; MSG SIZE  sent: 25  rcvd: 264

 

$ dig SOA mail.ru

 

; <<>> DiG 8.3 <<>> SOA mail.ru

;; res options: init recurs defnam dnsrch

;; got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59976

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6

;; QUERY SECTION:

;;      mail.ru, type = SOA, class = IN

 

;; ANSWER SECTION:

mail.ru.                5h51m47s IN SOA  ns.mail.ru. hostmaster.mail.ru. (

                                        3209013119      ; serial

                                        5M              ; refresh

                                        15M             ; retry

                                        2D              ; expiry

                                        5M )            ; minimum

 

 

;; AUTHORITY SECTION:

mail.ru.                4h6m19s IN NS   ns5.mail.ru.

mail.ru.                4h6m19s IN NS   ns.mail.ru.

mail.ru.                4h6m19s IN NS   ns1.mail.ru.

mail.ru.                4h6m19s IN NS   ns2.mail.ru.

mail.ru.                4h6m19s IN NS   ns3.mail.ru.

mail.ru.                4h6m19s IN NS   ns4.mail.ru.

 

;; ADDITIONAL SECTION:

ns.mail.ru.             1d18h22m17s IN A  194.67.23.130

ns1.mail.ru.            3d10h54m IN A   194.67.57.103

ns2.mail.ru.            1d22h10m31s IN A  194.67.57.104

ns3.mail.ru.            3d4h52m36s IN A  194.67.23.17

ns4.mail.ru.            3d4h52m36s IN A  194.67.57.4

ns5.mail.ru.            3d4h52m36s IN A  194.67.23.232

 

;; Total query time: 6 msec

;; FROM: aluminum.mccme.ru to SERVER: 62.117.108.2

;; WHEN: Wed Apr  5 14:52:50 2006

;; MSG SIZE  sent: 25  rcvd: 275

 

       


Для запроса к конкретному  серверу DNS его адрес необходимо предварять символом at:

$ dig mail.ru @194.67.23.130

 

; <<>> DiG 8.3 <<>> mail.ru @194.67.23.130

; (1 server found)

;; res options: init recurs defnam dnsrch

;; got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62910

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6

;; QUERY SECTION:

;;      mail.ru, type = A, class = IN

 

;; ANSWER SECTION:

mail.ru.                6H IN A         194.67.57.26

 

;; AUTHORITY SECTION:

mail.ru.                6H IN NS        ns.mail.ru.

mail.ru.                6H IN NS        ns1.mail.ru.

mail.ru.                6H IN NS        ns2.mail.ru.

mail.ru.                6H IN NS        ns4.mail.ru.

mail.ru.                6H IN NS        ns5.mail.ru.

mail.ru.                6H IN NS        ns3.mail.ru.

 

;; ADDITIONAL SECTION:

ns.mail.ru.             6H IN A         194.67.23.130

ns1.mail.ru.            6H IN A         194.67.57.103

ns2.mail.ru.            6H IN A         194.67.57.104

ns4.mail.ru.            6H IN A         194.67.57.4

ns5.mail.ru.            6H IN A         194.67.23.232

ns3.mail.ru.            6H IN A         194.67.23.17

 

;; Total query time: 91 msec

;; FROM: aluminum.mccme.ru to SERVER: 194.67.23.130

;; WHEN: Wed Apr  5 15:05:16 2006

;; MSG SIZE  sent: 25  rcvd: 244

 

       


Заметьте, что в этом запросе  размеры таймаутов стали более  «круглыми» — ровно по 6 часов. Причина в том, что мы задали вопрос авторитетному за эту зону серверу. Ответы, которые мы получали до сих пор мы брали из кешей неавторитетных серверов, поэтому в качестве TTL мы получали время указывающее на то, сколько осталось жить в кеше той или иной записи.

Давайте попробуем узнать с помощью команды dig(1) адреса серверов отвечающих за корневую зону (.) и время жизни записей о корневых серверах.

Информация о работе Отчёт о прохождении производственно-технологической практики на примере компании «СофтЛайн Трейд»