Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
- Название:TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
- Автор:
- Жанр:
- Издательство:Лори
- Год:2000
- Город:Москва
- ISBN:5-85582-072-6
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) краткое содержание
Второе издание популярного справочника полностью переработано и расширено с целью предоставить читателю наиболее полное описание средств разработки, конфигурирования, использования и обслуживания сетей TCP/IP и соответствующих служб.
Книга написана увлекательно и доступно. Она содержит дополнительные материалы о нескольких протоколах Интернета, используемых серверами и браузерами WWW, а также рассматривает все последние изменения в этой области. В книгу включены главы о новом стандарте безопасности IP и протоколе IP следующего поколения, известном как IPng или IPv6. Рисунки и таблицы наглядно показывают влияние средств безопасности IP и IPng на существующие сетевые среды.
Издание содержит следующие дополнительные разделы:
• Безопасность IP и IPv6
• Описание средств WWW, новостей Интернета и приложений для работы с gopher
• Подробное описание серверов имен доменов (DNS), маски подсети и бесклассовой маршрутизации в Интернете
• Таблицы и протоколы маршрутизации
• Руководство по реализации средств безопасности для каждого из протоколов и приложений
• Примеры диалогов с новыми графическими инструментами
Новое издание бестселлера по TCP/IP станет незаменимым помощником для разработчиков сетей и приложений, для сетевых администраторов и конечных пользователей.
TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Для сервера DNS требуется, по крайней мере, следующая информация:
■ Список корневых серверов всего мира, чтобы выяснить, куда посылать внешние запросы. Файл такого списка можно скопировать с сервера регистрации InterNIC.
■ Список имен и соответствующих им адресов.
■ Список адресов и соответствующих им имен.
12.13 Элементы описании в DNS
Данные DNS хранятся как набор текстовых элементов. Информационная запись содержит следующие элементы:
[имя] [TTL] [класс] Тип_Записи Данные_Записи [; комментарий]
Время жизни (TTL) указывает, как долго может быть кеширована запись после извлечения.
Если этот параметр не указан, то используется значение по умолчанию для имени или класса последнего элемента, включенного в список. В Интернете в текущий момент используется единственный класс IN, поэтому данное значение появляется только один раз, в первой записи.
Порядок расположения полей класса и TTL может быть изменен. Значение TTL выражается числом и, следовательно, не может быть перепутано с классом (IN).
12.13.1 Записи о ресурсах
Эта часть элемента данных состоит из:
[TTL] [класс] Тип_записи Данные_записи
и называется записью о ресурсах (resource record — RR). Существует несколько типов записей о ресурсах, каждый из которых идентифицируется символом или коротким акронимом. Типы записей о ресурсах перечислены в таблице 12.1.
Таблица 12.1 Типы записей о ресурсах
| Тип записи | Описание |
|---|---|
| SOA | Start Of Authority (начало авторизации) — идентифицирует домен или зону, а также набор числовых параметров. |
| NS | Отображает имя домена на имя компьютера, авторитетного для данного домена. |
| A | Отображает имя системы на ее адрес. Если система (например, маршрутизатор) имеет несколько адресов, для каждого из них должна существовать отдельная запись. |
| CNAME | Отображает псевдоним на действительное каноническое имя . |
| MX | Mail Exchanger (обмен почтой). Идентифицирует систему, доставляющую в организацию сообщения электронной почты. |
| TXT | Обеспечивает способ добавления текстовых комментариев к базе данных. Например, запись txt может отображать fishfood.com на название компании, ее адрес или на номер телефона. |
| WKS | Well-Known Services (общеизвестные службы). Может перечислить доступные на хосте прикладные службы. Используется не слишком часто, если вообще применяется. |
| HINFO | Host Information (информация о хосте) — например тип компьютера и его модель. Используется редко. |
| PTR | Отображает IP-адрес на имя системы. Используется в файлах трансляции адресов в имена. |
12.14 Пример файла трансляции имен в адреса
Рис. 12.6 демонстрирует файл трансляции имен в адреса для нашего мифического домена fishfood.com . Файл содержит несколько комментариев, которые отмечены символом точки с запятой (;).
12.14.1 Записи SOA
Первой записью в файле стоит начало авторизации (Start of Authority — SOA):
FISHFOOD.COM. IN SOA NS.FISHFOOD.COM. (
postmaster.FISHFOOD.COM.
94101101 ; serial number
86400 ; refresh after 24 hours
7200 ; retry after 2 hours
2592000 ; expire after 30 days
345600 ; default TTL of 4 days
)
; fishfood.com file
FISHFOOD.COM. IN SOA NS.FISHFOOD.COM. (
postmaster.FlSHFOOD.COM.
94101101 ; serial number
86400 ; refresh after 24 hours
7200 ; retry after 2 hours
2592000 ; expire after 30 days
345600 ; default TTL of 4 days
)
FISHFOOD.COM. IN NS NS.FISHFOOD.COM.
FISHFOOD.COM. IN NS NS2.FISHFOOD.COM
LOCALHOST IN A 127.0.0.1
NS IN A 172.66.1.1
NS2 IN A 172.66.1.100
;
MAIL-RELAY IN A 172.66.1.2
IN TXT www, ftp on mail-relay
IN TXT gopher on mail-relay
IN HINFO SUN UNIX ; should not include
;
WWW IN CNAME MAIL-RELAY
FTP IN CNAME MAIL-RELAY
GOPHER IN CNAME MAIL-RELAY
;
FISHFOOD.COM. IN MX 1 MAIL-RELAY
* IN MX 1 MAIL-RELAY
NS IN MX 1 MAIL-RELAY
;end of fishfood.com file
;
Рис. 12.6.Пример файла трансляции имен в адреса
Круглые скобки в записи SOA позволяют расширить эту запись на следующие строки. В запись включено несколько значений тайм-аута (измеряются в секундах). Данная запись SOA указывает:
■ Сервер ns.fishfood.com является первичным для домена fishfood.com .
■ Сведения о всех возникающих проблемах нужно сообщать на postmaster@fishfood.com (следует заменить первую точку на символ @).
Вторичные серверы будут копировать файл целиком, получая при этом важную информацию из следующих четырех пунктов в записи SOA. Из приведенной выше записи каждый вторичный сервер узнает, что ему необходимо:
■ Соединяться с первичным сервером каждые 24 часа.
■ Проверять, не стал ли текущий порядковый номер меньше, чем порядковый номер первичного сервера. Если это произойдет, значит информация на первичном сервере была изменена, и вторичному серверу нужно выполнить перенос зоны, т.е. скопировать все сведения о зоне из базы данных первичного сервера в свою систему.
■ Повторить попытку соединения через 2 часа, если он не сможет соединиться с первичным в намеченное время.
■ Отметить все свои данные просроченными и прекратить отвечать на запросы, если он не сможет соединяться с первичным в течение 30 дней.
Показанные в примере значения рекомендованы (см. RFC 1537) для серверов верхнего уровня.
12.14.2 Время жизни (Time-To-Live)
В RFC 1035 (специфицирует протокол DNS) заявлено, что TTL в записи SOA — это минимальное значение тайм-аута, разрешенное для всех записей. Но на практике администратору хочется использовать TTL в записи SOA как значение по умолчанию, указывая меньшие значения только для определенных хостов, информация на которых должна быстро измениться. В реализации следуют этому более осмысленному действию, а не требованиям стандарта.
В приведенном примере значение по умолчанию (для TTL — 4 дня) обычно располагается в диапазоне от одного дня до недели, в зависимости от устойчивости данного элемента сайта.
12.14.3 Дополнение имени
Имя, которое не заканчивается точкой, дополняется именем домена для зоны, например fishfood.com . Таким образом, в этом файле ns будет соответствовать ns.fishfood.com .
12.14.4 Запись о сервере имен
Запись о сервере имен (Name Server — NS) идентифицирует сервер для домена. Если имеются подзоны, необходимы и элементы для дочерних серверов имен подзон, чтобы сервер с более высоким уровнем мог использовать указатели на серверы низшего уровня. Записи об адресе требуются для обеспечения доступа к дочерним серверам и называются связующими (glue records).
Отметим, что сервер с более высоким уровнем не авторитетен для дочерних серверов. Отвечать за дочерние серверы могут различные администраторы. Администратор родительского сервера должен проявлять осторожность при взаимодействии с администраторами дочерних серверов и отслеживать текущие изменения в списке имен и адресов дочерних серверов.
Читать дальшеИнтервал:
Закладка:
