WikiDer > TSIG

TSIG

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

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

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

Обновления DNS, как и запросы, обычно передаются через UDP поскольку требует меньших накладных расходов, чем TCP. Однако DNS-серверы поддерживают запросы UDP и TCP.

Выполнение

Обновление, как указано в RFC 2136, представляет собой набор инструкций для DNS-сервера. К ним относятся заголовок, зона, которая должна быть обновлена, предварительные условия, которые должны быть выполнены, и записи, которые необходимо обновить. TSIG добавляет последнюю запись, которая включает отметку времени и хэш запроса. Он также включает имя секретного ключа, который использовался для подписи запроса. RFC 2535 есть рекомендации по форме имени.

Ответ на успешное обновление TSIG также будет подписан записью TSIG. Ошибки не подписываются, чтобы злоумышленник не мог узнать что-либо о ключе TSIG с помощью специально созданных «зондов» обновления.

В nsupdate программа может использовать TSIG для обновления DNS.

Запись TSIG имеет тот же формат, что и другие записи в запросе на обновление. Значение полей описано в RFC 1035.

Поля записи TSIG
ПолеБайтовЦенитьОписание
ИМЯМаксимум. 256ВарьируетсяИмя ключа; определяет ключ как на клиенте, так и на сервере
ТИП2TSIG (250)
КЛАСС2ЛЮБОЙ (255)
TTL40Записи TSIG нельзя кэшировать
ДЛИНА2ВарьируетсяДлина поля RDATA
RDATAПеременнаяВарьируетсяСтруктура, содержащая метку времени, алгоритм и хеш-данные

Альтернативы TSIG

Хотя TSIG широко применяется, с протоколом есть несколько проблем:

  • Это требует распространения секретных ключей на каждый хост, который должен делать обновления.
  • Хотя дайджест HMAC-MD5 по-прежнему широко используется, он уже не считается очень безопасным. HMAC-SHA256 является предпочтительным.

В результате был предложен ряд альтернатив и расширений.

  • RFC 2137 указывает метод обновления с помощью открытый ключ DNS-запись "SIG". Клиент, имеющий соответствующий закрытый ключ, может подписать запрос на обновление. Этот метод соответствует DNSSEC метод безопасных запросов. Однако этот метод устарел RFC 3007.
  • В 2003 г., RFC 3645 предложила расширить TSIG, чтобы обеспечить возможность безопасного обмена ключами с помощью Generic Security Service (GSS), устраняя необходимость вручную распределять ключи всем клиентам TSIG. Метод распространения открытых ключей в виде ресурсной записи DNS (RR) указан в RFC 2930, с GSS в качестве одного из режимов этого метода. А модифицированный ГСС-ЦИГ - с помощью Windows Kerberos Сервер - реализован Майкрософт Виндоус Active Directory серверов и клиентов под названием Secure Dynamic Update. В сочетании с плохо настроенным DNS (без зоны обратного просмотра) с использованием RFC 1918 При адресации, обновления обратного DNS с использованием этой схемы проверки подлинности массово пересылаются на корневые DNS-серверы и, таким образом, увеличивают трафик на корневые DNS-серверы. Существует Anycast группа, которая занимается этим трафиком, чтобы забрать его с корневых DNS-серверов.[1][2]
  • RFC 2845 определяет TSIG, указывает только одну разрешенную функцию хеширования, 128-битную HMAC-MD5, который больше не считается безопасным. RFC 4635 был распространен, чтобы позволить RFC 3174 Алгоритм безопасного хеширования (SHA1) и FIPS PUB 180-2 SHA-2 хеширование для замены MD5. 160-битные и 256-битные дайджесты, генерируемые SHA1 и SHA-2, более безопасны, чем 128-битные дайджесты, генерируемые MD5.
  • RFC 2930 определяет TKEY, а Запись DNS используется для автоматической рассылки ключей с DNS-сервера DNS-клиентам.
  • RFC 3645 определяет GSS-TSIG, который использует gss-api и TKEY для автоматического распределения ключей в режиме gss-api.
  • В DNSCurve Предложение имеет много общего с TSIG.

Смотрите также

Рекомендации

  1. ^ «RFC 7534 - Операции с сервером имен AS112». Май 2015 г.. Получено 2017-12-29.
  2. ^ «Обзор проекта AS112», получено 29 декабря 2017.

внешняя ссылка

  • RFC 2136 Динамические обновления в системе доменных имен (ОБНОВЛЕНИЕ DNS)
  • RFC 2845 Аутентификация транзакции с секретным ключом для DNS (TSIG)
  • RFC 2930 Создание секретного ключа для DNS (TKEY RR)
  • RFC 3645 Общий алгоритм службы безопасности для аутентификации транзакции с секретным ключом для DNS (GSS-TSIG)
  • RFC 3174 Алгоритм безопасного хеширования США 1
  • RFC 4635 Идентификаторы алгоритма HMAC SHA TSIG