Новые книги

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

Книга написана коллективом авторов Финансовой академии при Правительстве РФ на основе собственных исследований и многочисленных консультаций с предпринимателями.

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

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

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

How DNS Works



Как работает DNS

DNS организует имена хостов по областям или доменам ( domain). Домен, это набор как-то связанных участков, это могут быть машины одной сети (например, все машины в университетском городке, или все хосты в BITNET), все они могут принадлежать определенной организации (типа американского правительства) или они просто географически близки. Например, университеты сгруппированы в домен edu, каждый университет или колледж использует отдельную подобласть, субдомен (subdomain), в которой и находятся все его хосты. Университету Groucho Marx принадлежит домен groucho.edu, его отделу математики maths.groucho.edu. Хост в сети добавляет свое имя к имени домена и таким образом получает свое полное имя в Internet: erdos был бы известен как erdos.maths.groucho.edu. Это называется полным доменным именем, fully qualified domain name (FQDN).

Так возникает древовидная структура. Запись в корне этого дерева, которая обозначена единственной точкой, весьма точно названа корневым доменом (root domain), и она связана со всеми другими доменами. Чтобы показать, что в данном месте пишется полное имя хоста, а не имя относительно локальной области, иногда после имени ставят точку. Это значит, что последний компонент имени принадлежит корневому домену.

В зависимости от местоположения в иерархии имени, домен может быть назван top-level, second-level или third-level (верхнего уровня, второго уровня или третьего уровня). Большее количество уровней встречается относительно редко. Вот несколько верхних областей, которые вы можете часто увидеть:

Домне Описание
edu

Образовательные учреждения, подобные университетам (главным образом США, хотя регистрироваться в этом домене могут ВУЗы любой страны).

com

Коммерческие организации, компании. В Москве много таких доменов.

org

Некоммерческие организации. Часто частные UUCP-сети находятся в этом домене. К конкретной стране не привязан.

net

Шлюзы и другие административные хосты в сети. Часто сетевые сервисы, справочники и т.п. Например, автор данной работы в свое время хотел зарегистрировать домен RussianLDP.net и отказался от этого лишь из-за оплаты домена. Но в последнее время в нем стало можно регистрировать имена за рекламу, так что, может, еще и соберусь...

mil

Американские военные учреждения.

gov

Американские правительственные учреждения (хотя в последнее время наметились сдвиги в плане того, чтобы сделать этот домен международным правительственным).

uucp

Официально, все имена сайтов, прежде используемые как UUCP-имена без доменов, были перемещены в этот домен.

ru

Российский национальный домен. Все машины с этим доменом находятся в России.

Технически первые четыре из них принадлежат американской части Internet, но там встречаются и не американские сайты. Это особенно верно для доменов .net и .org. Однако, .mil и .gov пока используются исключительно в США. Сейчас идут бурные дебаты о международных доменах.

Вне США каждая страна использует собственный домен, названный по имени страны и состоящий из двух букв определенных в ISO-3166. Финляндия, например, использует домен fi, fr используется Францией, de Германией, au Австралией и т.д.. Ниже этого высокопоставленного домена, NIC каждой страны может свободно раздавать имена хостам. Австралия, например, имеет домены второго уровня подобные международным доменам, названные com.au и edu.au . Другие, подобно Германии, не используют этот дополнительный уровень, но используют довольно длинные имена, которые непосредственно относятся к организациям, управляющим специфическим доменом, например, ftp.informatik.uni-erlangen.de.

Конечно, эти национальные домены (кроме России) не подразумевают, что хост, расположенный ниже, фактически расположен в той же стране. Это только сигнализирует, что хост регистрировался в NIC этой страны. Шведский изготовитель мог бы иметь отделение в Австралии, и все же регистрировать все хосты в домене se.

Теперь организация пространства имен в виде иерархии имен доменов приятно решает проблему уникальности имен: с DNS, имя хоста должно быть уникально только в пределах одной области (домена). Кроме того, полностью квалифицированные имена весьма легко запомнить. Но DNS делает не только это: он позволяет вам передать работу с подобластями местным администраторам. Например, администратор в вычислительном центре Groucho мог бы создать поддомен для каждого отдела: мы уже столкнулись с подобластями физиков и математиков. Когда он решит, что сеть в отделе физики слишком большая и хаотичная, чтобы справиться с ней, он может просто передать контроль над physics.groucho.edu администраторам этой сети, пусть у них головы поболят. Тогда они свободны использовать любые имена хостов и назначать их IP-адреса в пределах подсети без всякого вмешательства сверху.

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

Поиск имени с помощью DNS

На первый взгляд, вся эта суета с областями и зонами кажется делает поиск адреса ужасно сложным делом. В конце концов, если нет центрального органа, контролирующего, какие имена с каким адресом связаны, тогда как скромное приложение должно его узнавать?!

