Настройка файлов зон для tinydns и axfrdns из djbdns

Содержание

Введение

Прежде всего стоит заметить, что в отличие от других DNS-серверов, данных разных зон в tinydns хранятся в одном файле.

Комментарии

Комментарии можно помещать в строки, начинающиеся с символа #.

Классификация клиентов

Клиентов, обращающихся с запросами к серверу, можно отнести к какому-либо классу. Для этого нужно создать в файле запись следующего вида:

 %lo:ipprefix

Где:

  • lo - обозначение класса,
  • ipprefix - IP-префикс клиентов, соответствующих этому классу.

Например, чтобы отличать локальных клиентов с IP-адресами из сети 192.168.0.0/16 от остальных клиентов, можно добавить в файл две записи:

 %in:192.168
 %ex

Тогда класс in будет соответствовать локальным клиентам, а класс ex будет соответствовать всем остальным, внешним клиентам.

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

Настройка записи SOA

Общий вид записи SOA следующий:

Zfqdn:mname:rname:ser:ref:ret:exp:min:ttl:timestamp:lo

Где:

  • Z - тип записи SOA,
  • fqdn - имя доменной зоны,
  • mname - доменное имя первичного сервера имён,
  • rname - почтовый ящик администратора доменной зоны, где первая точка соответствует символу @,
  • ser - серийный номер доменной зоны,
  • ref - время обновления в секундах (по умолчанию 16384 секунд или 4 часа 33 минуты 6 секунд),
  • ret - время повтора в секундах (по умолчанию 2048 секунд или 34 минуты 8 секунд),
  • exp - время истечения срока действия в секундах (по умолчанию 1048576 секунд или 12 дней 3 часа 16 минут 16 секунд),
  • min - минимальное время в секундах (по умолчанию 2560 секунд или 42 минуты 40 секунд),
  • ttl - время жизни записи в секундах (учтите, что некоторые кэширующие серверы воспринимают значение меньше 300 как 300, а значение меньше 2 для записей типа NS может привести к проблемам поиска по имени),
  • timestamp - отметка времени в формате TAI64,
  • lo - класс клиента, для которого действительна эта запись.

Поля ref, ret, exp, min могут быть не указаны. В таком случае будут использоваться значения по умолчанию.

Если в поле ttl указан 0, то в поле timestamp указано время окончания действия записи. Если значение в поле ttl не нулевое или отсутствует, то в поле timestamp указано время начала действия записи. Посчитать значение для поля timestamp можно с помощью следующих команд:

$ echo "obase=16;" `date +%s --date="2023-12-01 00:00:00"` "+ 2^62" | bc

При получении копии зоны от другого сервера SOA-запись будет иметь следующий вид:

Zstupin.su:ns1.stupin.su.:vladimir.stupin.su.:2022010601:10800:3600:604800:3600:10800

Можно попытаться сопоставить её с оригинальным определением:

$TTL 3h
stupin.su. IN SOA ns1.stupin.su. vladimir.stupin.su. 2022010601 3h 1h 1w 1h

Стоит заметить, что этот тип записей предназначен только для зон, скопированных с другого сервера имён. Для определения SOA-записей более естественным для tinydns способом стоит воспользоваться следующим разделом, где описана настройка NS-записей.

Настройка записей NS

Общий вид определения NS-записи вместе с SOA-записью:

.fqdn:ip:x:ttl:timestamp:lo

Определение NS-записи без SOA-записи:

&fqdn:ip:x:ttl:timestamp:lo

Где:

  • . - тип записи NS вместе с SOA-записью. Применяется для доменных зон, делегированных серверу,
  • & - тип записи NS. Применяется для делегирования доменных зон другим серверам,
  • fqdn - имя доменной зоны,
  • ip - IP-адрес сервера имён. Если указан, то будет создана A-запись, созданная из этого IP-адреса и имени сервера, указанного в поле x,
  • ttl - время жизни записи в секундах (учтите, что некоторые кэширующие серверы воспринимают значение меньше 300 как 300, а значение меньше 2 для записей типа NS может привести к проблемам поиска по имени),
  • x - имя сервера имён. Если в имени есть точка, то это полное имя сервера. Если точки нет, то имя сервера имён будет иметь вид x.ns.fqdn,
  • timestamp - отметка времени в формате TAI64,
  • lo - класс клиента, для которого действительна эта запись.

Если в поле ttl указан 0, то в поле timestamp указано время окончания действия записи. Если значение в поле ttl не нулевое или отсутствует, то в поле timestamp указано время начала действия записи. Посчитать значение для поля timestamp можно с помощью следующих команд:

$ echo "obase=16;" `date +%s --date="2023-12-01 00:00:00"` "+ 2^62" | bc

