Максимальный размер udp пакета. Протоколы передачи данных TCP и UDP. Как они используются

Faq 14.03.2019

Отображение адресов в имена

IP адрес записывается в десятично-точечной нотации . Для поиска доменных имен по IP адресам используется домен in-addr.arpa. Его поддоменами являются домены с простыми именами от 0 до 255, соответствующими старшему октету IP адреса. Их поддоменами явлются домены с простыми именами от 0 до 255, соответствующие второму октету IP адреса и т.д. до 4-го октета. Таким образом, IP адрес оказывается записанным в доменном имени в обратном порядке. Например, адресу 195.161.72.28 соответствует доменное имя 28.72.161.195.in-addr.arpa. (и значение PTR – deol.deol.ru). Обратная запись необходима для более легкого делегирования зон в соответствии с выделением IP адресов.

Зоны верхнего уровня в домене in-addr.arpa. делегированы IANA региональным регистраторам (RIR, Regional Internet Registrator) вместе с блоками IP-адресов.

RIPE для делегирования подзоны требует от LIR внесения информации в БД RIPE. Если вы представляете LIR, то должны были закончить специальные курсы, а если нет, то прав на внесение информации в БД RIPE вам не дадут и придется просить свой LIR. В БД должны быть как сеть (whois [email protected]), так и зона (whois [email protected])

Отображение адресов в имена может быть обязательным для работы некоторых сервисов Интернет: нет отображения – нет обслуживания.

Записи о ресурсах (RR, Resource Records)

Записи ресурсов могут быть представлены в текстовом формате в файле данных зоны и в двоичном формате при обмене сообщениями протокола DNS. Текстовый формат зоны может отличаться для различных реализаций DNS сервера, здесь описывается формат, упомянутый в стандарте (RFC 1035) и используемый в BIND 4/8/9. Файл зоны должен содержать записи только одного класса.

Каждая запись расположена на отдельной строке. Пустые строки игнорируются. Границы строк не распознаются внутри круглых скобок и текстовых литералов в кавычках. Разделителями полей являются пробелы и табуляции. Комментарии начинаются с символа точки с запятой в любом месте строки и продолжаются до конца строки. Кроме записей ресурсов файл зоны может содержать директивы $ORIGIN, $INCLUDE и $TTL (начиная с BIND 8.2). Символ “@” используется для обозначения текущего суффикса по умолчанию для относительных доменных имен. Обратная косая черта маскирует специальный смысл следующего символа. Возможно задание произвольных октетов в виде восьмеричных чисел (\012). Регистр букв не учитывается при поиске, но возвращается в ответе.

Директива $ORIGIN задает текущий суффикс по умолчанию для относительных доменных имен. Директива $INCLUDE вставляет указанный файл в файл зоны и задает (только для записей из вставляемого файла) текущий суффикс для относительных доменных имен (суффикс может быть опущен). В старых версиях BIND и его производных (например, in.named в Solaris 2.5) изменение суффикса не срабатывает (хотя и сообщения об ошибке не выдается!) и приходится “обрамлять” директиву $INCLUDE директивами изменения $ORIGIN и его восстановления. Директива $TTL задает TTL по умолчанию (RFC 2308).

Запись ресурса состоит из доменного имени (если опущено, то подразумевается значение из предыдущей записи ресурса), имени класса (может быть опущено и браться из предыдущей записи), TTL (число секунд, может быть опущено и браться из директивы $TTL для BIND 8.2 и новее или из поля MINIMUMTTL в SOA для старых версий; рекомендуемое значение – одни сутки; разумное – от 1 часа до недели; TTL всех записей с одинаковым ключом должны быть одинаковы), типа записи и данных записи (формат определяется классом и типом). В новых версиях (BIND ?) времена могут задаваться как в секундах, так и минутах (суффикс m), часах (суффикс h), днях (суффикс d), неделях (суффикс w). Только имена узлов обязаны соответствовать синтаксису доменных имен (буквы, цифры и минус), остальные (например, первая метка почтового адреса в записи SOA) могут состоять из произвольных символов ASCII.

