Проверка неправильного имени хоста

287. Когда IP датаграмма прибывает на хост сервера, будь то UDP датаграмма или TCP сегмент с требованием установить соединение, все что доступно процессу сервера это IP адрес клиента и номер порта (UDP или TCP). Некоторые сервера требуют, чтобы IP адрес клиента имел запись указателя в DNS. В разделе "Примеры FTP" главы 27 мы рассмотрим пример, иллюстрирующий это, используя анонимный FTP с неизвестного IP адреса.

288. Другие серверы, как, например, сервер Rlogin (глава 26), требуют не только то, чтобы IP адрес клиента имел запись указателя, но и еще спрашивают DNS об IP адресе, соответствующем имени, возвращенном в PTR отклике, и требуют, чтобы один из возвращенных адресов совпадал с IP адресом в принятой датаграмме. Эта проверка осуществляется потому, что пункты в файле.rhosts (глава 26, раздел "Протокол Rlogin") содержат имя хоста, а не IP адрес; таким образом, сервер хочет убедиться, что имя хоста действительно соответствует входящему IP адресу.

289. Некоторые производители автоматически помещают эту проверку в программы разборщика, конкретно в функцию gethostbyaddr. При этом подобная проверка становится доступной для любой программы, использующей разборщик. Отпадает необходимость помещать эту проверку в каждое приложение.

290. Мы можем увидеть, как это происходит, с помощью библиотеки разборщика SunOS 4.1.3. Мы написали простую программу, которая осуществляет запрос указателя путем вызова функции gethostbyaddr. Также мы поместили записи в файл /etc/resolv.conf таким образом, чтобы использовать в качестве DNS сервера хост noao.edu, получить доступ к которому можно через SLIP канал с хоста sun. На рисунке 14.13 показан вывод команды tcpdump, полученный от SLIP канала, при вызове функции gethostbyaddr, в случае, когда получается имя, соответствующее IP адресу 140.252.1.29 (хост sun).

291.

292.
1 0.0 sun.1812 > noao.edu.domain: 1+ PTR?
29.1.252.140.in-addr.arpa. (43)
2 0.339091 (0.3391) noao.edu.domain > sun.1812: 1* 1/0/0 PTR
sun.tuc.noao.edu. (73)
3 0.344348 (0.0053) sun.1813 > noao.edu.domain: 2+ A?
sun.tuc.noao.edu. (33)
4 0.669022 (0.3247) noao.edu.domain > sun.1813: 2* 2/0/0 A
140.252.1.29 (69)

293.

294. Рисунок 14.13 Вызов функции разборщика, которая осуществляет запрос указателя.

295.

296. В строке 1 запрос указателя, в строке 2 отклик. Однако, функция разборщика автоматически посылает запрос об IP адресе в строке 3 на имя, возвращенное в строке 2. Отклик в строке 4 содержит две записи ответа, так как хост sun имеет два IP адреса. Если ни один из адресов не совпал с аргументом gethostbyaddr, отправляется сообщение системе, которая фиксирует событие, а функция возвращает ошибку приложению.

297. Записи ресурсов

298. Мы видели несколько различных типов записей ресурса (RR), а именно: IP адрес имеет тип A, а PTR обозначает запрос указателя. Также мы видели RR, которые возвращает DNS сервер: RR ответа, RR полномочий и RR дополнительной информации. Всего существует около 20 различных типов записей ресурсов, некоторые из которых мы сейчас опишем.

299. А

300. Запись А определяет IP адрес. Хранится как 32-битное двоичное значение.

301. PTR

302. Запись указателя используется для запросов указателя. IP адрес представляется в виде имени домена (последовательность меток) в домене in-addr.arpa.

303. CNAME

304. "Каноническое имя" (canonical name). Представляется как имя домена (последовательность меток). Имя домена, которое имеет каноническое имя, часто называется псевдонимом (alias). Они используются некоторыми FTP узлами, для того чтобы предоставить легкозапоминаемый псевдоним для какой-либо системы.