Фактически, DNS гигантская распределенная база данных. Это осуществлено посредством так называемых серверов имен (name server), которые снабжают всех информацией о данном домене или нескольких доменах сразу. Для каждой зоны имеются по крайней мере два сервера имен, которые содержат всю информацию относительно хостов в этой зоне. Чтобы получить IP-адрес erdos, все что вы должны сделать, это обратится к серверу имен зоны groucho.edu, который и передаст вам требуемые данные.

Легко сказать, а как это сделать? Как найти сервер имен в Groucho Marx? В случае если ваш компьютер не оборудован программой преобразования адресов, DNS также обеспечивает это. Когда ваше приложение хочет найти информацию относительно erdos, оно входит в контакт с местным сервером имен, который проводит так называемый итерационный опрос. Сначала он посылает запрос серверу имен корневого домена, спрашивая об адресе erdos.maths.groucho.edu. Сервер имен корня сообщает, что это имя не принадлежит зоне его полномочий, но вместо этого отсылает к домену edu. Таким образом, он предлагает вам войти в контакт с сервером имен edu для получения большего количества информации и прилагает список всех серверов имен edu вместе с их адресами. Ваш местный сервер имен пошлет запрос одному из них, например, a.isi.edu. Также как серверу имен корня, a.isi.edu знает, что люди groucho.edu управляют своей зоной сами, и направит вас на их сервера. Местный сервер имен запросит один из них, который, наконец, распознает имя, как принадлежащее к его зоне, и вернет IP-адрес.

Кажется, что для поиска одного IP-адреса тратится слишком много ресурсов, но это несравнимо меньше, чем при прежней схеме с файлом HOSTS.TXT. Но все еще имеются места для усовершенствования этой схемы.

Чтобы уменьшить время ответа для будущих запросов, сервер имен хранит полученную раньше информацию в кэше (cache). Так что в следующий раз, когда любой другой компьютер из вашей локальной сети захочет найти адрес хоста в домене groucho.edu, ваш сервер имен не проведет все снова, а будет сразу обращаться к серверу имен groucho.edu.

Конечно, сервер имен не будет хранить эту информацию всегда, а отбросит ее через некоторое время. Этот интервал времени назван time to live, (временем жизни) или TTL. TTL задается администратором каждой конкретной зоны.

Типы серверов имен

Сервера имен, которые содержат всю информацию относительно хостов в пределах данной зоны, названы авторитетными для этой зоны и иногда упоминаются как authoritative или master name servers. Любой запрос относительно хоста в пределах этой зоны будет в конце концов передан одному из этих серверов.

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

Одна из причин наличия нескольких серверов имен состoит в том, чтобы распределить груз работы, другая в надежности. Когда одна машина с сервером имен ломается, все запросы будут посылаться другим серверам. Конечно, эта схема не защищает Вас от сбоев сервера, при которых он отсылает неправильные ответы на все запросы DNS, например, от ошибок в программе сервера.

Конечно, вы можете также создать сервер имени, который не будет авторитетным для любого домена. Этот тип серверов используется, чтобы проверять запросы от местных приложений и кэшировать ответы. Поэтому его называют caching-only сервером.

База данных DNS

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

Единица информации в базе данных DNS названа записью ресурса (resource record) или RR. Каждая запись имеет свой тип, описывающий тип данных, которые в ней записаны, и определяющий тип сети, к которой она применяется. Последний используется при определении схемы адресации, вроде IP-адресов (IN класс), или адресов в Hesiod-сетях (используемые в MIT). Основной записью ресурсов является запись, которая связывает полное имя домена с IP-адресом.

Конечно, хост может иметь больше, чем одно имя. Например, сервер предоставляющий сервисы FTP и World Wide Web может иметь имена ftp.machine.org и www.machine.org. Однако, одно из этих имен должно быть определено как официальное или каноническое (canonical) имя хоста в то время, как остальные просто псевдонимы. Различие между ними в том, что каноническое имя хоста связано с А-записью в то время, как другие только с записью типа CNAME, которая указывает на каноническое имя хоста.

Я не буду приводить здесь все типы записей, а сделаю это позже, в другой главе, здесь же ограничусь кратким примером. Пример 6-4 показывает часть базы данных домена, которая загружена на сервере имен для зоны physics.groucho.edu.

Пример 6-4. Выдержка из файла named.hosts для отдела физики

; Authoritative Information on physics.groucho.edu.
@  IN  SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
                  1999090200       ; serial no
                  360000           ; refresh
                  3600             ; retry
                  3600000          ; expire
                  3600             ; default ttl
                }
;
; Name servers
              IN    NS       niels
              IN    NS       gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.23
;
; Theoretical Physics (subnet 12)
niels         IN    A        149.76.12.1
              IN    A        149.76.1.12
name server    IN    CNAME    niels
otto          IN    A        149.76.12.2
quark         IN    A        149.76.12.4
down          IN    A        149.76.12.5
strange       IN    A        149.76.12.6
...
; Collider Lab. (subnet 14)
boson         IN    A        149.76.14.1
muon          IN    A        149.76.14.7
bogon         IN    A        149.76.14.12
...