Классы записей (в тяжелой эволюционной борьбе выжил только IN), в скобках – код для сообщений протокола DNS:

  • IN (1) – Интернет
  • CS (2) – CSNET
  • CH (3) – CHAOS
  • HS (4) – Hesiod

Типы записей, в скобках – код для сообщений протокола DNS:

BIND версии? позволяет дополнительно использовать директиву $GENERATE для создания последовательности RR, отличающихся лишь параметром:

$GENERATE интервал левая-часть тип-записи правая-часть

Интервал чисел задается либо в виде начало-конец, либо в виде начало-конец/шаг. По умолчанию, шаг равен 1. Левая часть задает правило формирования доменных имен для последовательности записей, у которых индекс пробегает от начало до конец с шагом шаг. Правая часть задает правило формирования данных записи (пока разрешены только типы PTR, CNAME, DNAME, A, AAAA и NS). В правилах одинокий символ $ заменяется текущим значением индекса. Значение индекса может быть модифицировано заданием смещения (вычитается из индекса), ширины поля (используется для форматирования результата) и системы счисления (d, o, x, X) в фигурных скобках через запятую. Если получилось относительное имя, то оно дополняется текущим суффиксом. Используется в основном для автоматической генерации обратных зон:

$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-127 $ CNAME $.0

преобразуется в

1.0.0.192.IN-ADDR.ARPA CNAME 1.0.0.0.192.IN-ADDR.ARPA
2.0.0.192.IN-ADDR.ARPA CNAME 2.0.0.0.192.IN-ADDR.ARPA
...
127.0.0.192.IN-ADDR.ARPA CNAME 127.0.0.0.192.IN-ADDR.ARPA

Протокол DNS

Запросы и ответы DNS обычно используют протокол UDP (порт 53, domain ), однако могут использовать и протокол TCP (порт 53, domain). Каждое сообщение полностью помещается в один UDP пакет, стало быть не может быть более 64 KB. В реальности, многие реализации имеют ограничение на размер нефрагментируемого UDP пакета в 576 байт. В такой пакет помещается информация о 10 записях типа NS в общем случае. Доменные имена корневых серверов Интернет были помещены в один домен, что позволило упаковать информацию с помощью ссылок (см. ниже) о 13 серверах. Если ответ не поместился в один фрагмент UDP, то в заголовке устанавливается бит TC (truncated), что приводит к повторному запросу с использованием протокола TCP. При использовании протокола TCP к каждому сообщению добавляется префикс (2 байта), содержащий длину сообщения без учета префикса. Первым передается левый бит (нулевой) – старший по значению.

Формат запросов и ответов одинаков (подробнее см. RFC 1035 )

Расширение протокола TSIG

RFC 2845 расширяет протокол DNS возможностью проверки целостности запросов и ответов (QUERY), передачу зон, а также аутентификацию динамических изменений (UPDATE, RFC 2136) с помощью криптографически стойких контрольных сумм – TSIG (transaction signatures). При генерации хеша используется алгоритм HMAC-MD5 и разделяемый между двумя участниками секрет (симметричный ключ). Механизм распределения ключей не определяется. Участники транзакции могут разделять несколько ключей, поэтому для идентификации конкретного ключа используется его имя в формате доменного имени. Для предотвращения атак повторного воспроизведения запись содержит время подписи (требуется синхронизация времени с помощью, например, NTP). Отвечая на защищенный запрос сервер посылает ответ, защищенный тем же алгоритмом и ключом. В качестве ключей рекомендуется использовать случайные последовательности длиной не менее 128 бит.

Данный механизм требует меньшей нагрузки на процессор и меньших затрат на создание инфраструктуры при небольшом количестве узлов по сравнению с DNSSEC с его механизмами ассиметричного шифрования и публичных ключей (RFC 2535, RFC 2137). С другой стороны DNSSEC позволяет легко масштабировать установленную инфраструктуру распределения ключей и обеспечивать цифровую подпись (TSIG несмотря на название не позволяет производить подтверждение авторства запросов из-за симметричности ключа).

