DNS HOWTO Nicolai Langfeldt janl@math.uio.no, перевод Alex Ott ott@phtd.tpu.edu.ru v2.0.8, 25 Августа 1998 Как стать за короткое время администратором DNS. ______________________________________________________________________ Table of Contents 1. Преамбула 1.1 Официальная часть 1.2 Признательности и запрос о помощи 1.3 Посвящение 2. Введение 3. Настройка кеширующего сервера имен. 3.1 Запуск named 4. (EM 4.1 Но сначала некоторое количество сухой теории 4.2 Наш собственный домен 4.3 Обратная (reverse) зона 5. Пример реального домена 5.1 /etc/named.conf (или /var/named/named.conf) 5.2 /var/named/root.hints 5.3 /var/named/zone/127.0.0 5.4 /var/named/zone/land-5.com 5.5 /var/named/zone/206.6.177 6. Сопровождение 7. Преобразование настроек named из версии 4 в версию 8 8. Вопросы и ответы 9. Как стать более знающим администратором DNS. ______________________________________________________________________ ППррииммееччааннииее ппееррееввооддччииккаа:: Шлите мне любые комментарии и замечания, даже небольшие. 11.. ППррееааммббууллаа Ключевые слова: DNS, bind, bind-4, bind-8, named, dialup, ppp, slip, isdn, Internet, домен (domain), имя (name), сервера (hosts), разрешение имен (resolving) 11..11.. ООффииццииааллььннааяя ччаассттьь Авторские права (c) Nicolai Langfeldt, 1995. Не исправлять без изменения авторских прав, распространяется свободно при сохранении уведомления об авторских правах. 11..22.. ППррииззннааттееллььннооссттии ии ззааппрроосс оо ппооммоощщии Я хочу поблагодарить Arnt Gulbrandsen, который постоянно читает черновики этого документа и дает много советов и рекомендаций. Я также хочу поблагодарить людей, которые прислали мне свои предложения и замечания. Этот документ никогда не будет закончен, пожалуйста посылайте мне сообщения о ваших успехах и неудачах -- это сделает данный документ лучше. Также посылайте деньги, комментарии и/или вопросы на адрес janl@math.uio.no. Если вы посылаете сообщение и хотите получить ответ, то пожалуйста проявите вежливость и _у_б_е_д_и_т_е_с_ь, что обратный адрес является правильным и работает. Также ппоожжааллууййссттаа прочитайте раздел ``Вопросы и ответы'' до того как посылать сообщение. Если вы хотите перевести этот документ, то пожалуйста сообщите мне об этом, что бы я мог отслеживать на каких языках я был опубликован, и также чтобы я мог известить вас, когда этот документ будет обновлен. 11..33.. ППооссввяящщееннииее Этот документ посвящен Anne Line Norheim Langfeldt. Хотя она вероятно никогда его не прочитает, поскольку она не относится к классу девушек, увлеченных данной проблемой. 22.. ВВввееддееннииее ЧЧттоо ээттоо ттааккооее,, ии ччеемм ээттоотт ддооккууммееннтт ннее яяввлляяееттссяя Для начинающих, DNS -- это Доменная Система Имен (Domain Name System). DNS преобразует имена машин в IP-номера, которые являются адресами машин, она преобразует из имен в адреса и из адресов в имена. Этот документ показывает как определить такие преобразования, используя систему на базе Linux. Преобразование -- это просто создание ассоциации между двумя вещами, в нашем случае между именем машины, таким как ftp.linux.org, и номером IP этой машины, например 199.249.150.4. DNS является, для непосвященных (для вас ;-), одной из самых непрозрачных областей сетевого администрирования. Этот документ постарается сделать некоторые вещи понятнее. Здесь описывается как настроить _п_р_о_с_т_о_й сервер DNS. Начав с настройки кэширующего сервера, мы перейдем к настройке основного сервера DNS для домена. Для более сложных настроек вы можете посмотреть раздел ``Вопросы и ответы'' этого документа. Если он не описывает, то что вам нужно, то вам понадобится _п_р_о_ч_и_т_а_т_ь полную документацию. Я возвращусь к тому из чего состоит эта полная документация в ``последнкй главе''. До начала этого процесса, вы должны настроить вашу машину так, чтобы вы могли выполнять команду telnet на нее/с нее, и производить любые сетевые соединения, и вам совершенно необходимо иметь возможность выполнять команду telnet 127.0.0.1 и входить на свою собственную машину (протестируйте это сейчас!). Вам также необходимо иметь правильно настроенные файлы /etc/nsswitch.conf (или /etc/host.conf), /etc/resolv.conf и /etc/hosts, поскольку я не буду объяснять их функции в этом документе. Если работа сети у вас еще не настроена, то в _N_E_T_-_3_-_H_O_W_T_O и/или _P_P_P_-_H_O_W_T_O вам объяснят как это сделать. Прочитайте их. Когда я говорю `ваша машина' я подразумеваю ту машину, на которой вы пытаетесь настроить DNS. А ни какая другая машина, которую вы могли вовлечь в ваши сетевые эксперименты. Я предполагаю, что вы не находитесь за firewall любого типа, который блокирует запрос имен. Если вы все-таки находитесь за firewall, то вам необходима специальная настройка, смотрите раздел ``Вопросы и ответы''. В Unix задача разрешения имен выполняется программой, называемой named. Она является частью пакета bbiinndd, который сопровождается Paul Vixie для Internet Software Consortium. Named включен в большинство дистрибутивов Linux, и обычно устанавливается как /usr/sbin/named. Если у вас есть named, то вы вероятно сможете использовать его; Если у вас его нет, то вы можете получить исполняемые файлы с основных ftp серверов Linux, или взять последнюю и наилучшую версию исходных текстов с ftp.isc.org:/isc/bind/src/cur/bind-8/. Этот документ описывает bind версии 8. Старые версии этого документа, описывающие bind версии 4, еще доступны по адресу http://www.math.uio.no/~janl/DNS/, в том случае, если вы используете bind 4. Если справочная страница named ссылается на файл named.conf, то у вас стоит bind 8, если она ссылается на named.boot, то у вас bind 4. Если у вас установлен bind версии 4 и вы ососзнаете необходимость сохранения безопасности, то вы действительно должны обновить вашу версию до версии 8. DNS является базой данных во всемирной сети. Поэтому заботьтесь о том, что вы помещаете в нее. Если вы будете помещать в нее всякий хлам, то и вы и другие люди также получат всякий хлам. Храните вашу базу DNS в аккуратности и вы получите хорошее обслуживание с ее стороны. Учитесь как использовать ее, администрировать и отлаживать, и вы будете еще одним хорошим администратором, хранящим сеть от сбоев в результате неумелого управления. В этом документе я констатирую набор вещей, которые в самом деле не являются полностью правильными (они являются по крайней мере наполовину правильными). Все это сделано в целях упрощения. Эти вещи (вероятно ;-) будут работать, если вы поверите, тому что я скажу. ССооввеетт:: Сделайте резервные копии всех файлов, которые я буду советовать изменить, если у вас они уже есть, так что если ничего не будет работать, то вы можете вернуться назад к рабочей конфигурации. 33.. ННаассттррооййккаа ккеешшииррууюющщееггоо ссееррввеерраа ииммеенн.. ЭЭттоо ппееррввыыйй шшаагг вв ннаассттррооййккее DDNNSS,, ооччеенньь ппооллееззнныыйй ддлляя ddiiaalluupp ппооллььззооввааттееллеейй Кеширующий сервер найдет ответ на запрос об имени машины и запомнит его, чтобы ответить, когда вы запросите эту же информацию в следующий раз. Это значительно уменьшит время ожидания ответа при следующем запросе, особенно если у вас медленное соединение. Ддя начала вам нужен файл, названный /etc/named.conf. Из него named читает информацию при старте. Сейчас он должен просто содержать следующие строки: ______________________________________________________________________ // Файл настроек для только кеширующего сервера options { directory "/var/named"; // Раскомментируйте следующую строку, если вы // работаете через firewall и система не работает: // query-source address * port 53; }; zone "." { type hint; file "root.hints"; }; zone "0.0.127.in-addr.arpa" { type master; file "pz/127.0.0"; }; ______________________________________________________________________ Строка `directory' задает где искать файлы. Все файлы используемые впоследствии, будут именоваться относительно этой директории. Таким образом pz -- это директория в директории /var/named, т.е., /var/named/pz. /var/named -- это правильная директория согласно _L_i_n_u_x _F_i_l_e _s_y_s_t_e_m _S_t_a_n_d_a_r_d _(_С_т_а_н_д_а_р_т_у _ф_а_й_л_о_в_о_й _с_и_с_т_е_м_ы _L_i_n_u_x_). Файл названный /var/named/root.hints должен находится в указанной директории. Он должен содержать следующую информацию: ______________________________________________________________________ . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 ______________________________________________________________________ Этот файл описывает имена корневых серверов имен по всему миру. Их список изменяется время от времени и эта часть в дальнейшем _д_о_л_ж_н_а сопровождаться. Смотрите ``раздел по сопровождению'' для того, чтобы узнать как хранить эту информацию соответсвующей действительности. Следующий раздел в named.conf -- это последняя зона. Я объясню как она используется в следующих разделах, сейчас просто создайте файл, названный 127.0.0 в поддиректории pz: ______________________________________________________________________ @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 1 ; Serial 8H ; Refresh 2H ; Retry 1W ; Expire 1D) ; Minimum TTL NS ns.linux.bogus. 1 PTR localhost. ______________________________________________________________________ Далее вам необходимо, чтобы ваш файл /etc/resolv.conf выглядел примерно так: ______________________________________________________________________ search subdomain.your-domain.edu your-domain.edu nameserver 127.0.0.1 ______________________________________________________________________ Строка `search' задает в каких доменах должен идти поиск машин с кокторыми вы хотите соединиться. Строка `nameserver' указывает адрес вашего сервера имен, в нашем случае это ваша собственная машина, поскольку на ней запущен named (127.0.0.1 это правильный адрес, также никаких проблем, если ваша машина имеет другой адрес). Если вы хотите перечислите несколько серверов имен, то поместите их по одному в строку со словом `nameserver' для каждого. (Замечание: Named никогда не читает этот файл, это делает программа resolver, которая использует named). Проиллюстрируем как это работает: Если клиент пытается найти машину с именем foo, то сначала программа пытается найти машину с полным именем foo.subdomain.your-domain.edu, затем с именем foo.your-fomain.edu, и в конце концов foo. Если клиент пытается найти sunsite.unc.edu, то сначала пробуется sunsite.unc.edu.subdomain.your-domain.edu (да это глупо, но вот так это работает), затем sunsite.unc.edu.your- domain.edu, и в конце концов sunsite.unc.edu. Вы можете не помещать слишком много доменов в строку поиска, поскольку поиск в них займет слишком много времени. Пример предполагает, что вы находитесь в домене subdomain.your- domain.edu, и ваша машина вероятно называется your- machine.subdomain.your-domain.edu. Строка поиска не должна содержать ваш TLD (Top Level Domain (Домен Верхнего Уровня), `edu' в нашем случае). Если вам необходимо часто соединяться с машиной в другом домене, то вы можете добавить этот домен в строку поиска, примерно вот так: ______________________________________________________________________ search subdomain.your-domain.edu your-domain.edu other-domain.com ______________________________________________________________________ и так далее. Очевидно, что вам необходимо поместить в эту строку имена настоящих доменов, вместо вышеприведенных. Пожалуйста заметьте отсутствие точки в конце имени домена. Далее в зависимости от вашей версии libc вам необходимо вносить исправления либо в файл /etc/nsswitch.conf, либо в файл /etc/host.conf. Если у вас уже есть файл nsswitch.conf, то значит мы будем вносить исправления в него, если же его нет, то мы будем вносить изменения в файл host.conf. //eettcc//nnsssswwiittcchh..ccoonnff Это длинный файл описывающий как получить разные типы данных, из какого файла или базы данных. В начале он обычно содержит полезные комментарии, которые вы должны учесть при чтении этого файла. После того, как вы найдете строку начинающуюся с `hosts:', вы должны увидеть: ______________________________________________________________________ hosts: files dns ______________________________________________________________________ Если в этом файле нет строки начинающейся с `hosts:', то поместите вышеприведенную строку в файл. Эта строка указывает программам сначала выполнять поиск в файле /etc/hosts, а затем просматривать DNS в соответствии с порядком указаном в файле resolv.conf. //eettcc//hhoosstt..ccoonnff Этот файл вероятно содержит разные данные, одна из строк должна начинаться со слова order и выглядеть примерно так: ______________________________________________________________________ order hosts,bind ______________________________________________________________________ Если строки с `order' нет, то вы должны ее вставить. Она заставляет подпрограмму разрешения имен сначала посмотреть в файле /etc/hosts, а затем сделать запрос к серверу имен (который в resolv.conf указан как машина с адресом 127.0.0.1). Эти два последних файла описаны в разделе (8) справочной системы (выполните команду `man 8 resolv') в большинстве дистрибутивов Linux. По моему мнению это вполне читаемая справочная страница, и каждый человек, особенно администраторы DNS, должны прочитать ее хотя бы раз. Сделайте это сейчас! Если вы скажете себе "я сделаю это позже", то вы никогда это не сделаете. 33..11.. ЗЗааппуусскк nnaammeedd После этих приготовлений пришло время запуска named. Если вы используете dialup соединение, то сначала произведите подключение. Наберите `ndc start' без опций, и нажмите клавишу return. Если никакого результата нет, то попробуйте следующую команду `/usr/sbin/ndc start'. Если опять попытка не удалась, то смотрите раздел ``Вопросы и ответы''. Теперь мы можем протестировать нашу настройку. Если вы посмотрите в файл сообщений syslog (обычно названный /var/adm/messages, но может быть другая директория /var/log и другой файл syslog в которые необходимо посмотреть) во время запуска named (выполните команду tail -f /var/log/messages), то вы должны увидеть что-то подобное следующему: (строки заканчивающиеся на \ продолжаются на следующей строке) Feb 15 01:26:17 roke named[6091]: starting. named 8.1.1 Sat Feb 14 \ 00:18:20 MET 1998 ^Ijanl@roke.uio.no:/var/tmp/bind-8.1.1/src/bin/named Feb 15 01:26:17 roke named[6091]: cache zone "" (IN) loaded (serial 0) Feb 15 01:26:17 roke named[6091]: master zone "0.0.127.in-addr.arpa" \ (IN) loaded (serial 1) Feb 15 01:26:17 roke named[6091]: listening [127.0.0.1].53 (lo) Feb 15 01:26:17 roke named[6091]: listening [129.240.230.92].53 (ippp0) Feb 15 01:26:17 roke named[6091]: Forwarding source address is [0.0.0.0].1040 Feb 15 01:26:17 roke named[6092]: Ready to answer queries. Если есть какие-нибудь сообщения об ошибках, то значит вы что-то сделали неправильно. Named укажет в каком файле ошибка (я надеюсь, что это один из файлов named.conf и root.hints :-). Завершите выполнение named и проверьте файлы конфигурации. Теперь пора запустить nslookup и проверить результаты вашей работы. $ nslookup Default Server: localhost Address: 127.0.0.1 > Если это выглядит так, то значит вы заставили систему работать. Мы так надеемся. Если что-то другое, то вернитесь назад и все проверьте. Каждый раз когда вы изменяете файл named.conf, вам необходимо перезапустить named, используя команду ndc restart. Теперь мы можем ввести запрос на поиск информации. Попробуйте найти машину близкую к вам. pat.uio.no находится близко от меня, в Университете Осло: > pat.uio.no Server: localhost Address: 127.0.0.1 Name: pat.uio.no Address: 129.240.130.16 Сейчас nslookup попросит ваш named посмотреть информацию о машине pat.uio.no. Затем он соединится с одним из серверов имен, перечисленных в вашем файле root.hints, и запросит у него путь к данной машине. Это может занять какое-то время, до того как вы получите результаты, поскольку система сначала ищет заданную машину во всех доменах перечисленных в вашем файле /etc/resolv.conf. Если вы запросите то же самое, то вы получите такой ответ: > pat.uio.no Server: localhost Address: 127.0.0.1 Non-authoritative answer: Name: pat.uio.no Address: 129.240.2.50 Заметим, что мы в это раз получили сообщение `Non-authoritative answer:'. Это означает, что named в этот раз не делал запрос к внешним серверам имен, а вместо этого произвел поиск в своем кеше и нашел там ответ. Но кешированная информация может быть устаревшей. Так что он вас информируют об этой (весьма незначительной) опасности сообщением `Non-authorative answer:'. nslookup выдает это сообщение, когда вы второй раз запрашиваете об одной и той же машине -- это знак того, что named кеширует информацию и это значит, что он работает правильно. Вы можете завершить работу nslookup дав команду `exit'. Теперь вы знаете как установить кеширующий сервер имен. Возьмите пива, молока или того, что вы предпочитаете и отпразднуйте это. 44.. ППррооссттоойй ддооммеенн.. ККаакк ууссттааннооввииттьь ссввоойй ссооббссттввеенннныыйй ддооммеенн 44..11.. ННоо ссннааччааллаа ннееккооттооррооее ккооллииччеессттввоо ссууххоойй ттееооррииии До того как мы в _д_е_й_с_т_в_и_т_е_л_ь_н_о_с_т_и начнем этот раздел, я хочу дать вам некоторые теоретические сведения о том как работает DNS. И вы должны читать дальше, потому что это полезно для вас. Если вы не `хотите' делать это, то вы по крайней мере должны быстро просмотреть его. Остановитесь, когда вы увидите указания о том, что вы должны делать с вашим файлом named.conf. DNS -- это иерархическая система. Вершина записывается как `.' и произносится как `root (корень)'. В . существует некоторое количество Доменов верхнего уровня (Top Level Domains, TLDs), наиболее известными из которых являются ORG, COM, EDU и NET, но на самом деле их намного больше. При поиске машины, запрос обрабатывается рекурсивно, начиная с корня. Если вы хотите найти адрес машины prep.ai.mit.edu, то ваш сервер имен должен найти сервер имен, который обслуживает edu. Он запрашивает корневой сервер (.) (он уже знает корневые . сервера -- они перечислены в файле root.hints), корневой сервер . дает список серверов edu: $ nslookup Default Server: localhost Address: 127.0.0.1 Запросите корневой сервер: > server c.root-servers.net. Default Server: c.root-servers.net Address: 192.33.4.12 Установите тип запроса (Query type) в NS (записи о серверах имен): > set q=ns Запросите его о edu: > edu. Заключительная точка . очень важна, она сообщает серверу, что мы запрашиваем о edu находящемся прямо под корневым сервером . (это ограничивает поиск). edu nameserver = A.ROOT-SERVERS.NET edu nameserver = H.ROOT-SERVERS.NET edu nameserver = B.ROOT-SERVERS.NET edu nameserver = C.ROOT-SERVERS.NET edu nameserver = D.ROOT-SERVERS.NET edu nameserver = E.ROOT-SERVERS.NET edu nameserver = I.ROOT-SERVERS.NET edu nameserver = F.ROOT-SERVERS.NET edu nameserver = G.ROOT-SERVERS.NET A.ROOT-SERVERS.NET internet address = 198.41.0.4 H.ROOT-SERVERS.NET internet address = 128.63.2.53 B.ROOT-SERVERS.NET internet address = 128.9.0.107 C.ROOT-SERVERS.NET internet address = 192.33.4.12 D.ROOT-SERVERS.NET internet address = 128.8.10.90 E.ROOT-SERVERS.NET internet address = 192.203.230.10 I.ROOT-SERVERS.NET internet address = 192.36.148.17 F.ROOT-SERVERS.NET internet address = 192.5.5.241 G.ROOT-SERVERS.NET internet address = 192.112.36.4 Это дает нам информацию о том, что *.root-servers.net обслуживают edu., так что мы можем продолжать опрашивать сервер c. Теперь мы хотим знать кто обслуживает следующий уровень имени домена: mit.edu.: > mit.edu. Server: c.root-servers.net Address: 192.33.4.12 Non-authoritative answer: mit.edu nameserver = W20NS.mit.edu mit.edu nameserver = BITSY.mit.edu mit.edu nameserver = STRAWB.mit.edu Authoritative answers can be found from: W20NS.mit.edu internet address = 18.70.0.160 BITSY.mit.edu internet address = 18.72.0.3 STRAWB.mit.edu internet address = 18.71.0.151 Сервера steawb, w20ns и bitsy обслуживают mit, выберите один из них и запросите у него информацию о ai.mit.edu: > server W20NS.mit.edu. Имена машин не зависят от регистра, но я просто использую мышь для вырезания и вставки текста, так что я получаю их такими же, как они написаны на экране. Server: W20NS.mit.edu Address: 18.70.0.160 > ai.mit.edu. Server: W20NS.mit.edu Address: 18.70.0.160 Non-authoritative answer: ai.mit.edu nameserver = ALPHA-BITS.AI.MIT.EDU ai.mit.edu nameserver = GRAPE-NUTS.AI.MIT.EDU ai.mit.edu nameserver = TRIX.AI.MIT.EDU ai.mit.edu nameserver = MUESLI.AI.MIT.EDU ai.mit.edu nameserver = LIFE.AI.MIT.EDU ai.mit.edu nameserver = BEET-CHEX.AI.MIT.EDU ai.mit.edu nameserver = MINI-WHEATS.AI.MIT.EDU ai.mit.edu nameserver = COUNT-CHOCULA.AI.MIT.EDU ai.mit.edu nameserver = MINTAKA.LCS.MIT.EDU Authoritative answers can be found from: AI.MIT.EDU nameserver = ALPHA-BITS.AI.MIT.EDU AI.MIT.EDU nameserver = GRAPE-NUTS.AI.MIT.EDU AI.MIT.EDU nameserver = TRIX.AI.MIT.EDU AI.MIT.EDU nameserver = MUESLI.AI.MIT.EDU AI.MIT.EDU nameserver = LIFE.AI.MIT.EDU AI.MIT.EDU nameserver = BEET-CHEX.AI.MIT.EDU AI.MIT.EDU nameserver = MINI-WHEATS.AI.MIT.EDU AI.MIT.EDU nameserver = COUNT-CHOCULA.AI.MIT.EDU AI.MIT.EDU nameserver = MINTAKA.LCS.MIT.EDU ALPHA-BITS.AI.MIT.EDU internet address = 128.52.32.5 GRAPE-NUTS.AI.MIT.EDU internet address = 128.52.36.4 TRIX.AI.MIT.EDU internet address = 128.52.37.6 MUESLI.AI.MIT.EDU internet address = 128.52.39.7 LIFE.AI.MIT.EDU internet address = 128.52.32.80 BEET-CHEX.AI.MIT.EDU internet address = 128.52.32.22 MINI-WHEATS.AI.MIT.EDU internet address = 128.52.54.11 COUNT-CHOCULA.AI.MIT.EDU internet address = 128.52.38.22 MINTAKA.LCS.MIT.EDU internet address = 18.26.0.36 Так что museli.ai.mit.edu является сервером имен для ai.mit.edu: > server MUESLI.AI.MIT.EDU Default Server: MUESLI.AI.MIT.EDU Address: 128.52.39.7 Теперь я изменил тип запроса, поскольку мы нашли сервер имен и можем опрашивать его том, что мы хотим знать о prep.ai.mit.edu. > set q=any > prep.ai.mit.edu. Server: MUESLI.AI.MIT.EDU Address: 128.52.39.7 prep.ai.mit.edu CPU = dec/decstation-5000.25 OS = unix prep.ai.mit.edu inet address = 18.159.0.42, protocol = tcp ftp telnet smtp finger prep.ai.mit.edu preference = 1, mail exchanger = gnu-life.ai.mit.edu prep.ai.mit.edu internet address = 18.159.0.42 ai.mit.edu nameserver = beet-chex.ai.mit.edu ai.mit.edu nameserver = alpha-bits.ai.mit.edu ai.mit.edu nameserver = mini-wheats.ai.mit.edu ai.mit.edu nameserver = trix.ai.mit.edu ai.mit.edu nameserver = muesli.ai.mit.edu ai.mit.edu nameserver = count-chocula.ai.mit.edu ai.mit.edu nameserver = mintaka.lcs.mit.edu ai.mit.edu nameserver = life.ai.mit.edu gnu-life.ai.mit.edu internet address = 128.52.32.60 beet-chex.ai.mit.edu internet address = 128.52.32.22 alpha-bits.ai.mit.edu internet address = 128.52.32.5 mini-wheats.ai.mit.edu internet address = 128.52.54.11 trix.ai.mit.edu internet address = 128.52.37.6 muesli.ai.mit.edu internet address = 128.52.39.7 count-chocula.ai.mit.edu internet address = 128.52.38.22 mintaka.lcs.mit.edu internet address = 18.26.0.36 life.ai.mit.edu internet address = 128.52.32.80 Так начиная от корня ., мы нашли нужные сервера имен для каждого уровня, указанных в имени домена. Если бы вы использовали ваш собственный сервер DNS вместо использования всех перечисленных серверов, то ваш сервер конечно же кешировал бы всю информацию, которую он находил во время прохождения этого пути, и тогда бы он больше не запрашивал эту информацию при повторном обращении. Менее обсуждаемым, но все равно важным является домен in-addr.arpa. Он также имеет иерархическую структуру, подобно `обычным' доменам. in- addr.arpa позволяет нам получить имя машины, по ее адресу. Необходимо заметить, то что ip-адреса в домене in-addr.arpa записаны в обратном порядке. Например, Если у вас есть машина с адресом: 192.128.52.43, то named обрабатывает ее точно также как в примере для prep.ai.mit.edu: находит сервера arpa.. Находит сервера для домена in-addr.arpa., находит сервера 192.in-addr.arpa., находит сервера для 128.192.in- addr.arpa., сервера для 52.128.192.in-addr.arpa.. А потом уже находит необходимые записи о 43.52.128.192.in-addr.arpa. Ловко? (скажите 'да'). Хотя обратный порядок может смущать, но это только первые два года. Я вам солгал. DNS не работает точно так, как я это описал. Но достаточно близко к описанному процессу. 44..22.. ННаашш ссооббссттввеенннныыйй ддооммеенн Теперь определим наш собственный домен. Мы будем делать домен _l_i_n_u_x_._b_o_g_u_s и определим машины в нем. Я использую полностью поддельное имя домена, для того чтобы быть уверенным, что мы не побеспокоим никого во внешнем мире. Одно важное замечание до того как мы начнем: Не все символы разрешено использовать в именах машин. Мы ограничимся символами английского алфавита: a-z, цифрами: 0-9 и символом '-' (тире). Придерживайтесь сипользования этих символов. Прописные и строчные символы не различаются DNS, так что pat.uio.no является равным Pat.UiO.No. Мы уже начали эту часть строкой в named.conf: ______________________________________________________________________ zone "0.0.127.in-addr.arpa" { type master; file "pz/127.0.0"; }; ______________________________________________________________________ Заметьте отсутствие `.' в конце имен доменов в этом файле. Это указывает, что мы сейчас будем определять зону 0.0.127.in-addr.arpa, и что мы будем основным сервером для нее, а также то, что она хранится в файле, названном pz/127.0.0. Мы уже сделали этот файл, в нем записано: ______________________________________________________________________ @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 1 ; Serial 8H ; Refresh 2H ; Retry 1W ; Expire 1D) ; Minimum TTL NS ns.linux.bogus. 1 PTR localhost. ______________________________________________________________________ Заметьте наличие символа `.' в конце полных имен доменов в этом файле, в противоположность вышеприведенному файлу named.conf. Некоторые люди любят начинать каждый файл зон с директивы $ORIGIN, но это является излишним. Расположение (origin) (место зоны в иерархии DNS) файла зоны указывается в разделе зон в файле named.conf, в данном случае это 0.0.127.in-addr.arpa. Этот `файл зоны' содержит 3 `записи ресурсов (resource records)' (RRs): A SOA RR, A NS RR и PTR RR. SOA это сокращение для Начала Полномочий (Start Of Authority). Символ `@' это специальный символ обозначающий расположение, и поскольку в колонке `домен (domain)' для этого файла записано 0.0.127.in-addr.arpa, то первая строка на самом деле значит 0.0.127.in-addr.arpa. IN SOA ... NS это RR для сервера имен (Name Server). В начале строки символ '@' не указывается, это _п_о_д_р_а_з_у_м_е_в_а_е_т_с_я, поскольку предыдущая строка начиналась с символа '@'. Это съэкономит нам несколько нажатий на клавиши. Так что строка NS в действительности читается как 0.0.127.in-addr.arpa. IN NS ns.linux.bogus Эта строка сообщает DNS, что машина является сервером имен домена 0.0.127.in-addr.arpa, это ns.linux.bogus. 'ns' традиционное имя для серверов имен, но как и для web-серверов, чьим традиционным именем является www._ч_т_о_-_н_и_б_у_д_ь, данное имя может быть любым. И в в окончание - запись PTR гласит, что машина с адресом 1 в подсети 0.0.127.in-addr.arpa, например, 127.0.0.1 называется localhost. Запись SOA находится в преамбуле каждого из файлов зон, и она должна первой записью в файле. Она описывает зону -- откуда она появляется (машина, названная ns.linux.bogus), кто отвечает за содержимое зоны (hostmaster@linux.bogus), какая версия файла зоны текущая (serial: 1), и другие вещи, которые надо сделать для кеширующих и вторичных серверов DNS. Для полей refresh, retry, expire и minimum используйте числа приведенные в этом документе и вы должны быть в безопасности, используя их. Затем перезапустите ваш named (команда ndc restart) и используйте программу nslookup для проверки того, что сделано: $ nslookup Default Server: localhost Address: 127.0.0.1 > 127.0.0.1 Server: localhost Address: 127.0.0.1 Name: localhost Address: 127.0.0.1 мы видим, что named работает и можно получить данные о localhost из домена 127.0.0.1, это очень хорошо. Теперь приступим к нашей основной задаче, домену linux.bogus, вставим новый раздел '(zone)' в файл named.conf: ______________________________________________________________________ zone "linux.bogus" { notify no; type master; file "pz/linux.bogus"; }; ______________________________________________________________________ Заметим, что мы опять не написали завершающий символ `.' в имени домена в файле named.conf. В файле зоны linux.bogus мы поместим некоторые поддельные данные: ______________________________________________________________________ ; ; Файл зоны для linux.bogus ; ; Полный файл зоны ; @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 1W ; expire, seconds 1D ) ; minimum, seconds ; NS ns ; Internet адрес сервера имен MX 10 mail.linux.bogus ; Основной почтовый сервер MX 20 mail.friend.bogus. ; Дополнительный почтовый сервер ; localhost A 127.0.0.1 ns A 192.168.196.2 mail A 192.168.196.4 ______________________________________________________________________ Необходимо упомянуть две вещи о записи SOA. ns.linux.bogus _д_о_л_ж_е_н быть настоящей машиной с записью A. Не разрешается указывать машину с записью CNAME в записи SOA. Это имя не обязательно должно быть `ns', оно может быть любым правильным именем машины. Далее, hostmaster.linux.bogus должен читаться как hostmaster@linux.bogus, это должен быть почтовый псевдоним или почтовый ящик для человека сопровождающего DNS и читающего почту достаточно часто. Любая почта, относительно домена будет посылаться на адрес указаный здесь. Имя не обязательно должно быт `hostmaster', это может быть любой правильный адрес электронной почты, но адрес с именем `hostmaster' как ожидается будет работать. В этом файле приведен еще один новый тип записи о ресурсах (RR) -- MX, или запись ресурса Почтовый Сервер (Mail eXchanger). Она сообщает почтовой системе куда посылать почту адресованную someone@linux.bogus, а именно серверам mail.linux.bogus или mail.friend.bogus. Число перед каждым именем машины -- это приоритет записи MX RR. Запись ресурса с наименьшим номером (10) -- это машины куда почта должна посылаться в первую очередь. Если происходит ошибка, то почта может быть послана на машину с большим номером, вторичному почтовому серверу, например, mail.friend.bogus для которого приоритет установлен равным 20. Перезапустите named с помощью команды ndc restart. Проверьте результаты работы используя команду nslookup: $ nslookup > set q=any > linux.bogus Server: localhost Address: 127.0.0.1 linux.bogus origin = ns.linux.bogus mail addr = hostmaster.linux.bogus serial = 199802151 refresh = 28800 (8 hours) retry = 7200 (2 hours) expire = 604800 (7 days) minimum ttl = 86400 (1 day) linux.bogus nameserver = ns.linux.bogus linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus linux.bogus preference = 20, mail exchanger = mail.friend.bogus linux.bogus nameserver = ns.linux.bogus ns.linux.bogus internet address = 192.168.196.2 mail.linux.bogus internet address = 192.168.196.4 При внимательном тестировании вы обнаружите ошибку. Строка linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus является полностью неправильной. Она должна выглядеть следующим образом linux.bogus preference = 10, mail exchanger = mail.linux.bogus Я сознательно сделал ошибку, чтобы вы смогли получить некоторый опыт --:-) Глядя в файл зоны мы обнаружим, что в строке MX 10 mail.linux.bogus ; Основной почтовый сервер отсутствует точка. Или лишний раз написано 'linux.bogus'. Если имя машины не заканчивается на символ точки в файле зоны, то к концу этого имени добавляется текущее расположение (origin), вызывая в итоге дублирование текста linux.bogus.linux.bogus. Так запись ______________________________________________________________________ MX 10 mail.linux.bogus. ; Основной почтовый сервер ______________________________________________________________________ или ______________________________________________________________________ MX 10 mail ; Основной почтовый сервер ______________________________________________________________________ является правильной. Я предпочитаю последнюю форму, поскольку надо меньше набирать на клавиатуре. Существуют пользователи bind, которые не согласны с этим подходом, но есть и те, которые согласны с этим. В файле зоны имя домена должно быть написано и закачиваться на символ `.' или домен не должен быть указан, в этом случае по умолчанию доменом будет текущее расположение (origin) машины. Я должен подчеркнуть, что в файле named.conf _н_е _д_о_л_ж_н_о быть символа `.' после имен доменов. У вас может не быть понятия про символ `.' -- это слишком часто или наоборот слишком редко заполняет разные вещи и смущает много людей. Так что опираясь на мою точку зрения мы напишем новый файл зоны, с некоторой дополнительной информацией. ______________________________________________________________________ ; ; Файл зоны для linux.bogus ; ; Полный файл зоны ; @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 1W ; expire, seconds 1D ) ; minimum, seconds ; TXT "Linux.Bogus, your DNS consultants" NS ns ; Internet адрес сервера имен NS ns.friend.bogus. MX 10 mail.linux.bogus ; Основной почтовый сервер MX 20 mail.friend.bogus. ; Дополнительный почтовый сервер localhost A 127.0.0.1 gw A 192.168.196.1 HINFO "Cisco" "IOS" TXT "The router" ns A 192.168.196.2 MX 10 mail MX 20 mail.friend.bogus. HINFO "Pentium" "Linux 2.0" www CNAME ns donald A 192.168.196.3 MX 10 mail MX 20 mail.friend.bogus. HINFO "i486" "Linux 2.0" TXT "DEK" mail A 192.168.196.4 MX 10 mail MX 20 mail.friend.bogus. HINFO "386sx" "Linux 1.2" ftp A 192.168.196.5 MX 10 mail MX 20 mail.friend.bogus. HINFO "P6" "Linux 2.1.86" ______________________________________________________________________ Здесь присутствует несколько новых записей о ресурсах (RR): запись HINFO (Информация о машине, Host INFOrmation) имеет две части, хорошей привычкой является заключение каждой из этих частей в кавычки. Первая часть -- это информация об оборудовании машины, а вторая часть описывает программное обеспечение и операционную систему данной машины. Машина, названная 'ns', имеет процессор Pentium и работает под управлением Linux 2.0. CNAME (Каноническое имя, Canonical NAME) -- это способ присвоить каждой машине несколько имен. Так, что www является алиасом для ns. Использование записи CNAME является немного неоднозначным. Но безопасным способом будет следовать правилу, что записи MX, CNAME или SOA _н_и_к_о_г_д_а не должны ссылаться на имя, указанное как запись CNAME, они должны ссылаться на имя определенное записью A, так что будет неправильно записать ______________________________________________________________________ foobar CNAME www ; NO! ______________________________________________________________________ но вместо этого необходимо записать ______________________________________________________________________ foobar CNAME ns ; Yes! ______________________________________________________________________ Также лучше считать, что запись CNAME не является настоящим именем машины для использования в адресе электронной почты: адрес webmaster@www.linux.bogus является неправильным адресом электронной почты. Вы можете ожидать, что некоторые администраторы электронной почты во внешнем мире следят за моблюдением этого правила, даже если у вас все работает нормально. Для того, чтобы избежать этого используйте запись A (и возможно также некоторые другие записи, такие как MX) вместо: ______________________________________________________________________ www A 192.168.196.2 ______________________________________________________________________ Некоторые из разработчиков архитектуры bind (arch-bind-wizards), рекомендуют _н_е использовать запись CNAME. Так, что ее использование надо рассматривать серьезно. Но как вы видите, этот документ также как и множество других серверов не следуют этому правилу. Загрузите новую базу данных выполнив команду ndc reload, это заставит named перечитать файлы зон заново. $ nslookup Default Server: localhost Address: 127.0.0.1 > ls -d linux.bogus Это означает, что должны быть перечислены все записи в данном домене. В результате получится следующее: [localhost] $ORIGIN linux.bogus. @ 1D IN SOA ns hostmaster ( 199802151 ; serial 8H ; refresh 2H ; retry 1W ; expiry 1D ) ; minimum 1D IN NS ns 1D IN NS ns.friend.bogus. 1D IN TXT "Linux.Bogus, your DNS consultants" 1D IN MX 10 mail 1D IN MX 20 mail.friend.bogus. gw 1D IN A 192.168.196.1 1D IN HINFO "Cisco" "IOS" 1D IN TXT "The router" mail 1D IN A 192.168.196.4 1D IN MX 10 mail 1D IN MX 20 mail.friend.bogus. 1D IN HINFO "386sx" "Linux 1.0.9" localhost 1D IN A 127.0.0.1 www 1D IN CNAME ns donald 1D IN A 192.168.196.3 1D IN MX 10 mail 1D IN MX 20 mail.friend.bogus. 1D IN HINFO "i486" "Linux 1.2" 1D IN TXT "DEK" ftp 1D IN A 192.168.196.5 1D IN MX 10 mail 1D IN MX 20 mail.friend.bogus. 1D IN HINFO "P6" "Linux 1.3.59" ns 1D IN A 192.168.196.2 1D IN MX 10 mail 1D IN MX 20 mail.friend.bogus. 1D IN HINFO "Pentium" "Linux 1.2" @ 1D IN SOA ns hostmaster ( 199802151 ; serial 8H ; refresh 2H ; retry 1W ; expiry 1D ) ; minimum Это хорошо. Как вы видите, это выглядит почти как сам файл зоны. Теперь проверим какой будет ответ только для машины с именем www: > set q=any > www.linux.bogus. Server: localhost Address: 127.0.0.1 www.linux.bogus canonical name = ns.linux.bogus linux.bogus nameserver = ns.linux.bogus linux.bogus nameserver = ns.friend.bogus ns.linux.bogus internet address = 192.168.196.2 Другими словами, настоящим именем для www.linux.bogus является ns.linux.bogus, и он также дается некоторая дополнительная информацию о машине ns, достаточная, чтобы соединиться с ней. Теперь мы находимся на середине пути. 44..33.. ООббррааттннааяя ((rreevveerrssee)) ззооннаа Теперь программы могут преобразовывать имена машин в домене linux.bogus в адреса, по которым они могут связаться с этими машинами. Но также, кроме этого, требуется обратная зона, которая дает возможность DNS преобразовывать адреса в имена машин. Эти имена используются достаточным количеством серверов различного рода (FTP, IRC, WWW и другими) для того, чтобы решить, хотят ли они с вами общаться или нет, и даже иногда имя машины используется для того, чтобы решить какой приоритет вам дать. Обратная зона требуется для полного доступа к различным сервисам в Internet. Поместите следующие строки в файл named.conf: ______________________________________________________________________ zone "196.168.192.in-addr.arpa" { notify no; type master; file "pz/192.168.196"; }; ______________________________________________________________________ Эти строки похожи на описание зоны 0.0.127.in-addr.arpa, а файл зоны также имеет сходное содержание: ______________________________________________________________________ @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; Serial, todays date + todays serial 8H ; Refresh 2H ; Retry 1W ; Expire 1D) ; Minimum TTL NS ns.linux.bogus. 1 PTR gw.linux.bogus. 2 PTR ns.linux.bogus. 3 PTR donald.linux.bogus. 4 PTR mail.linux.bogus. 5 PTR ftp.linux.bogus. ______________________________________________________________________ Теперь перезапустите ваш named (ndc restart) и снова проверьте его работу с помощью программы nslookup: ______________________________________________________________________ > 192.168.196.4 Server: localhost Address: 127.0.0.1 Name: mail.linux.bogus Address: 192.168.196.4 ______________________________________________________________________ так, это выглядит нормально, теперь выдайте полный список машин в домене, для того чтобы проверить правильность информации: ______________________________________________________________________ > ls -d 196.168.192.in-addr.arpa [localhost] $ORIGIN 196.168.192.in-addr.arpa. @ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial 8H ; refresh 2H ; retry 1W ; expiry 1D ) ; minimum 1D IN NS ns.linux.bogus. 1 1D IN PTR gw.linux.bogus. 2 1D IN PTR ns.linux.bogus. 3 1D IN PTR donald.linux.bogus. 4 1D IN PTR mail.linux.bogus. 5 1D IN PTR ftp.linux.bogus. @ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial 8H ; refresh 2H ; retry 1W ; expiry 1D ) ; minimum ______________________________________________________________________ Выглядит хорошо! Существует несколько вещей, которые я должен добавить здесь. Сетевые адреса, используемые здесь взяты из одного из блоков 'личных (private) сетей', их не разрешается публично использовать в internet. Так, что их можно спокойно использовать как пример в этом документе. Вторая вещь это строка notify no;. Она заставляет named не извещать вторичные (ведомые) сервера, когда вы обновляете один из файлов зон. В bind-8, named может уведомлять другие сервера, перечисленные в записях NS в файлах зон, когда конкретная зона обновляется. Это является удобным для обычного использования, но для личных экспериментов с зонами эта возможность должна быть отключена, мы же не хотим, чтобы наш эксперимент загрязнял internet? И конечно, этот домен является фиктивным, также как и все адреса в нем. Для настоящего примера действующего домена смотрите следующий раздел. 55.. ППррииммеерр ррееааллььннооггоо ддооммееннаа ММыы ззддеессьь ппееррееччииссллиимм ннеессккооллььккоо _н_а_с_т_о_я_щ_и_х ффааййллоовв ззоонн Пользователи предложили, чтобы я включил пример настроек действующего домена как учебное пособие. Я использую этот пример с разрешения David Bullock из LAND-5. Эти файлы содержат информацию, которая являлась реальной на 24 Сентября 1996 года, и были отредактированы мною для соответствия правилам синтаксиса bind-8 и использовали некоторые мои расширения. Так что, то что вы увидите здесь будет отличаться от того, что вы увидите сделав запрос на настоящий сервер имен LAND-5. 55..11.. //eettcc//nnaammeedd..ccoonnff ((ииллии //vvaarr//nnaammeedd//nnaammeedd..ccoonnff)) Здесь мы обнаружим два раздела основных зон для двух необходимых обратных зон: для сети 127.0.0, а также для домена LAND-5 с номером 206.6.177. А записи для основной зоны домена land-5.com. Также заметим, что вместо размещения файлов в директории названной pz, как я делал здесь до этого, администратор поместил эти файлы в директорию названную zone. ______________________________________________________________________ // Загрузочный файл для сервера имен LAND-5 options { directory "/var/named"; }; zone "." { type hint; file "root.hints"; }; zone "0.0.127.in-addr.arpa" { type master; file "zone/127.0.0"; }; zone "land-5.com" { type master; file "zone/land-5.com"; }; zone "177.6.206.in-addr.arpa" { type master; file "zone/206.6.177"; }; ______________________________________________________________________ Если вы поместите эти данные в ваш файл named.conf для того, чтобы поэкспериментировать с ними, то _П_О_Ж_А_Л_У_Й_С_Т_А поместите строку notify no; в раздел зон, принадлежащих land-5, для того чтобы избежать инцидентов. 55..22.. //vvaarr//nnaammeedd//rroooott..hhiinnttss Запомните, что это файл не является постоянным, и данные одног из перечисленных здесь серверов являются устаревшими. Вам лучше использовать вместо приведенного файла, файл сделанный перед этим помощью программы dig, как это объяснялось ранее. ______________________________________________________________________ ; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUERY SECTION: ;; ., type = NS, class = IN ;; ANSWER SECTION: . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 ;; Total query time: 215 msec ;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET. 198.41.0.4 ;; WHEN: Sun Feb 15 01:22:51 1998 ;; MSG SIZE sent: 17 rcvd: 436 ______________________________________________________________________ 55..33.. //vvaarr//nnaammeedd//zzoonnee//112277..00..00 Как основа файла обязательными записями являются запись SOA, и запись, которая объявляет 127.0.0.1 как localhost. Требуется указать обе эти записи. Больше ничего не должно быть в этом файле. Его скорее всего никогда не надо будет обновлять, до тех пор пока не изменится адрес сервера имен или ответственного за машину (hostmaster). ______________________________________________________________________ @ IN SOA land-5.com. root.land-5.com. ( 199609203 ; Serial 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400) ; Minimum TTL NS land-5.com. 1 PTR localhost. ______________________________________________________________________ 55..44.. //vvaarr//nnaammeedd//zzoonnee//llaanndd--55..ccoomm Здесь мы увидим обязательную запись SOA, и необходимые записи NS. Мы можем видеть, что имеется дополнительный сервер имен расположенный по адресу ns2.psi.net. _В_с_е_г_д_а необходимо иметь дополнительный сервер имен за пределами домена в качестве резерва. Мы также можем видеть, что этот домен имеет основной сервер, названный land-5, который заботится о множестве разных сервисов Internet, это сделано используя записи CNAME (как альтернатива использованию записей A). Как вы видите из записи SOA, файл зоны расположен в домене land-5.com, ответственным лицом является root@land-5.com. hostmaster -- это другой часто используемый адрес для отвественного за эту работу человека. Серийный номер записан в привычном формате yyyymmdd и дополнен серийным номером для текущего дня; это примерно 6-я версия файла зоны на 20 сентября 1996. Помните, что серийный номер _д_о_л_ж_е_н увеличиваться монотонно, здесь только _о_д_н_а цифра для серийного номера текущего дня, так что после 9 поправок мы должны ждать завтрашнего дня, для того чтобы дальше продолжить редактировать файл. Рассмотрите возможность использования двух цифр для номера вместо одной. ______________________________________________________________________ @ IN SOA land-5.com. root.land-5.com. ( 199609206 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 1W ; expire, seconds 1D ) ; minimum, seconds NS land-5.com. NS ns2.psi.net. MX 10 land-5.com. ; Основной почтовый сервер localhost A 127.0.0.1 router A 206.6.177.1 land-5.com. A 206.6.177.2 ns A 206.6.177.3 www A 207.159.141.192 ftp CNAME land-5.com. mail CNAME land-5.com. news CNAME land-5.com. funn A 206.6.177.2 @ TXT "LAND-5 Corporation" ; ; Рабочие станции ; ws-177200 A 206.6.177.200 MX 10 land-5.com. ; Основная почтовая машина ws-177201 A 206.6.177.201 MX 10 land-5.com. ; Основная почтовая машина ws-177202 A 206.6.177.202 MX 10 land-5.com. ; Основная почтовая машина ws-177203 A 206.6.177.203 MX 10 land-5.com. ; Основная почтовая машина ws-177204 A 206.6.177.204 MX 10 land-5.com. ; Основная почтовая машина ws-177205 A 206.6.177.205 MX 10 land-5.com. ; Основная почтовая машина ; {много повторяющихся определений удалено} ws-177250 A 206.6.177.250 MX 10 land-5.com. ; Основная почтовая машина ws-177251 A 206.6.177.251 MX 10 land-5.com. ; Основная почтовая машина ws-177252 A 206.6.177.252 MX 10 land-5.com. ; Основная почтовая машина ws-177253 A 206.6.177.253 MX 10 land-5.com. ; Основная почтовая машина ws-177254 A 206.6.177.254 MX 10 land-5.com. ; Основная почтовая машина ______________________________________________________________________ Если вы поработаете с сервером имен домена land-5, то вы обнаружите, что имена машин имеют форму ws__н_о_м_е_р. С последних версий bind 4 named начал ограничивать то, какие символы могут быть использованы в именах машин. Так, что эти имена нельзя было использовать с bind-8, и я подставил символ '-' (тире) вместо символа '_' (подчеркивание). Другая вещь, которую необходимо заметить, это то, что все рабочие станции не имеют индивидуальных имен, а вместо этого состоят из префикса за которым следует 2 последних числа из IP-адреса. Используя такое соглашение вы можете значительно упростить работу по сопровождению, но это может быть достаточно безлично и в действительности может быть источником недовольства со стороны ваших клиентов. Мы также видим, что имя funn.land-5.com это алиас для land-5.com, но используется запись A, а не запись CNAME. 55..55.. //vvaarr//nnaammeedd//zzoonnee//220066..66..117777 Я прокомментирую это файл после этого листинга. ______________________________________________________________________ @ IN SOA land-5.com. root.land-5.com. ( 199609206 ; Serial 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400) ; Minimum TTL NS land-5.com. NS ns2.psi.net. ; ; Servers ; 1 PTR router.land-5.com. 2 PTR land-5.com. 2 PTR funn.land-5.com. ; ; Рабочие станции ; 200 PTR ws-177200.land-5.com. 201 PTR ws-177201.land-5.com. 202 PTR ws-177202.land-5.com. 203 PTR ws-177203.land-5.com. 204 PTR ws-177204.land-5.com. 205 PTR ws-177205.land-5.com. ; {много повторяющихся определений удалено} 250 PTR ws-177250.land-5.com. 251 PTR ws-177251.land-5.com. 252 PTR ws-177252.land-5.com. 253 PTR ws-177253.land-5.com. 254 PTR ws-177254.land-5.com. ______________________________________________________________________ Обратная зона является той частью настройки, которая кажется способной вызвать большое горе (печаль, grief). Она используется для того, чтобы найти имя машины по ее IP-адресу. Пример: у вас есть IRC-сервер и он принимает соединения от IRC-клиентов. Однако он находится в Норвегии и хочет принимать соединения только от клиентов из Норвегии и других скандинавских стран. Когда вы соединяетесь с клиентом, то с помощью библиотеки языка С вы можете узнать адрес соединяющейся с сервером машины, поскольку этот адрес содержится во всех пакетах, передаваемых по сети. Теперь сервер может вызвать функцию названную gethostbyaddr, которая ищет имя машины по заданному IP-номеру. Gethostbyaddr запросит сервер DNS, который выполнит поиск заданной машины в DNS. Допустим клиент соединяется с машины ws-177200.land-5.com. IP-номер, который библиотека C передает IRC-серверу, равен 206.6.177.200. Для того, чтобы найти имя машины нам необходимо найти домен 200.177.6.206.in- addr.arpa. DNS-сервер сначала найдет сервера домена arpa., затем найдет сервера in-addr.arpa., следуя дальше через сервера группы 206, затем 6 и в конце концов найдет сервер для зоны 177.6.206.in-addr.arpa в домене land-5. От которого он в конце концов может получит ответ, что для 200.177.6.206.in-addr.arpa у нас есть запись 'PTR ws-177200.land-5.com', означающая что имя машины с адресом 206.6.177.200 равно ws-177200.land-5.com. Как и объяснение того, как мы искали prep.ai.mit.edu, этот пример вымышлен. Вернемся к нашему примеру с IRC-сервером. IRC-сервер принимает соединения только из скандинавских стран, например, *.no, *.se, *.dk, имя ws-177200.land-5.com явно не соответствует этому правилу и сервер запретит соединение. Если бы _н_е было обратного мапирования адреса 206.2.177.200 с помощью зоны in-addr.arpa, то сервер не смог бы вообще найти имя машины и должен был бы сравнивать адрес 206.2.177.200 с заданными масками --*.no, *.se и *.dk, которым этот адрес явно не соответствует. Некоторые люди скажут, что обратное преобразование адресов важно только для серверов, и не важно для остальной работы. Это не так: многие ftp, news, IRC и даже некоторые http (WWW) сервера _н_е принимают соединения от машин для которых они не могут найти имена. Так что в действительности обратное преобразование для машин является _о_б_я_з_а_т_е_л_ь_н_ы_м. 66.. ССооппррооввоожжддееннииее ССооддеерржжааннииее вв ррааббооччеемм ссооссттоояяннииии. Существует только одна задача по сопровождению named, кроме содержания его запущенным на машине. Это регулярное обновление файла root.hints. Наиболее легкий путь -- это использование программы dig. Сначала запустите dig без аргументов и вы получите файл root.hints, соответствующтй вашим данным. Затем запросите один из перечисленных корневых серверов, выполнив команду dig @rootserver. Вы заметите, что вывод этой команды выглядит ужасно похоже на файл root.hints. Сохраните выводимые данные в файл (с помощью команды dig @e.root- servers.net . ns >root.hints.new) и замените этим файлом старый файл root.hints. Помните, что необходимо перезапустить named после замены файла. Al Longyear послал мне этот скрипт, который может быть автоматически запущен для того, чтобы обновлять файл root.hints, создайте запись в crontab для запуска его раз в месяц и забудьте про него. В скрипте предполагается, что почтовая система работает и что определен почтовый алиас `hostmaster'. Вы должны подправить этот скрипт для соответствия вашим настройкам. ______________________________________________________________________ #!/bin/sh # # Обновляет информацию кеша сервера имен раз в месяц. # Он автоматически запускается раз в месяц с помощью cron. # ( echo "To: hostmaster " echo "From: system " echo "Subject: Automatic update of the named.conf file" echo export PATH=/sbin:/usr/sbin:/bin:/usr/bin: cd /var/named dig @rs.internic.net . ns >root.hints.new echo "The named.conf file has been updated to contain the following information:" echo cat root.hints.new chown root.root root.hints.new chmod 444 root.hints.new rm -f root.hints.old mv root.hints root.hints.old mv root.hints.new root.hints ndc restart echo echo "The nameserver has been restarted to ensure that the update is complete." echo "The previous root.hints file is now called /var/named/root.hints.old." ) 2>&1 | /usr/lib/sendmail -t exit 0 ______________________________________________________________________ Некоторые из вас заметили, что файл root.hints также доступен по ftp с сервера Internic. Пожалуйста _н_е используйте ftp для обновления файла root.hints, вышеприведенный метод более дружелюбен по отношению к сети. 77.. ППррееооббррааззооввааннииее ннаассттррооеекк nnaammeedd иизз ввееррссииии 44 вв ввееррссииюю 88 Раньше это был раздел об использовании bind 8, написанный David E. Smith (dave@bureau42.ml.org). Я немного изменил его для того, чтобы соответствовать имени раздела. В нем совсем немного. За исключением использования файла named.conf вместо named.boot, все остальное тоже самое. И bind8 поставляется со скриптом на perl, который преобразует файлы настроек со старым синтаксисом в файл с новым синтаксисом. Пример файла named.boot (старый стиль) для кеширующего сервера имен: ______________________________________________________________________ directory /var/named cache . root.hints primary 0.0.127.IN-ADDR.ARPA 127.0.0.zone primary localhost localhost.zone ______________________________________________________________________ В командной строке, находясь в директории bind8/src/bin/named (_э_т_о_т _п_р_и_м_е_р _п_р_е_д_п_о_л_а_г_а_е_т_, _ч_т_о _у _в_а_с _и_м_е_е_т_с_я _и_с_х_о_д_н_ы_й _к_о_д _п_а_к_е_т_а _b_i_n_d_8_. _Е_с_л_и _у _в_а_с _б_и_н_а_р_н_ы_й _п_а_к_е_т_, _т_о _с_к_р_и_п_т _в_е_р_о_я_т_н_о _д_о_л_ж_е_н _б_ы_т_ь _г_д_е_-_т_о _р_я_д_о_м_, _х_о_т_я _я _н_е _у_в_е_р_е_н_, _в _т_о_м _г_д_е _т_о_ч_н_о _о_н _б_у_д_е_т_н_а_х_о_д_и_т_с_я), наберите: ______________________________________________________________________ ./named-bootconf.pl < named.boot > named.conf ______________________________________________________________________ Эта команда создаст соответствующий файл named.conf: ______________________________________________________________________ // generated by named-bootconf.pl options { directory "/var/named"; }; zone "." { type hint; file "root.hints"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "127.0.0.zone"; }; zone "localhost" { type master; file "localhost.zone"; }; ______________________________________________________________________ Этот скрипт работает для всего, что могло быть записано в файле named.boot, хотя он не добавляет все новые расширения и опции настройки, которые разрешено использовать в bind8. Здесь я приведу более полный файл named.conf, который делает те же самые вещи, но немного более эффективно. ______________________________________________________________________ // Это файл конфигурации для named (для BIND 8.1 или более поздних). // Он обычно устанавливается как /etc/named.conf. // Отличие от `шаблонного' файла named.conf (кроме этого комментария :) // в том, что строка , где он объяснял свой способ решения данной проблемы: У меня запущен named на моей машине с 'Masquerading'. У меня есть два файла root.hints -- один, названный root.hints.real, который содержит настоящий список имен корневых серверов и второй, названный root.hints.fake, который содержит... ---- ; root.hints.fake ; этот файл не содержит информации ---- Когда я отключаюсь от провайдера, я копирую файл root.hints.fake в файл root.hints и перезапускаю named. Когда я снова подключаюсь к провайдеру, то я копирую файл root.hints.real в root.hints и опять перезапускаю named. Это делается из скриптов ip-down и ip-up соответственно. Сначала я делаю запрос об имени домена, о котором named не имеет информации, и он помещает примерно такую строку в файл messages.. Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN Кажется это работает в моем случае. Я могу использовать сервер имен для локальных машин в то время, когда я отключен от сети, без каких либо задержек по тайм-ауту для внешних доменов, и сервер имен работает нормально с внешними доменами, в то в ремя, когда я подключен к сети. ╥ Я также получил информацию от Karl-Max Wanger о том, как bind взаимодействует с NFS и portmapper на большинстве большинстве машин, не имеющих доступа к внешней сети. У меня запущен named на всех машинах, которые только время от времени подключены к Internet с помощью модема. Сервер имен только кеширует информацию, он не авторизует никакую информацию и запрашивает обо всем сервера перечисленные в файле root.cache. Как обычно в Slackware, он запускается до nfsd и mountd. На одной из моих машин (портативный компьютер Libretto 30) у меня была проблема с тем, что иногда я мог примонтировать ее диск с другой машины, подключенной к моей локальной сети, но в остальное время эта операция не удавалось. У меня был один и тот же эффект, вне зависимости от использования PLIP, PCMCIA ethernet карты или PPP по последовательному интерфейсу. После некоторого времени, проведенного в предположениях и экспериментах, я нашел, что named несомненно вносит беспорядок в процесс регистрации nfsd и mountd, что выполняется с помощью portmapper при запуске (я как обычно запускаю эти демоны во время загрузки). Запуск named после nfsd и mountd полностью устранил эту проблему. Поскольку не ожидается никакого ущерба от такой измененной последовательности загрузки, то я рекомендую всем сделать также как сделал я, для предотвращения потенциальных осложнений. 7. Где кеширующий сервер имен хранит свой кеш? Есть ли способ контролировать размер кеша. Кеш полностью хранится в памяти, он _н_и_к_о_г_д_а сохраняется на на диск. Каждый раз, когда вы прекращаете выполнение named содержимое кеша теряется. Кеш не контролируется ни одним из способов. named обслуживает его, согласно некскольким простым правилам. Вы не можете контролировать кеш или его размер по любым причинам. Если вы хотите, то вы можете ``исправить'' это, подправив named. Однако это не рекомендуется. 8. Сохраняет ли named свой кеш между перезапусками? Как я могу заставить named сохранять его? Нет, named _н_е сохряняет кеш при завершении. Это означает, что кеш должен быть построен заново каждый раз при перезапуске named. _Н_е_т способа, который заставил бы named сохранять кеш в файле. Если вы хотите, то вы можете ``исправить'' это, подправив named. Однако это не рекомендуется. 99.. ККаакк ссттааттьь ббооллееее ззннааюющщиимм ааддммииннииссттррааттоорроомм DDNNSS.. ДДооккууммееннттааццииии ии ууттииллииттыы.. Существует настоящая документация. Доступная в электронной и в печатной формах. Чтение некоторых из этих руководств требуется для того, чтобы сделать шаг от простого администратора DNS к крупному администратору. В печатном виде стандартной книгой является _D_N_S _a_n_d _B_I_N_D авторов C. Liu и P. Albitz, выпущенная O'Reilly & Associates, Sebastopol, CA, ISBN 0-937175-82-X. Я читал ее, она великолепна. Также существует раздел о DNS в книге _T_C_P_/_I_P _N_e_t_w_o_r_k _A_d_m_i_n_i_s_t_r_a_t_i_o_n, написанной Craig Hunt и изданной O'Reilly..., ISBN 0-937175-82-X. Также для администрирования DNS (или всего, относящегося к этому) должна быть хорошей книга _Z_e_n _a_n_d _t_h_e _A_r_t _o_f _M_o_t_o_r_c_y_c_l_e _M_a_i_n_t_e_n_a_n_c_e автора Robert M. Prisig :-) доступна как ISBN 0688052304, а также другие книги. В электронной форме вы можете найти материалы на , ; FAQ, справочные материалы (BOG; Bind Operations Guide), а также статьи и определения протоколов и дополнения (hacks) к DNS (эти, и большинство, если не все, rfc, упомянутые ниже, они также идут в поставке bind). Мне не нужны большинство из них, но я не являюсь крупным DNS администратором. Arnt Gulbrandsen читал BOG и находится в экстазе от его :-). В группе новостей comp.protocols.tcp-ip.domains происходят дискуссии о DNS. В добавление к этому, здесь перечислены некоторые RFC о DNS, самыми важными из которых вероятно являются следующие: RRFFCC 22005522 A. Gulbrandsen, P. Vixie, _A _D_N_S _R_R _f_o_r _s_p_e_c_i_f_y_i_n_g _t_h_e _l_o_c_a_t_i_o_n _o_f _s_e_r_v_i_c_e_s _(_D_N_S _S_R_V_), October 1996 RRFFCC 11991188 Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear, _A_d_d_r_e_s_s _A_l_l_o_c_a_t_i_o_n _f_o_r _P_r_i_v_a_t_e _I_n_t_e_r_n_e_t_s, 02/29/1996. RRFFCC 11991122 D. Barr, _C_o_m_m_o_n _D_N_S _O_p_e_r_a_t_i_o_n_a_l _a_n_d _C_o_n_f_i_g_u_r_a_t_i_o_n _E_r_r_o_r_s, 02/28/1996. RRFFCC 11991122 EErrrroorrss B. Barr _E_r_r_o_r_s _i_n _R_F_C _1_9_1_2, this is available at RRFFCC 11771133 A. Romao, _T_o_o_l_s _f_o_r _D_N_S _d_e_b_u_g_g_i_n_g, 11/03/1994. RRFFCC 11771122 C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, _D_N_S _E_n_c_o_d_i_n_g _o_f _G_e_o_g_r_a_p_h_i_c_a_l _L_o_c_a_t_i_o_n, 11/01/1994. RRFFCC 11118833 R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, _N_e_w _D_N_S _R_R _D_e_f_i_n_i_t_i_o_n_s, 10/08/1990. RRFFCC 11003355 P. Mockapetris, _D_o_m_a_i_n _n_a_m_e_s _- _i_m_p_l_e_m_e_n_t_a_t_i_o_n _a_n_d _s_p_e_c_i_f_i_c_a_t_i_o_n, 11/01/1987. RRFFCC 11003344 P. Mockapetris, _D_o_m_a_i_n _n_a_m_e_s _- _c_o_n_c_e_p_t_s _a_n_d _f_a_c_i_l_i_t_i_e_s, 11/01/1987. RRFFCC 11003333 M. Lottor, _D_o_m_a_i_n _a_d_m_i_n_i_s_t_r_a_t_o_r_s _o_p_e_r_a_t_i_o_n_s _g_u_i_d_e, 11/01/1987. RRFFCC 11003322 M. Stahl, _D_o_m_a_i_n _a_d_m_i_n_i_s_t_r_a_t_o_r_s _g_u_i_d_e, 11/01/1987. RRFFCC 997744 C. Partridge, _M_a_i_l _r_o_u_t_i_n_g _a_n_d _t_h_e _d_o_m_a_i_n _s_y_s_t_e_m, 01/01/1986.