305. Например, сервер gated (мы упоминали о нем в разделе "Демоны маршрутизации в Unix" главы 10) доступен через анонимное FTP с сервера gated.cornell.edu. Однако, не существует системы, названной gated, это псевдоним для какой-то другой системы. Эта другая система является каноническим именем для gated.cornell.edu:

306.

307.
sun % host -t cname gated.cornell.edu
gated.cornell.edu CNAME COMET.CIT.CORNELL.EDU

308.

309. Здесь мы использовали опцию -t, чтобы указать на один конкретный тип запроса.

310. HINFO

311. Информация о хосте: две символьные строки, указывающие на центральный процессор (CPU) и операционную систему. Не все хосты предоставляют записи HINFO для своих систем, и предоставляемая информация может быть устаревшей.

312.

313.
sun % host -t hinfo sun
sun.tuc.noao.edu HINFO Sun-4/25 Sun4.1.3

314.

315. MX

316. Записи, посвященные обмену почтой, которые используются по следующему сценарию: (1) узел, который не подсоединен к Internet, может использовать узел, который подсоединен к Internet, в качестве своего почтового сервера. Два узла работают попеременно, обмениваясь любой прибывшей почтой, в основном с использованием протокола UUCP. (2) запись MX предоставляет возможность доставить почту на альтернативный хост, когда хост назначения недоступен. (3) записи MX позволяют организациям предоставлять виртуальные хосты, на которые можно отправлять почту, как, например, cs.university.edu, даже если хост с таким именем не существует. (4) Организации со шлюзами firewall могут использовать записи MX, чтобы ограничить доступ к внутренним системам.

317. Многие хосты, которые не подключены к Internet, имеют UUCP каналы к хостам, подключеным к Internet, как, например, UUNET. С помощью записи MX обеспечивается передача электронной почты с использованием стандартного обращения user@host (пользователь@хост). Например, фиктивный домен foo.com может иметь следующую MX запись:

318.

319.
sun % host -t mx foo.com
foo.com MX relay1.UU.NET
foo.com MX relay2.UU.NET

320.

321. MX записи используются программами доставки почты на хостах, подключенных к Internet. В этом примере программа доставки почты говорит "если у тебя есть почта, которую необходимо послать на [email protected], пошли почту на relay1.uu.net или на relay2.uu.net".

322. В каждой записи MX есть 16-битное целое значение, которое называется значением предпочтительности. Если для одного пункта назначения существует несколько MX записей, они будут использованы по порядку, начиная с той записи, у которой наименьшее значение предпочтительности.

323. Записи MX используются, когда хост выключен или недоступен. В этом случае программа доставки почты использует MX записи только в том случае, если не может подсоединиться к пункту назначения с использованием TCP. Для объединенных сетей, с которыми экспериментировал автор, его основная система подключена к Internet через SLIP канал, и если она не работает, мы получим:

324.

325.
sun % host -tv mx sun
Query about sun for record types MX
Trying sun within tuc.noao.edu...
Query done, 2 answers,authoritative status: no error
sun.tuc.noao.edu 86400 IN MX 0 sun.tuc.noao.edu
sun.tuc.noao.edu 86400 IN MX 10 noao.edu

326.

327. Опцию -v позволяет посмотреть значения предпочтительности. (Благодаря этой опции в выводе появятся и все другие поля.) Второе поле, 86400, - это время жизни в секундах. Время жизни равно 24 часам (24х60х60). Третья колонка, IN, это класс (Internet). Мы видим, что непосредственная доставка на хост (первая запись MX) имеет наименьшее значение предпочтительности равное 0. Если это не работает (SLIP канал выключен), используется следующее более высокое значение предпочтительности (10), и делается попытка доставить почту на хост noao.edu. Если и это не сработает, отправитель отработает тайм-аут и повторит попытки позже.

328. В разделе "Примеры SMTP" главы 28 мы покажем примеры доставки почты SMTP с использованием записей MX.

329. NS

330. Запись имени сервера. Указывает на полномочные DNS серверы для домена. Представлена в виде имен доменов (последовательность меток). Мы рассмотрим примеры этих записей в следующем разделе.

331.

332. Это общие типы RR. В следующих примерах мы увидим еще некоторые типы.