RFC 2845 вводит новый тип записи TSIG (250) и несколько новых кодов ответа. Запись типа TSIG является виртуальной, т.е. вычисляется во время транзакции, не содержится в файле данных зоны и не кешируется. Запись добавляется в раздел дополнительных данных; включает имя разделяемого ключа, класс (ANY), TTL (0), имя алгоритма (сейчас всегда HMAC-MD5), время подписи, интервал отклонения времени, хеш, идентификатор исходного сообщения (используется при ретрансляции динамических изменений), код ошибки, дополнительный данные об ошибке (например, расхождение часов участников). Для генерации хеша используется исходное сообщение, имя ключа, класс, TTL, имя алгоритма, время подписи, интервал отклонения времени. При генерации хеша ответа в исходные данные включается также хеш запроса.

Динамические изменения зоны

RFC 2136 расширяет протокол DNS возможностью динамического изменения содержимого зоны по требованию клиента. Это избавляет от необходимости при частых изменениях (например, работа DHCP) редактировать текстовый файл с описанием зоны и перезапускать сервер. С помощью данного расширения можно одним пакетом внести несколько изменений в зону, управляемую данным первичным уполномоченным сервером (все доменные имена должны быть внутри зоны):

  • добавить запись ресурса (RR) в набор записей ресурсов (RRset); записи типа SOA и CNAME не добавляются, а замещаются; если SOA не было или её серийный номер был больше, то добавление игнорируется; попытка заменить нормальный набор записей на CNAME или CNAME на нормальный набор записей игнорируется; попытка добавить дублирующую запись игнорируется
  • удалить запись ресурса (RR) с заданным значением из набора записей ресурсов (RRset); не удаляются последняя запись NS и SOA самой зоны; попытка удалить несуществующую запись игнорируется
  • удалить набор записей ресурсов (RRset); не удаляются записи NS и SOA самой зоны; попытка удалить несуществующий набор игнорируется
  • удалить все наборы ресурсов, относящиеся к указанному доменному имени; не удаляются записи NS и SOA самой зоны; попытка удалить несуществующий набор игнорируется

Набор изменений может быть предварён набором условий следующих типов (все доменные имена должны быть внутри зоны):

  • указанное доменное имя имеет хотя бы одну запись ресурса указанного типа
  • указанное доменное имя имеет записи ресурсов указанного типа с заданными значениями (значение TTL не учитывается, при сравнении имён прописные и строчные буквы не различаются, шаблоны не обрабатываются, синонимы (CNAME) не обрабатываются)
  • указанное доменное имя не имеет ни одной записи ресурса указанного типа
  • указанное доменное имя имеет хотя бы одну запись ресурса
  • указанное доменное имя не имеет ни одной записи ресурса

есь пакет условий и изменений является атомарным, т.е. обрабатывается как единое неделимое целое (как транзакция в СУБД). При этом сервер обязан записать изменения на диск до ответа клиенту. bind временно записывает изменения в журнал и сливает его с файлом зоны позднее. Если изменения не затронули SOA, то сервер должен увеличить серийный номер автоматически. Метод стандартом не задаётся. Если автоувеличение серийного номера производится с задержкой, но она не должна быть более 300 секунд или 1/3 от времени обновления зоны.

RFC 2136 вводит новый класс NONE (254) и несколько новых кодов ответа. Формат запросов и ответов совпадает с форматом обычных запросов и ответов, но имеет код запроса – UPDATE (5). Секция запроса содержит имя изменяемой зоны (ровно одна запись ресурса типа SOA), секция ответа – набор условий, секция ссылок на уполномоченные сервера – добавляемые или удаляемые записи, секция дополнительной информации – связующие записи доменных имён вне зоны (может игнорироваться сервером).

Клиент может получить список потенциальных серверов из записей SOA, NS или внешними средствами.

Сервер может проверять право клиента на изменение зоны по его IP адресу (не рекомендуется) или при помощи механизма TSIG.

