Пример практической реализации dns
Далее более подробно описана практическая реализация протокола, с точки зрения администратора, использующего сетевые мониторы, или программиста. Примеры кода, иллюстрирующие работу протокола, приведены на Java, но легко могут быть перенесены на другой язык.
Клиент отправляет UDP(TCP) пакет на порт 53 сервера с запросом отобразить имя ресурса в IP адрес (или наоборот). На сервер возлагается задача произвести работу по нахождению запрашиваемой информации. Работа по нахождению данной информации сводится к рекурсивным или итеративным запросам, но, в любом случае, работа скрыта от клиента: клиент ожидает либо ответа, либо ошибки.
Исходя из следующих предпосылок, приводится дальнейшее описание: клиент с сервером обращаются по протоколу UDP, где клиентом является OS Windows. Операционные системы от Microsoft работают с небольшими отличиями от стандартной схемы - это незаметно для пользователя, но важно для администратора. Это связано с ориентировкой на работу в рамках доменов. Каждый компьютер имеет имя и принадлежит определенному домену (рис. 9).
Рис. 9. Полное имя ресурса 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.), но это правило только для пользователей, в самих сетевых пакетах финальная точка в явном виде отсутствует.
Общий формат пакета одинаков и для запросов, и для ответов.
Первые два байта являются идентификатором. Это числа, по которым клиент может определить, на какой из его запросов пришел ответ, и, кроме того, обеспечивает минимальную страховку того, что ответ получен из достоверного источника.
Сервер должен скопировать идентификатор в ответ, без этого пакет просто будет отброшен клиентом.
Следующие два байта это флаги.
Таблица № 5. Идентификатор пакета
Поле |
Кол-во бит |
Тип сообщения |
1 |
Код операции |
4 |
Авторитетный ответ |
1 |
Фрагментация |
1 |
Требование рекурсии |
1 |
Возможность рекурсии |
1 |
Нулевое поле |
3 |
Код возврата |
4 |
Тип сообщения: 0 - запрос клиента, 1 - ответ сервера. Код операции: это ноль для обычного запроса и 1 для инверсного. Авторитетный ответ устанавливается сервером, ответственным за зону. Фрагментация устанавливается, если информация не уместилась в 512 байт. Требование рекурсии, как правило, всегда установлено, что переносит всю ответственность за разрешение с клиента на сервер. Возможность рекурсии устанавливается сервером в ответе. Код возврата ноль в случае успеха и 3 при ошибке имени.
Остальные варианты опций описаны в RFC 1035, но для реализации простой схемы диалога сервера с клиентом они не требуются.
Далее следуют четыре 2х байтовых поля, которые содержат количество значений в полях с переменными длинами. Вместе с байтами идентификации и флагами они составляют заголовок DNS пакета:
- идентификация;
- флаги;
- количество запросов;
- количество ответов;
- количество прав доступа;
- количество дополнительной информации.
Общая длина заголовка - 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 - это идентификаторы, выбранные случайным образом
За ними следуют два байта флагов, которые сообщают о том, что это стандартный запрос, требующий рекурсию.
Следующие два байта - это количество запросов (1). При этом остальных полей переменной длины нет. Запрос начинается сразу после заголовка - 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