333. Кэширование

334. Чтобы уменьшить траффик DNS в Internet, все сервера DNS используют кэширование. В стандартных Unix реализациях кэш поддерживается сервером, а не разборщиком. Так как разборщик является частью каждого приложения, а приложения приходят и уходят, оставляя кэш в программах, которые живут все время, пока система работает (сервер DNS), имеет смысл поддерживать кэш именно на сервере. При этом кэш доступен любому приложению, которое использует сервер. Любые другие хосты в узле, которые используют этот сервер DNS, также пользуются кэшем сервера.

335. В примерах (рисунок 14.9), мы запускали клиентов на хосте sun, и обращались к DNS серверу на хост noao.edu через SLIP канал. Сейчас попробуем запустить DNS сервер на хосте sun. В этом случае, если просмотреть с использованием tcpdump траффик DNS в SLIP канале, мы увидим только запросы, которые не могут быть обработаны сервером в своем собственном кэше.

336. По умолчанию разборщик ищет сервер DNS на локальном хосте (UDP порт 53 или TCP порт 53). Мы удалили запись nameserver из файла разборщика, оставив только запись domain:

337.

338. sun % cat /etc/resolv.conf
domain tuc.noao.edu

339.

340. Отсутствие записи nameserver в этом файле приводит к тому, что разборщик пользуется сервером DNS на локальном хосте.

341. Затем мы запустили команду host следующим образом:

342.

343.
sun % host ftp.uu.net
ftp.uu.net A 192.48.96.9

344.

345. На рисунке 14.14 показан вывод команды tcpdump для этого запроса.

346.

347.
1 0.0 sun.tuc.noao.edu.domain > NS.NIC.DDN.MIL.domain:
2 A? ftp.uu.net. (28)
2 0.559285 (0.5593) NS.NIC.DDN.MIL.domain > sun.tuc.noao.edu.domain:
2- 0/5/5 (229)

3 0.564449 (0.0052) sun.tuc.noao.edu.domain > ns.UU.NET.domain:
3+ A? ftp.uu.net. (28)
4 1.009476 (0.4450) ns.UU.NET.domain > sun.tuc.noao.edu.domain:
3* 1/0/0 A ftp.UU.NET (44)

348.

349. Рисунок 14.14 Вывод tcpdump для: host ftp.uu.net.

350.

351. Появилась новая опция программы tcpdump. Мы получаем все данные, направляющиеся к или от UDP или TCP портов 53, с помощью опции -w. В этом случае весь символьный вывод сохраняется в файле для дальнейшей обработки. При этом tcpdump не пытается вызвать свой собственный разборщик, чтобы напечатать все имена, соответствующие IP адресам. После того как запущены все запросы, мы перезапустили tcpdump с опцией -r. В этом случае программа читает выходной файл и генерирует обычный вывод (который показан на рисунке 14.14). Это занимает несколько секунд, так как tcpdump вызывает свой разборщик.

352.

353. Первое на что необходимо обратить внимание в выводе tcpdump, это то, что идентификаторы представляют собой небольшие целые числа (2 и 3). Это потому, что мы выключили сервер DNS и затем перестартовали его, чтобы очистить кэш. Когда сервер DNS стартует, он устанавливает идентификатор в 1.

354. Затем мы ввели запрос, в котором требуется получить IP адрес для хоста ftp.uu.net, DNS сервер установил соединение с одним из восьми корневых серверов, ns.nic.ddn.mil (строка 1). Это обычный запрос типа A, который мы уже видели ранее, однако обратите внимание, что флаг требования рекурсии не установлен. (Если флаг установлен, после идентификатора 2 должен быть напечатан знак плюс.) В наших предыдущих примерах говорилось, что разборщик устанавливает флаг необходимости рекурсии, однако здесь мы видим, что наш сервер DNS не установил флаг, когда он обратился к одному из корневых серверов. Это произошло потому, что от корневых серверов нельзя требовать рекурсивных ответов - они должны быть использованы только для того, чтобы найти адреса к другим полномочным серверам.