Вторичный уполномоченный сервер, получивший запрос на динамическое изменение зоны, может перенаправить его первичному серверу от своего имени (изменив идентификатор запроса) и получив ответ вернуть его клиенту. Тот в свою очередь может переправить его дальше и т.д.. Список используемых серверов совпадает со списком серверов, к которым выдаются запросы на передачу зоны. Если клиент использовал для запроса TCP (рекомендуется, если имеется обработка результата), то вторичный сервер должен использовать для перенаправления запроса также TCP.

Обеспечение правильного порядка применения изменений (так чтобы “задержавшиеся в пути” старые изменения не перекрывали более новые) является нетривиальной задачей в среде TCP/IP, особенно при наличии нескольких делающих запросы клиентов и нескольких перенаправляющих вторичных серверов. Ответ сервера также может задержаться или затеряться. Авторы RFC рекомендуют пользоваться “маркерными” записями ресурсов для обеспечения синхронизации (такой маркер может, например, содержать время выдачи запроса).

DNS клиент (resolver)

Клиенты DNS обычно реализуются в виде библиотеки подпрограмм, присоединяемых к каждой программе (статически или динамически), которой требуется сервис доменных имен. Простой (stub) клиент обращается к указанному при настройке DNS серверу (серверам), интерпретирует ответ и возвращает результат запросившей программе. Реализация клиента в Solaris (Solaris 2.5.1 и младше соответствует BIND 4.8.3; с заплатками – BIND 4.9.3; Solaris 2.6, 7 и 8 – BIND 4.9.4-P1) и Linux (клиент DNS входит в состав пакета glibc, а не bind) позволяет также получить информацию из других источников (локальный файл, NIS, NIS+ и т.д.) в зависимости от настройки Name Service Switch. Некоторые клиенты позволяют кешировать информацию самостоятельно, либо с помощью nscd.

Общий алгоритм запроса таков: прикладная программа, которой необходимо, например, получить адрес хоста по его имени, вызывает подпрограмму gethostbyname(3) или аналогичную ей. При сборке программы к ней прилинковываются подпрограммы из библиотеки libc (glibc), которые проверяют наличие требуемой информации в кеше nscd (если, конечно, запущен сервер nscd). Если информацию из кеша извлечь не удалось, то используется NSS для определения сервиса имен, который (которые) будет использован для поиска адреса по имени. В частности, в настройках NSS может быть указан dns в качестве сервиса имен для поиска доменных имен. В этом случае используются функции, указанные в resolver(3), которые и являются “настоящим” клиентом DNS (они формируют запрос к серверу в соответствии с DNS протоколом и обрабатывают ответ).

Настройка работы клиента DNS производится с помощью файла /etc/resolv.conf или переменных окружения при запуске процесса.

