Практическая реализация DNS
Общий принцип работы системы доменных имен (DNS) понятен и довольно прост. Поэтому предполагается, что Вы уже знакомы с доменами, зонами и подобными терминами и понимаете, как они работают. Хотелось бы сосредоточиться на практической реализации протокола, с точки зрения администратора, использующего сетевые мониторы, или программиста. Примеры кода, иллюстрирующие работу протокола, приведены на Java, но легко могут быть перенесены на другой язык.
Клиент отправляет UDP(TCP) пакет на порт 53 сервера с запросом отобразить имя ресурса в IP адрес (или наоборот). На сервер возлагается задача произвести работу по нахождению запрашиваемой информации. Работа по нахождению данной информации сводится к рекурсивным или итеративным запросам, но, в любом случае, работа скрыта от клиента: стандартный клиент ожидает либо ответа, либо ошибки.
В данной статье описывается процесс работы DNS с точки зрения программиста, разрабатывающего клиента или сервер.
Исходя из следующих предпосылок, приводится дальнейшее описание: клиент с сервером обращаются по протоколу UDP, где клиентом является OS Windows. Операционные системы от Microsoft работают с небольшими отличиями от стандартной схемы - это незаметно для пользователя, но важно для администратора. Связанно это с ориентировкой на работу в рамках доменов. Каждый компьютер имеет имя и принадлежит определенному домену, как, например, на рис. 1.
[ZEBR_TAG_p align="center"> рис. 1. Полное имя ресурса computer.office.acme.com.
Когда возникает необходимость в разрешении имени, работает следующая схема:
Нам надо узнать IP адрес сайта "www.yahoo.com" (без точки в конце). Компьютер клиента автоматически добавит имя домена, к которому принадлежит компьютер, т.е. на самом деле DNS запрос будет содержать имя: "www.yahoo.com.office.acme.com.".
Корпоративный сервер, ответственный за зону office.acme.com, не сможет найти ответ и возвратит клиенту ошибку, после чего сразу переспросит сервер "www.yahoo.com.". Сервер уже сможет обработать этот запрос и дать нужный или нужные IP адреса.
Для того, чтобы сервер не прибавлял суффикс достаточно в конце имени добавить точку. Кроме того, если запрос не содержит точки, например "user1", то выполняется добавление суффикса, а без него запроса не последует.
В настройках TCP/IP можно указать дополнительные суффиксы.
Стоит заметить, что полное имя ресурса должно заканчиваться точкой (www.yahoo.com.), но это правило только для пользователей, в самих сетевых пакетах финальная точка в явном виде отсутствует.
Начнем с общего формата пакета: он одинаков и для запросов, и для ответов.
Первые два байта являются идентификатором. Это числа, по которым клиент может определить, на какой из его вопросов пришел ответ, и, кроме того, обеспечивает минимальную страховку того, что ответ получен из достоверного источника.
Сервер должен скопировать идентификатор в ответ, без этого пакет просто будет отброшен клиентом.
Следующие два байта это флаги.
| Кол-во бит | ||
| Тип сообщения | 1 | QR |
| Код операции | 4 | Opcode |
| Авторитетный ответ | 1 | AA |
| Фрагментация | 1 | TC |
| Требование рекурсии | 1 | RD |
| Возможность рекурсии | 1 | RA |
| Нулевое поле | 3 | |
| Код возврата | 4 | Rcode |
Код операции: это ноль для обычного запроса и 1 для инверсного.
Авторитетный ответ устанавливается сервером, ответственным за зону.
Фрагментация устанавливается, если информация не уместилась в 512 байт.
Требование рекурсии, как правило, всегда установлено, что переносит всю ответственность за разрешение с клиента на сервер.
Возможность рекурсии устанавливается сервером в ответе.
Код возврата ноль в случае успеха и 3 при ошибке имени.
Остальные варианты опций описаны в RFC 1035, но для реализации простой схемы диалога сервера с клиентом они не требуются.
Далее следуют четыре 2х байтовых поля, которые содержат количество значений в полях с переменными длинами. Вместе с байтами идентификации и флагами они составляют заголовок DNS пакета.
Схематично заголовок выглядит следующим образом:
| 0 | 15 |
| Идентификация | |
| Флаги | |
| Количество вопросов | |
| Количество ответов | |
| Кол-во прав доступа | |
| Кол-во дополнительной инф. |
Общая длина заголовка - 12 байт, после которого следуют поля переменной длины. Нас будут интересовать только секции вопросов и ответов. В пакете от клиента количество вопросов, как правило, равно единице. А в пакете от сервера количество ответов как минимум один. Остальные счетчики будем устанавливать в ноль.
Обе секции (вопросы и ответы) имеют одинаковое начало: переменное количество байт, отведенное на имя, два байта на тип, и два - на класс. Класс будет всегда единицей. Типы - A, NS, MX, CNAME и т.д. Например, для типа A поле будет установлено в единицу, а для MX - 15. Для запросов и ответов имя кодируется одинаково. Все символы представляются своими ASCII кодами за исключением точек. Точки разделяют имя на части, а сами заменяются длинами этих частей. Для примера: www.yahoo.com.
Будет представлено в виде последовательности байт: 3www5yahoo3com0 - буквы представляются кодами.
При этом финальный ноль является обязательным, т.к. является маркером конца имени.
Теперь у нас есть достаточно информации, чтобы составить клиентский пакет, который запрашивает IP адрес хоста "aaa."
byte[] question={2,34,1,0,0,1,0,0,0,0,0,0,3,97,97,97,0,0,1,0,1};
2,34 - это идентификаторы, выбранные случайным образом
За ними следуют два байта флагов, которые сообщают о том, что это стандартный запрос, требующий рекурсию.
Следующие два байта - это кол-во вопросов, т.е. один. При этом остальных полей переменной длины нет.
Вопрос начинается сразу после заголовка - 12й байт, считая с нуля.
Такую же последовательность, за исключением идентификатора, можно увидеть сетевым монитором, сформировав запрос "aaa" с помощью утилиты nslookup.
В общем случае, сервер, приняв подобный пакет, должен выделить имя и тип.
//получение текста имени из вопроса int i=12; String s=""; String QUESTION;
while (data[i]>0) { if (s.length()>0) {s+=".";} if ((data[i]+i+1)>=len) {s="";break;} s += new String(data, i+1, data[i]); i+=data[i]+1; } QUESTION = s;
Далее сервер реализует поиск имени по собственной базе или отправляет запрос другому серверу, но в любом случае он должен сформировать ответ для клиента.
Секция ответа состоит из полей имени ресурса, типа и класса, описанных выше. При этом их содержание можно полностью скопировать из запроса. За ними следуют четыре байта поля TTL (time-to-live), содержащее количество секунд, на которое можно кэшировать запрос (заполняем нулями). Следующие два байта - это длина данных ресурса, и сами ресурсы. В ресурс помещается информация об ответе. Как указывается в RFC 1035, она зависит от типа запроса, но в нашем случае это будут четыре байта под IP адрес.
Приведем пример ответа на предыдущий запрос:
byte[] reply={2,34,133,128,0,0,0,1,0,0,0,0,3,97,97,97,0,0,1,0,1,0,0,0,0,0,4,5,6,7,8};
Тут количество вопросов - ноль, ответов - один. И ответ устанавливает соответствие имени хоста "aaa." с IP адресом 5.6.7.8 и TTL равным 0.
Стоит обратить внимание на флаги: 133 - авторитетный ответ, 128 - сервер поддерживает рекурсию.
В качестве завершающего примера приведу код сервера, который принимает DNS пакет и генерирует ответ. При этом вне зависимости оттого, что спросит клиент, ответ будет содержать "aaa" и IP адрес 5.6.7.8
После компиляции проверить это можно при помощи утилиты nslookup
import java.net.*; import java.io.*;
class udptest {
public static void main(String arg[]) { byte id1,id2,flags; int qtype;
try { byte[] buffer = new byte[512]; DatagramPacket incoming = new DatagramPacket(buffer, buffer.length); DatagramSocket ds = new DatagramSocket(53); ds.receive(incoming); byte[] data = incoming.getData(); id1=data[0]; id2=data[1]; int i=12; String s="";
while (data[i]>0) { if (s.length()>0) {s+=".";} s += new String(data, i+1, data[i]); i+=data[i]+1; } i++; byte[] reply={0,0,0,0,0,0,0,1,0,0,0,0,3,97,97,97,0,0,1,0,1,0,0,0,0,0,4,5,6,7,8}; reply[0]=id1; reply[1]=id2; reply[2]=0&133; reply[3]=0;
DatagramPacket out = new DatagramPacket(reply,reply.length, incoming.getAddress(), incoming.getPort());
ds.send(out); } catch (IOException e) {System.err.println(e);} }//main
}//class