355. Из строки 2 видно, что отклик пришел назад без записи ресурса (RR) ответа, с пятью RR полномочий и пятью RR дополнительной информации. Знак минус, следующий за идентификатором 2, означает, что флаг "рекурсия возможна" (RA) не установлен - этот корневой сервер не ответит на рекурсивный запрос, даже если мы его об этом попросим.

356. Несмотря на то, что tcpdump не напечатал 10 записей ресурсов, которые были возвращены, мы можем исполнить команду host, чтобы посмотреть, что находится в кэше:

357.

358.
sun % host -v ftp.uu.net
Query about ftp.uu.net for record types A
Trying ftp.uu.net...
Query done, 1 answer, status: no error
The following answer is not authoritative:
ftp.uu.net 19109 IN A 192.48.96.9
Authoritative nameservers:
UU.NET 170308 IN NS NS.UU.NET
UU.NET 170308 IN NS UUNET.UU.NET
UU.NET 170308 IN NS UUCP-GW-1.PA.DEC.COM
UU.NET 170308 IN NS UUCP-GW-2.PA.DEC.COM
UU.NET 170308 IN NS NS.EU.NET
Additional information:
NS.UU.NET 170347 IN A 137.39.1.3
UUNET.UU.NET 170347 IN A 192.48.96.2
UUCP-GW-1.PA.DEC.COM 170347 IN A 16.1.0.18
UUCP-GW-2.PA.DEC.COM 170347 IN A 16.1.0.19
NS.EU.NET 170347 IN A 192.16.202.11

359.

360. В этот раз мы указали опцию -v, чтобы увидеть не только записи A. Вывод показывает, что в домене uu.net присутствует пять полномочных DNS серверов. Пять RR с дополнительной информацией, которые были возвращены корневым серверам, содержат IP адреса этих пяти DNS серверов. Поэтому у нас нет необходимости снова устанавливать контакт с корневым сервером, чтобы найти адрес одного из этих серверов. Это еще одно из расширений реализации, сделанное в DNS.

361. Команда host определяет, что ответ не авторитетный. Это произошло из-за того, что ответ был получен из кэша нашего DNS сервера, а не в результате контакта с полномочным сервером.

362. Вернемся к строке 3 на рисунке 14.14; сервер DNS установил контакт с первым полномочным сервером (ns.uu.net) с тем же самым вопросом: какой IP адрес ftp.uu.net? На этот раз наш сервер установил флаг "рекурсия необходима". Ответ, возвращенный в строке 4 - это отклик с одним ответом RR.

363. Затем мы снова исполнили команду host, спрашивая о том же самом имени:

364.

365.
sun % host ftp.uu.net
ftp.uu.net A 192.48.96.9

366.

367. Это как раз то, что мы и ожидали, потому что ответ на команду host был получен из кэша сервера.

368. Мы исполнили команду host снова в поисках адреса для ftp.ee.lbl.gov:

369.

370.
sun % host ftp.ee.lbl.gov
ftp.ee.lbl.gov CNAME ee.lbl.gov
ee.lbl.gov A 128.3.112.20

371.

372. На рисунке 14.15 показан вывод команды tcpdump.

373.

374.
1 18.664971 (17.6555) sun.tuc.noao.edu.domain > c.nyser.net.domain:
4 A? ftp.ee.lbl.gov. (32)
2 19.429412 (0.7644) c.nyser.net.domain > sun.tuc.noao.edu.domain:
4 0/4/4 (188)

3 19.432271 (0.0029) sun.tuc.noao.edu.domain > ns1.lbl.gov.domain:
5+ A? ftp.ee.lbl.gov. (32)
4 19.909242 (0.4770) ns1.lbl.gov.domain > sun.tuc.noao.edu.domain:
5* 2/0/0 CNAME ee.lbl.gov. (72)

375.

376. Рисунок 14.15 Вывод tcpdump для: host ftp.ee.lbl.gov.

377.

378. Из строки 1 видно, что теперь наш сервер установил контакт с другим корневым сервером (c.nyser.net). Сервер DNS обычно циклически опрашивает различные серверы для зоны, при этом накапливается информация о времени отклика от того или иного сервера. И, в конце концов, будет использован тот сервер, время возврата от которого минимально.