Каждая строка /etc/resolv.conf содержит одну инструкцию, комментарии начинаются с точки с запятой или символа # (осторожно! клиент может не сообщать об ошибках в этом файле!):

  • nameserver IP-адрес-обслуживающего-сервера (можно указать до 3 строк с адресами серверов; по умолчанию используется сервер, расположенный на этом же хосте (его также можно указать с помощью его IP адреса или адреса 0.0.0.0 или loopback адреса 127.0.0.1); клиент опрашивает указанные сервера в порядке их перечисления, если не дождался ответа от предыдущего сервера из списка или получил сообщение об ошибке (недоступен порт на сервере, хост сервера или вся сеть); опрос по списку повторяется несколько раз в зависимости от версии клиента (от 2 до 4); интервал первоначального ожидания зависит от версии (от 2 до 5 секунд) и числа серверов в списке; при каждом следующем прохождении по списку интервал ожидания удваивается; суммарное время ожидания достигает 80 секунд для версии до 8.2 и 24 секунд для более новых версий)
  • domain имя-локального-домена (добавляется к относительным доменным именам перед поиском; точка в конце имени не нужна; по умолчанию извлекается из доменного имени хоста (см. hostname(1)); имя локального домена также задает список поиска по умолчанию (для bind 4.8.3: имя локального домена и список его предков, имеющих не менее 2 простых имен; для новых версий bind: только имя локального домена))
  • search список-имен-доменов-через-пробел (до 6 имен доменов в порядке предпочтения; первое имя в списке устанавливает имя локального домена; инструкции domain и search – взаимоисключающие (выполняется последняя из них); список поиска используется для разрешения относительных доменных имен; для bind 4.8.3 разрешение относительного имени делается сначала по списку поиска (имена доменов из списка поиска приписываются по очереди справа от относительного имени перед запросом к серверу DNS), при неудаче имя считается абсолютным и делается еще один запрос; для новых версий bind сначала разрешение для относительного имени, содержащего хотя бы одну точку, делается так как будто оно является абсолютным, при неудаче используется список поиска)
  • sortlist IP-адрес-сети/маска … (версия 4.9 и выше; позволяет клиенту отдавать предпочтение указанным сетям при получении ответов, содержащих несколько адресов – их он помещает в начало списка, остальные в конец; можно указывать до 10 сетей)
  • options опция … (версия 4.9 и выше; позволяет изменять настройки клиента
    • debug (на stdout)
    • ndots:число-точек (минимальное число точек в аргументе, при котором поиск по имени осуществляется до использования списка поиска; по умолчанию – 1)
    • attempts:число-опросов-списка-серверов (по умолчанию – 2; максимум – 5)
    • timeout:начальный-интервал-ожидания (по умолчанию – 5 секунд; максимум – 30 секунд)
    • rotate (при каждом обращении использовать другой порядок серверов с целью распределения нагрузки; распределение осуществляется только в рамках одного процесса – при следующем запуске программы первый сервер в списке опять станет первым используемым)
    • no-check-names (запретить лексическую проверку простых имен, которая включена в версии 4.9.4 и старше)

Конкретная реализация resolver(3) может иметь другие значения параметров по умолчанию – смотри /usr/include/resolv.h. Различные программы могут быть собраны с различными версиями клиента DNS. К счастью, клиент DNS пропускает непонятные ему строки из файла /etc/resolv.conf. Старые версии клиента DNS (resolv+) могут управляться файлом /etc/host.conf, в этом случае см. host.conf(5). Некоторые программы самостоятельно устанавливают нестандартные значения параметров клиента DNS при инициализации.

Переменная окружения LOCALDOMAIN перекрывает действие инструкций domain и search. Переменная окружения RES_OPTIONS перекрывает действие инструкции options. Переменная окружения HOSTALIASES позволяет задать имя файла (например, /etc/host.aliases), содержащего список синонимов доменных имен (по одному простому имени и его доменному синониму без завершающей точки на строке через пробел).

Если при загрузке компьютера требуется наличие работающего локального сервера DNS (обычно из-за указания доменных имен в ifconfig или route), то желательно обеспечить резервный метод разрешения доменных имен с помощью настройки NSS и заполнения /etc/hosts, иначе клиентские компьютеры будут вынуждены дожидаться загрузки одного из серверов DNS. Тем более важно обеспечить резервный метод для хостов, на которых работают серверы DNS. А лучше всего не использовать DNS во время загрузки. Ещё имеется загадочный файл /etc/ppp/resolv.conf.

Настройка DNS в MS Windows производится с помощью графического интерфейса. Изготовитель уверяет, что это очень просто;). Вот только отличаются реализации клиента DNS в различных версиях MS Windows больше, чем Unix от Linux (в частности, TCP/IP стек в W2000 и XP взят из FreeBSD (NetBSD?):

  • W95 – отдельные стеки для локальной сети (Control Panel -> Network -> TCP/IP -> DNS) и коммутируемых соединений (My Computer -> Dial-up Networking -> right click на нужном соединении -> Properties -> Server Types -> TCP/IP); при использовании коммутируемого доступа рекомендуется оставлять пустым список DNS серверов в основном стеке и выбирать вариант “Server assigned name server addresses” при настройке коммутируемых соединений
  • W98 – визуально настройка ничем не отличается; возвращаемые сервером адреса сортируются в соответствии с таблицей маршрутизации; клиент работает одновременно и с серверами, указанными для основного стека, и с серверами, указанными для данного коммутируемого соединения
  • NT – визуально очень похоже на W95; настройки для основного стека (Control Panel -> Network -> Protocols -> TCP/IP -> DNS) и коммутируемого соединения (My Computer -> Dial-up Networking -> выбрать нужное соединение из выпадающего меню -> More -> Edit Entry -> Modem Properies -> Server -> TCP/IP) используются в нужное время; клиент кеширует полученные результаты (в пределах процесса); в SP4 клиент после неудачи с первым сервером начинает рассылать запросы всем известным ему серверам параллельно
  • W2000 (Start -> Setting -> Network and Dial-up -> right click на Local Area Connection -> Properies -> TCP/IP); поведение клиента аналогично NT SP4

Сервера DNS

Немного позднее опубликую статью о Bind 9

Статья взята с сайта Bog BOS , автор Сергей Евгеньевич Богомолов.


Служба Доменных Имен предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.

Служба Доменных Имен была разработана для именования машин в глобальной сети. Основной особенностью глобальной сети является распределенное администрирование, когда один администратор физически не может уследить за выделением имен. Поэтому Служба Доменных Имен функционирует на принципе делегирования полномочий. Каждая машина либо знает ответ на вопрос, либо знает кого спросить. При правильном функционировании система замкнута, т.е. если запрошенная информация имеется у кого-либо, то она будет найдена и сообщена клиенту, либо, если вопрос не имеет ответа, клиент получит сообщение о невозможности получения ответа на вопрос.

Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".

Имеется некий домен верхнего уровня, обозначаемый точкой: ".". Имеется девять серверов (по крайней мере на моем Name-сервере записано столько), которые отвечают за эту зону. Они не знают ни одного доменного имени - они только авторизуют серверы верхних зон. Серверы верхних зон тоже гнушаются хранить информацию о конкретных машинах и передают это право нижележащим серверам. Тут уже появляются первые упоминания о конкретных машинах, равно как и происходит авторизация нижележащих серверов.

Мне неизвестна ни одна машина с доменным именем из одного сегмента; очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко, а из шести и более мне неизвестны.

Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:

  1. Клиент спрашивает своего сервера.
  2. Если тот является сервером данной зоны, то ответит, на чем все заканчивается.
  3. Сервер спрашивает корневой сервер.
  4. Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна".
  5. Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город.страна".
  6. Тот в свою очередь отсылает запрос серверу зоны "организация.город.страна", который сообщит нужную информацию.

Это приближенная модель, которая тем не менее позволяет представить работу системы DNS.

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

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

Хочу обратить особое внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран. Имена серверов выглядят так:

Ftp.freebsd.org первичный сервер в США ftp.страна.freebsd.org основной сервер в стране ftpчисло.страна.freebsd.org дополнительный сервер в стране

  • ftp.ru.freebsd.org соответствует ftp.ru
  • ftp2.ru.freebsd.org соответствует ftp.gamma.ru
  • ftp3.ru.freebsd.org соответствует ftp.chg.ru

Таким образом, машины, находящиеся в России оказались произвольно (по воле DNS-мастера из университета Bercley) включенными в домен freebsd.org; однако, они также состоят в своих зонах. Система DNS позволяет любому DNS-мастеру включить любой сервер в свою зону, хотя это включение никого ни к чему не обязывает.

Однако, некоторым сервисам этого недостаточно - так E-mail требует, чтобы машина, принимающая письмо, признала своим адрес, указанный в качестве пункта назначения. Протокол HTTP 1.1 (в 1.0 этого не было) требует, чтобы в HTTP-запросе указывался не путь к файлу, отсчитанный от корня сервера (хотя такие запросы тоже признаются), но и имя сервера; при этом сам сервер знает, какие имена - его, а остальные обрезает и обслуживает в соответствии с HTTP 1.0.

Делегирование зоны...in-addr.arpa дается только от провайдера вместе с IP-адресами. Собственно, это связано с предназначением ReverceDNS - сообщать доменное имя по IP-адресу. Наверняка мастер зоны freebsd.org держит Reverce-зону для IP-номеров, выделенных университету Bercley; но все эти серверы (кроме сервера, расположенного в университете) не входят в эту Reverce-зону, а значит, ему неподконтрольны.

Одна из проблем состит в том, что Reverce-зону можно выделить только на сеть класса A, B или C (на 16777216, 65536 или 256 адресов) и никак иначе. Можно получить правА на несколько зон одного или разных классов, но что делать тем, кому выделили меньше 256 адресов? А ведь в условиях исчерпания адресного пространства не редкость выделения пула уже на 16 адресов!

DNS-услуги Internet-провайдера

Как правило, провайдер предоставляет клиенту целый комплекс услуг. В число оказываемых DNS-услуг входят:

  • делегирование зоны...in-addr.arpa клиентам, имеющим пул адресов, кратный 256.
  • регистрация доменного имени клиента у держателя той зоны, в которой клиент хочет зарегистрироваться;
  • поддержание вторичного сервера прямой и обратной DNS-зон клиента;
  • поддержание первичного сервера этих зон, если клиент по какой-либо причине не поддерживает их сам (особенно это относится к случаю виртуальных зон и к случаю выделения малого пула адресов);

Если провайдер будет отказываться - сошлитесь на меня. :-)