Настройка записей A

Для настройки A-записи вместе с PTR-записью используется следующий формат:

=fqdn:ip:ttl:timestamp:lo

Для настройки дополнительных A-записи или A-записей без PTR-записи используется следующий формат:

+fqdn:ip:ttl:timestamp:lo

Для временно отключенных записей используется следующий формат:

-fqdn:ip:ttl:timestamp:lo

Где:

  • = - тип записи A вместе с PTR-записью,
  • + - тип записи A,
  • - - временно отключенная A-запись,
  • fqdn - доменное имя,
  • ip - IP-адрес,
  • ttl - время жизни записи в секундах (учтите, что некоторые кэширующие серверы воспринимают значение меньше 300 как 300),
  • timestamp - отметка времени в формате TAI64,
  • lo - класс клиента, для которого действительна эта запись.

Если в поле ttl указан 0, то в поле timestamp указано время окончания действия записи. Если значение в поле ttl не нулевое или отсутствует, то в поле timestamp указано время начала действия записи. Посчитать значение для поля timestamp можно с помощью следующих команд:

$ echo "obase=16;" `date +%s --date="2023-12-01 00:00:00"` "+ 2^62" | bc

Настройка записей MX

Для настройки MX-записей используется следующий формат:

@fqdn:ip:x:dist:ttl:timestamp:lo

Где:

  • @ - тип записи MX,
  • fqdn - доменное имя почтового сервера,
  • ip - IP-адрес почтового сервера. Если указан, то будет создана A-запись, созданная из этого IP-адреса и имени сервера, указанного в поле x,
  • x - имя почтового сервера. Если в имени есть точка, то это полное имя сервера. Если точки нет, то имя сервера имён будет иметь вид x.mx.fqdn,
  • dist - дистанция до почтового сервера. Если не указана, то используется значение 0,
  • ttl - время жизни записи в секундах (учтите, что некоторые кэширующие серверы воспринимают значение меньше 300 как 300),
  • timestamp - отметка времени в формате TAI64,
  • lo - класс клиента, для которого действительна эта запись.

Если в поле ttl указан 0, то в поле timestamp указано время окончания действия записи. Если значение в поле ttl не нулевое или отсутствует, то в поле timestamp указано время начала действия записи. Посчитать значение для поля timestamp можно с помощью следующих команд:

$ echo "obase=16;" `date +%s --date="2023-12-01 00:00:00"` "+ 2^62" | bc

Настройка записей PTR

Формат файла таков, что PTR-записи можно определять вместе с A-записями с префиксом =. Но при необходимости можно определить PTR-запись отдельно, следующим образом:

^fqdn:ip:ttl:timestamp:lo

Где:

  • ^ - тип записи PTR,
  • fqdn - доменное имя, на которое будет указывать PTR-запись,
  • ip - IP-адрес PTR-записи,
  • ttl - время жизни записи в секундах (учтите, что некоторые кэширующие серверы воспринимают значение меньше 300 как 300),
  • timestamp - отметка времени в формате TAI64,
  • lo - класс клиента, для которого действительна эта запись.

Если в поле ttl указан 0, то в поле timestamp указано время окончания действия записи. Если значение в поле ttl не нулевое или отсутствует, то в поле timestamp указано время начала действия записи. Посчитать значение для поля timestamp можно с помощью следующих команд:

$ echo "obase=16;" `date +%s --date="2023-12-01 00:00:00"` "+ 2^62" | bc

Настройка записей CNAME

Вместо определения CNAME-записей лучше определить дополнительные A-записи с помощью префикса +. Но если вам всё-таки по каким-то неизвестным причинам понадобится создать CNAME-записи, то определить их можно следующим образом:

Cfqdn:p:ttl:timestamp:lo

Где:

  • ^ - тип записи CNAME,
  • fqdn - ссылающееся доменное имя,
  • p - целевое доменное имя,
  • ttl - время жизни записи в секундах (учтите, что некоторые кэширующие серверы воспринимают значение меньше 300 как 300),
  • timestamp - отметка времени в формате TAI64,
  • lo - класс клиента, для которого действительна эта запись.

Если в поле ttl указан 0, то в поле timestamp указано время окончания действия записи. Если значение в поле ttl не нулевое или отсутствует, то в поле timestamp указано время начала действия записи. Посчитать значение для поля timestamp можно с помощью следующих команд:

$ echo "obase=16;" `date +%s --date="2023-12-01 00:00:00"` "+ 2^62" | bc

Настройка записей TXT

Для добавления записей типа TXT предусмотрен следующий формат:

'fqdn:s:ttl:timestamp:lo