379.

380. Так как наш сервер установил контакт с корневым сервером, флаг "рекурсия необходима" не установлен. Корневой сервер не сбросил флаг "рекурсия возможна", как мы видели в строке 2 на рисунке 14.14. (Даже если так, DNS сервер все равно не должен запрашивать корневой сервер с помощью рекурсивного запроса.)

381. В строке 2 отклик приходит назад без ответа, однако с четырьмя RR полномочий и четырьмя RR дополнительной информации. Как мы можем догадаться, четыре RR полномочий это имена DNS серверов для ftp.ee.lbl.gov, а другие четыре RR содержат IP адреса этих четырех серверов.

382. Строка 3 - это запрос на сервер ns1.lbl.gov (первый из четырех DNS серверов, полученных в строке 2). Флаг "рекурсия необходима" установлен.

383. Отклик в строке 4 отличается от предыдущих откликов. Возвращено два RR ответа, и tcpdump сообщает, что первый - это RR CNAME. Каноническое имя для ftp.ee.lbl.gov - это ee.lbl.gov.

384.

385. Это общепринятое использование записи CNAME. FTP узел для LBL всегда имеет имя, начинающееся с ftp, однако время от времени он может перемещаться с одного хоста на другой. Пользователям достаточно знать только имя ftp.ee.lbl.gov, а DNS сама установит соответствие с тем или иным хостом.

386.

387. Вспомните, что когда мы запускали host, он печатал и CNAME и IP адрес, соответствующий каноническому имени. Это потому, что отклик (строка 4 на рисунке 14.15) содержит два RR ответа. Первый это CNAME, второй это запись A. Если запись A не была возвращена вместе с CNAME, наш сервер пошлет еще один запрос, спрашивая IP адрес ee.lbl.gov. Это еще одна оптимизация реализации: CNAME и запись A канонического имени возвращается в одном отклике.

388. UDP или TCP

389. Мы уже упоминали, что заранее известные номера портов для DNS серверов - UDP порт 53 и TCP порт 53. Это означает, что DNS поддерживает как UDP, так и TCP. Однако все примеры, которые мы просмотрели с использованием tcpdump, использовали UDP. Когда используется тот или иной протокол и почему?

390. Когда разборщик выдает запрос и возвращается отклик с установленным битом TC (обрезано - truncated), это означает, что размер отклика превысил 512 байт, только первые 512 байт были возвращены серверу. Разборщик обычно отправляет запрос снова, но уже с использованием TCP. При этом возвращается больше, чем 512 байт. (Вспомните описание максимального размера UDP датаграммы в разделе "Максимальный размер UDP датаграммы" главы 11.) Так как TCP делит поток данных на части, которые называются сегментами, он может передать любое количество пользовательских данных с использованием нескольких сегментов.

391. Также, когда в домене включается вторичный сервер DNS, он осуществляет передачу зоны с первичного сервера домена. Мы также говорили, что вторичный сервер регулярно запрашивает первичный (обычно каждые три часа). При этом определяется, не обновил ли первичный сервер свою таблицу, и если да, то осуществляется передача зоны. Передача зоны осуществляется с использованием TCP, так как в этом случае передается значительно больше данных, чем в случае одного запроса или отклика.

392. Так как DNS в основном использует UDP, и разборщик, и сервер DNS должны отработать свой собственный тайм-аут и осуществить повторную передачу. В отличие от других приложений Internet, которые используют UDP (TFTP, BOOTP и SNMP) и которые функционируют обычно в локальных сетях, DNS отправляет запросы и получает отклики обычно по глобальным сетям. Процент потерянных пакетов и разница в значениях времен возврата обычно значительно выше в глобальных сетях, нежели в локальных, при этом повышается важность надежной передачи и четкости работы алгоритма расчета тайм-аутов для клиентов DNS.

393. Еще один пример

394. Давайте рассмотрим еще один пример, который описывает несколько функций DNS, о которых мы рассказали раньше. Мы запустили клиента Rlogin, подсоединившись к Rlogin серверу в каком-то удаленном домене. На рисунке 14.16 показан обмен пакетами.