Политика и стратегия назначения имен

Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегестрированы следующие "организационные" зоны:

Com commercial (коммерческие) edu educational (образовательные) gov goverment (правительственные) mil military (военные) net network (организации, обеспечивающие работу сети) org organization (некоммерческие организации)

В данный момент, чтобы разгрузить домен com, собираются создать несколько новых доменов, но у меня нет достоверной информации по ним. В организационных зонах обычно размещаются непосредственно домены организаций.

Каждая страна (государство) имеет свой географический домен из двух букв:

Ae United Arab Emirates (Объединенные Арабские Эмираты) au Australia (Австралия) be Belgium (Бельгия) br Brazil (Бразилия) by Belarus (Белоруссия) ca Canada (Канада) ch Switzerland (Швейцария) cz Czech Republic (Чехия) de Germany (Германия) dk Denmark do Dominican Republic (Доминиканская республика) ee Estonia (Эстония) eo ??? es Spain (Испания) fi Finland (Финляндия) fr France (Франция) hu Hungary (Венгрия) il Israel (Израиль) in India (Индия) iz ??? jp Japan (Япония) kg Kyrgyzstan (Кыргызстан) kr South Korea (Южная Корея) kz Kazakhstan (Казахстан) lt Lithuania (Литва) lv Latvia (Латвия) mx Mexico (Мексика) nl Netherlands (Нидерланды) no Norway (Норвегия) nz New Zealand (Новая Зеландия) pl Poland (Польша) ro Romania (Румыния) ru Russia (Россия) si Slovenia (Словения) sk Slovak Republic (Словакия) su Soviet Union (Советский Союз - поддерживается, но не распределяется) ua Ukraine (Украина) uk United Kingdom (Соединенное Королевство ВеликоБритания / Англия) yu Yugoslavia (Югославия) za South Africa (Южная Африка)