Где:

  • ' - тип записи TXT,
  • fqdn - доменное имя,
  • s - текст, соответствующий доменному имени. В тексте поддерживается возможность указать символ при помощи его восмеричного кода в виде \nnn, например, \072 для двоеточия,
  • ttl - время жизни записи в секундах (учтите, что некоторые кэширующие серверы воспринимают значение меньше 300 как 300),
  • timestamp - отметка времени в формате TAI64,
  • lo - класс клиента, для которого действительна эта запись.

Если в поле ttl указан 0, то в поле timestamp указано время окончания действия записи. Если значение в поле ttl не нулевое или отсутствует, то в поле timestamp указано время начала действия записи. Посчитать значение для поля timestamp можно с помощью следующих команд:

$ echo "obase=16;" `date +%s --date="2023-12-01 00:00:00"` "+ 2^62" | bc

Настройка записей SRV

По ссылке djbdns tools by Rob Mayoff можно найти Perl-скрипт для создания SRV-записей в формате djbdns и справку по использованию этого скрипта.

По ссылке 030-srv-records-and-axfrget.patch можно найти патч, добавляющий в djbdns поддержку записей типа SRV.

По ссылке Integrated the SRV+NAPTR ancient patch можно найти патч, добавляющий в djbdns поддержку записей типа SRV и NAPTR. По ссылке Added documentation of the patch можно найти документацию к этому патчу.

Формат SRV-записи, добавляемый патчем:

Sfqdn:ip:x:port:weight:priority:ttl:timestamp

Где:

  • S - тип записи SRV,
  • fqdn - доменное имя сервера,
  • ip - IP-адрес сервера. Если указан, то будет создана A-запись, созданная из этого IP-адреса и имени сервера, указанного в поле x,
  • x - имя сервера. Если в имени есть точка, то это полное имя сервера. Если точки нет, то имя сервера имён будет иметь вид x.srv.fqdn,
  • ttl - время жизни записи в секундах (учтите, что некоторые кэширующие серверы воспринимают значение меньше 300 как 300),
  • timestamp - отметка времени в формате TAI64,
  • lo - класс клиента, для которого действительна эта запись.

Если в поле ttl указан 0, то в поле timestamp указано время окончания действия записи. Если значение в поле ttl не нулевое или отсутствует, то в поле timestamp указано время начала действия записи. Посчитать значение для поля timestamp можно с помощью следующих команд:

$ echo "obase=16;" `date +%s --date="2023-12-01 00:00:00"` "+ 2^62" | bc

Настройка записей NAPTR

Формат записи, добавляемой патчем:

Nfqdn:order:pref:flags:service:regexp:replacement:ttl:timestamp

Где:

  • S - тип записи SRV,
  • fqdn - доменное имя сервера,
  • order -
  • pref -
  • flags -
  • service -
  • regexp -
  • replacement -
  • timestamp - отметка времени в формате TAI64,
  • lo - класс клиента, для которого действительна эта запись.

Если в поле ttl указан 0, то в поле timestamp указано время окончания действия записи. Если значение в поле ttl не нулевое или отсутствует, то в поле timestamp указано время начала действия записи. Посчитать значение для поля timestamp можно с помощью следующих команд:

$ echo "obase=16;" `date +%s --date="2023-12-01 00:00:00"` "+ 2^62" | bc

Получение копии зоны с помощью axfr-get

Для получения копии зоны с удалённого DNS-сервера по протоколу AXFR можно воспользоваться командой такого вида:

$ tcpclient -l localhost -RH 192.168.252.1 53 axfr-get stupin.su data1 data1.tmp

Где:

  • 192.168.252.1 - IP-адрес удалённого DNS-сервера,
  • 53 - TCP-порт удалённого DNS-сервера,
  • stupin.su - доменная зона, копию которой нужно получить,
  • data1 - имя файла, в который нужно поместить копию зоны,
  • data1.tmp - имя временного файла, который будет использоваться в процессе приёма копии зоны до тех пор, пока она не будет принята полность.

В команде также фигурируют неочевидные опции -l localhost -RH. У меня ушло некоторое время, чтобы понять, почему получение копии не работало. Подключение устанавливалось с большой задержкой, а затем закрывалось по таймауту ожидания данных. Оказалось, что tcpclient пытается узнать доменные имена участвующих в обмене сторон по их IP-адресам, чтобы присвоить эту информацию переменным окружения TCPLOCALHOST, TCPREMOTEHOST и TCPREMOTEINFO и передать их axfr-get. Этой информации не было в DNS, кэширующий сервер dnscache отвечал с большой задержкой и сообщением об ошибке, а tcpclient пытался повторить запросы. В результате установка связи затягивалась, а удалённый DNS-сервер, так и не дождавшись запроса, просто закрывал подключение.

Дополнительные материалы