Кроме записей A и CNAME, Вы можете видеть специальную, занимающую несколько строк запись вверху файла. Это SOA-запись ресурса расшифровывается как Start of Authority (начало авторитета), которая содержит общую информацию относительно зоны, для которой этот сервер является авторитетным. Она включает, например, время жизни для всех записей.

Обратите внимание, что все имена в файле с примером, которые не заканчиваются точкой, интерпретируются относительно physics.groucho.edu. Специальное имя (@ ), используемое в записи SOA при обращении к имени данного домена.

Мы видели, что сервера имен для groucho.edu так или иначе должны знать хоть что-то относительно зоны физиков так, чтобы направлять запросы серверам имен. Это обычно достигается парой записей: NS-запись дает FQDN, и А-запись, ассоциирующая его имя с IP-адресом. Так как эти записи появляются вместе, они часто называются склеенными записями (glue records). Это фактически единственный случаи записи, в которой родительская зона держит информацию относительно хостов в зоне подчиненного. Склеенные записи, указывающие на сервера имен для physics.groucho.edu, показаны в примере 6-5.

Пример 6-5. Выдержка из файла named.hosts для GMU

; Zone data for the groucho.edu zone.
 @  IN  SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
                      1999070100       ; serial no
                      360000           ; refresh
                      3600             ; retry
                      3600000          ; expire
                      3600             ; default ttl
               }
 ....
 ;
 ; Glue records for the physics.groucho.edu zone
 physics        IN     NS        niels.physics.groucho.edu.
                IN     NS        gauss.maths.groucho.edu.
 niels.physics  IN     A         149.76.12.1
 gauss.maths    IN     A         149.76.4.23
 ...

Обратный поиск

После обнаружения IP-адреса, принадлежащего хосту, иногда желательно выяснить каноническое имя хоста, соответствующее данному адресу. Это называется reverse mapping (обратное отображение) и используется несколькими сервисами, чтобы проверить идентичность клиента. При использовании файла hosts, обратный поиск заключается просто в проверке этого файла. В DNS, конечно, не проводится просмотр всего адресного пространсва. Вместо этого создана специальная область in-addr.arpa, она содержит IP-адреса всех хостов в перевернутой записи. Например, IP-адрес 149.76.12.4 соответствует имени 4.12.76.149.in-addr.arpa. Тип записи ресурса, связывающий это имя с каноническим именем, называется PTR.

Создание зоны полномочий обычно означает, что ее администраторам дают полный контроль над тем, как назначать адреса и имена хостов. Так как они обычно управляют одной или более IP-сетями или подсетями, одна зона DNS может охватывать несколько IP-сетей. Отдел физики, например, включает подсети 149.76.8.0, 149.76.12.0 и 149.76.14.0.

Как следствие, новые зоны должны быть записаны в in-addr.arpa домена: 8.76.149.in-addr.arpa , 12.76.149.in-addr.arpa и 14.76.149.in-addr.arpa. Иначе, установка нового хоста в лаборатории Collider требовала бы обращения к родительской области, чтобы отметиться в ее файле in-addr.arpa . Зональная база данных для подсети 12 показана в примере 6-6. Соответствующие склеенные записи в базе данных зоны родителя показаны в примере 6-7.

Пример 6-6. Выдержка из файла named.rev для подсети 12

 ; the 12.76.149.in-addr.arpa domain.
 @  IN  SOA  niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
                      1999090200 360000 3600 3600000 3600
            }
 2        IN     PTR       otto.physics.groucho.edu.
 4        IN     PTR       quark.physics.groucho.edu.
 5        IN     PTR       down.physics.groucho.edu.
 6        IN     PTR       strange.physics.groucho.edu.

Пример 6-7. Выдержка из файла named.rev для сети 149.76

 ; the 76.149.in-addr.arpa domain.
 @  IN  SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
                      1999070100 360000 3600 3600000 3600
                  }
 ...
 ; subnet 4: Mathematics Dept.
 1.4        IN     PTR      sophus.maths.groucho.edu.
 17.4       IN     PTR      erdos.maths.groucho.edu.
 23.4       IN     PTR      gauss.maths.groucho.edu.
 ...
 ; subnet 12: Physics Dept, separate zone
 12         IN     NS       niels.physics.groucho.edu.
            IN     NS       gauss.maths.groucho.edu.
 niels.physics.groucho.edu. IN  A 149.76.12.1
 gauss.maths.groucho.edu. IN  A   149.76.4.23
 ...

Одно важное следствие этого то, что зоны могут создаваться только как наборы IP-сетей и даже более того, количество нулевых битов в маске подсети должно быть кратно 8. Все подсети в университете Groucho Marx имеют сетевую маску 255.255.255.0, так что зона in-addr.arpa может быть создана для каждой подсети. Однако, если сетевая маска будет 255.255.255.128, создание зон для подсети 149.76.12.128 будет невозможно, потому что нет никакого способа сообщить DNS, что область 12.76.149.in-addr.arpa была раздроблена на две зоны с именами хостов от 1 до 127 и от 128 до 255 соответственно.