Я перечислил отнюдь не все страны - кто хочет, может прислать мне другие названия.

В зонах государств опять же имеются "организационные" и "географические" зоны. "Организационные" в большинстве своем повторяют структуру "организационных" зон верхнего уровня, разве что вместо "com" используется "co". "Географические" выделяются городам, областям и т.п. территориальным образованиям. Непосредственно в тех и других размещаются домены организаций или домены персональных пользователей.

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

С левого конца доменного имени находятся имена машин. Имена бывают "собственные" и "функциональные". Имена "собственные" каждый придумавает в меру фантазии: машинам присваиваются имена членов семьи, животных, растений, музыкантов и артистов, литературных персонажей - кто во что горазд.

Имена "функциональные" вытекают из функций, выполняемых машиной:

Www HTTP (WWW) сервер ftp FTP сервер ns, nss, dns DNS (Name) сервер mail Mail сервер relay Mail Exchanger *proxy соответствующий Proxy сервер

Я считаю нежелательным присваивать какой-либо машине функциональное имя - в любой момент может потребоваться перенести соответствующую функцию на другую машину. Для этого лучше всего использовать псевдонимы, которые перенаправляют запросы к данному имени на записи, относящиеся к другому имени. Но вот ссылаться на псевдонимы при обьявлении Mail Exchanger"ов и вообще использовать их в правой части записей считается нежелательным, а зачастую является недопустимым