395.

396. Рисунок 14.16 Обмен пакетами при старте Rlogin клиента и сервера.

397.

398. Было осуществлено 11 шагов, при этом заранее никакой информации на клиенте или сервере кэшировано не было:

399. Клиент стартует и вызывает свою функцию разборщика, чтобы конвертировать имя хоста, которое мы ввели вместо IP адреса. Запрос типа A отправляется на корневой сервер.

400. Ответ от корневого сервера содержит DNS сервера для домена в котором находится Rlogin сервер.

401. Разборщик клиента повторно отправляет запрос типа A на DNS сервер. Этот запрос обычно имеет установленный флаг "рекурсия необходима".

402. Приходит отклик с IP адресом хоста.

403. Клиент Rlogin устанавливает TCP соединение с сервером Rlogin. (В главе 18 этот процесс описывается более подробно.) TCP модули клиента и сервера обмениваются друг с другом тремя пакетами.

404. Сервер Rlogin принимает соединение от клиента и вызывает свой разборщик, чтобы получить имя хоста клиента по IP адресу, который сервер получил от своего TCP. Это PTR запрос, выданный на корневой DNS сервер. Может быть, это не тот корневой сервер, к которому обратился клиент в шаге 1.

405. Отклик корневого сервера содержит имя DNS сервера домена in-addr.arpa клиента.

406. Разборщик сервера повторно отправляет PTR запрос к DNS серверу клиента.

407. PTR отклик содержит FQDN хоста клиента.

408. Разборщик сервера отправляет запрос типа A к DNS серверу клиента, спрашивая IP адрес, соответствующий имени, возвращенному в предыдущем шаге. Это может быть сделано автоматически с использованием функции сервера gethostbyaddr, как мы описали в разделе "Запросы указателя" этой главы, или сервер Rlogin осуществляет этот шаг самостоятельно. Также, DNS сервер клиента часто тот же самый, что и DNS сервер клиента in-addr.arpa, однако это необязательно.

409. Отклик от DNS сервера клиента содержит запись A для хоста клиента. Сервер Rlogin сравнивает запись A с IP адресом клиента, потребовавшего открыть TCP соединение.

410. Кэширование может уменьшить количество пакетов, которыми произошел обмен в этом примере.

411. Краткие выводы

412. DNS это одна из важнейших частей любого хоста, подключенного к Internet, эта система также широко используется в частных объединенных сетях. Основа организации - иерархическое дерево, которое формирует пространство имен DNS.

413. Приложения обращаются к разборщикам, чтобы конвертировать имя хоста в IP адрес и наоборот. Разборщики обращаются к локальным серверам DNS, а они, свою очередь, могут обратиться к одному из корневых серверов или к другим серверам, чтобы получить ответ на запрос.

414. Все DNS запросы и отклики имеют один и тот же формат. Эти сообщения содержат записи ресурсов (RR) вопросов и, возможно, ответов, RR полномочий и RR дополнительной информации. Мы рассмотрели множество примеров, в которых показана конфигурация разборщика и некоторые принципы организации DNS: указатели на имена доменов (чтобы уменьшить размер сообщений), кэширование, домен in-addr.arpa (поиск имени по заданному IP адресу) и возвращаемые дополнительные RR (для того чтобы запрашивающий не выдавал повторный запрос).

69.некоторые типы dns-серверов. Формат dns сообщенния.

Типы DNS-серверов

Рассматривая любой субдомен DNS, вы столкнетесь с тремя видами пере­численных далее DNS-серверов.

? Первичный DNS-cepeep, также называемый ведущим сервером. Первичный ведущий сервер именDNS или, иначе, ведущий сервер (master server) со­держит первичные файлы баз данных службыDNS для доменов или суб­доменов, за которые он отвечает. Этот файл — это ASCII-снимок базы данных службы DNS, загружаемый в память сервера во время его работы. Такой сегмент базы данных называется зоной (zone); таким образом, со­ответствующий файл, иногда называемыйфайлом зоны (zone file) или файлом данных зоны (zone data file). Первичный ведущий сервер(primary master server) отличается от других серверов имен, относящихся к домену, тем, что он всегда способен считывать свои данные из файла зоны на диске, когда служба DNS запускается. Обозначение первичного ведущего сервера является важным элементом конфигурации при установке лю­бого DNS-сервера. Для каждой DNS-зоны может существовать только один первичный ведущий сервер имен.

