Автор: Пользователь скрыл имя, 03 Октября 2012 в 01:41, отчет по практике
В процессе прохождения технологической практики мы должны получить достаточно полное представление о будущей профессии, а также понять взаимосвязь и направленность изучаемых по специальности дисциплин.
I. Введение
II. Сведения о компании «СофтЛайн Трейд»
О компании
История и развитие компании «СофтЛайн Трейд»
Цель компании
Softline – программное обеспечение, IT – сервисы, решения.
Компании разработчики ПО
Клиенты компании «СофтЛайн Трейд»
III. Задание и проделанная работа
Классификация сетевых протоколов
Запрос к DNS серверу
Настройка прямой и обратной зон
Синтаксис файла-зоны
Определение ответственного за DNS-зону
IV. Заключение
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
В приведённом примере браузер должен осуществить запрос с целью определить на каком сервере и на каком порту обслуживают злужбу 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. (
;; 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) адреса серверов отвечающих за корневую зону (.) и время жизни записей о корневых серверах.