Определение

DNS (Domain Name System, «система доменных имён») - компьютерная распределённая система для получения информации о доменах. Основная область применения данной системы - преобразование имени хоста в IP-адрес и предоставления данных о маршрутизации почты. Хост - это любой компьютер или сервер, подключенный к локальной сети или интернету.

Принцип работы

Схематичное представление процесса определения определения IP-адреса по вводимому имени домена

Работа DNS достаточно проста, но из-за незнания её основ возникает основная масса проблем и вопросов при переносе существующего доменного имени и регистрации нового.

Остановимся немного подробней на описании самой схемы.

  • Когда пользователь запускает веб-браузер и вводит название домена сайта, его ПК отправляет запрос к DNS-серверу интернет-провайдера для получения IP-адреса, на котором находится домен (1).
  • Если DNS-серверы провайдера не обнаруживают в своем кэше информации о запрашиваемом сайте, то отправляют запрос на корневые DNS-серверы (2).
  • Корневой DNS-сервер ищет в своей базе данных информацию о серверах имен хостинг-провайдера, на которых присутствует этот сайт. Далее, он сообщает их кэширующему DNS-серверу провайдера (3).
  • После того, как кэширующий DNS-сервер интернет-провайдера получает информацию о серверах имен хостинг-провайдера он опрашивает любой из них (4) и, в случае получения положительного результата получения IP-адреса (5), помещает в кэш. Кэширование используется для того, чтобы снизить как нагрузку на интернет-каналы, так и для ускорения получения результата запроса.
  • После этого DNS-сервер провайдера передает IP-адрес браузеру пользователя, совершившему запрос сайта (6).
  • И уже после этого браузер, получив IP-адрес запрашиваемого сайта, переходит на сам сайт (7 и 8).

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

Так же если кто-либо из пользователей вашего интернет-провайдера заходил на сайт и после этого сайт изменил IP-адрес или сервера имен, то в базе данных кеширующего DNS-сервера провайдера останется старая информация до тех пор, пока кеш не обновится. И до этого момента при запросе сайта будет предоставляться устаревшая информация о месторасположении (IP-адрес). Хотя пользователям с других провайдеров сайт может открываться уже с нового IP-адреса.

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

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

Диагностика и решение проблем

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

Являясь провайдером виртуальной инфраструктуры, компания 1cloud интересуется сетевыми технологиями, о которых мы регулярно рассказываем в своем блоге. Сегодня мы подготовили материал, затрагивающий тему доменных имен. В нем мы рассмотрим базовые аспекты функционирования DNS и вопросы безопасности DNS-серверов.

Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.

Кто управляет и поддерживает DNS-сервера?

Когда вы вводите адрес интернет-ресурса в строку браузера, он отправляет запрос на DNS-сервер отвечающий за корневую зону. Таких серверов 13 и они управляются различными операторами и организациями. Например, сервер a.root-servers.net имеет IP-адрес 198.41.0.4 и находится в ведении компании Verisign, а e.root-servers.net (192.203.230.10) обслуживает НАСА.

Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.

Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.

После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.

Также стоит отметить утилиту dns-validator, которая наблюдает за передачей всех пакетов DNS, сопоставляет каждый запрос с ответом и в случае несовпадения заголовков уведомляет об этом пользователя. Подробная информация доступна в



Рекомендуем почитать