? Вторичный DNS-cepeep, также называемый подчиненным сервером. Вторич­ный DNS-сервер(secondary DNS server), или другие его названия — вто­ричный ведущий сервер (secondary masterserver) и подчиненный сервер (slave server), получает свои данные зоны от ведущего сервера этой зоны. В боль­шинстве реализаций службы DNS вторичный сервер может считывать свои данные из локального файла, но всегда проверяет, является ли вер­сия данных, находящаяся на его диске, столь же современной, как вер­сия, размещенная на первичном сервере. Для этого он проверяет специ­альное поле в своей записи начала полномочий (SOA) и сравнивает его с соответствующим значением в базе данных ведущего сервера. Если при этом выявляются несоответствия, вторичный сервер может обновить свою базу данных, отождествляя ее с базой, находящейся на первичном сервере домена. Важно понимать, что данные зоны на вторичном сервере всегда получаются с первичного сервера. Как бы то ни было, в большин­стве реализаций службы DNS присутствуют ограничения, которые обя­зывают вторичный сервер обновлять только те данные, которые подверг­лись изменениям на первичном сервере (эти данные сначала должны быть скопированы на вторичный сервер). Для каждой DNS-зоны наряду с обязательным первичным сервером имен должен существовать хотя бы один вторичный ведущий сервер (но их может быть и больше).

? Кэширующий сервер. Кэширующие серверы (caching servers) хранят DNS- записи из других доменов, доступ к которым запрашивался в недавнем времени. Это делается для того, чтобы избежать непроизводительных из­держек, связанных с осуществлением удаленного запроса в каждом слу­чае получения доступа к ресурсу вне локального домена. Чтобы понять принцип кэширования, можно рассмотреть различие между вашим холо­дильником и соседним продуктовым магазином. Равно как холодильник определяет, что вы можете съесть прямо сейчас, так и кэш указывает, ка­кие имена вне локального домена можно разрешить немедленно. Ана­логичным образом, в продуктовом магазине есть обширный набор про­дуктов, которые вы теоретически можете съесть, а во всемирной базе данных DNS содержатся все имена и адреса, которые можно попытаться разрешить.

Функции кэширования могут выполнять первичные и вторичные DNS- серверы, но в то же время внутри конкретного домена можно установить и настроить специальный кэширующий сервер(caching-only server). Назна­чение специального кэширующего сервера состоит в том, чтобы ускорить доступ к определенным доменным именам посредством хранения ло­кальной копии данных поиска, при этом не выполняя функции первич­ного или вторичного DNS-сервера. Когда организации пытаются решить, нужен ли им специальный кэширующий сервер, они принимают во вни­мание такие факторы, как размер данной организации и объемы предос­тавляемого доступа в сеть Internet. Столь серьезная специализация DNS- серверов обычно характерна лишь для крупных компаний и поставщиков услуг или, иначе, провайдеров. В компаниях меньшего масштаба первич­ные и вторичные отклики на внутренние запросы могут сочетаться с по­исками по кэшу для исходящего трафика, причем производительность от этого сильно не пострадает.

Вторичные, или подчиненные, DNS-серверы важны постольку, поскольку они содержат резервную копию базы данных домена для конкретной зоны. Таким образом, вторичные DNS-серверы могут обрабатывать запросы служ­бы имен для своих зон даже в тех случаях, когда первичный сервер имен выходит из строя. Кроме того, вторичные серверы способствуют распреде­лению нагрузки при выполнении операций DNS-поиска. Часто DNS- серверы, ответственные (являющиеся первичными) за одни зоны, действуют в роли подчиненных или вторичных DNS-серверов в отношении других, близлежащих зон. В результате хосты, находящиеся в одной зоне, получают возможность свободного доступа к данным службы DNS других зон.