Key modules:

| Module | Ответственность |
|--------|----------------|
| `ioc2rpz.erl` | TCP/TLS DNS рабочий — приём, разбор, проверка, ответ |
| `ioc2rpz_udp.erl` | UDP DNS слушатель — SOA-запросы |
| `ioc2rpz_conn.erl` | Получение источников IOC (HTTP/HTTPS/файл/shell) |
| `ioc2rpz_db.erl` | Кэш зон и пакетов на основе ETS |
| `ioc2rpz_sup.erl` | Главный супервизор, загрузка конфигурации, планирование зон |
| `ioc2rpz_rest.erl` | REST API управления (Cowboy) |
| `ioc2rpz_doh.erl` | Обработчик DNS-over-HTTPS |

## Как использовать ioc2rpz™
Вы можете использовать ioc2rpz™ с любым DNS-сервером, поддерживающим зоны политики ответов, например, последние версии ISC BIND, PowerDNS и любые коммерческие DNS-серверы на их основе (например, Infoblox, Blue Cat, Efficient IP). Пример конфигурационного файла bind (named.conf) находится в папке cfg.
<p align="center"><a href="http://www.youtube.com/watch?feature=player_embedded&v=bvhyMFa_mBM" target="_blank"><img src="https://raw.githubusercontent.com/Homas/ioc2rpz/master/ioc2rpz_demo.png"></a></p>

## Веб-интерфейс ioc2rpz™
[ioc2rpz.gui](https://github.com/Homas/ioc2rpz.gui) — это веб-интерфейс управления, разрабатываемый как отдельный проект. Он не требуется для работы ioc2rpz™.

## Поддержка протоколов

ioc2rpz™ прослушивает несколько транспортных протоколов. Во всех транспортах используется один и тот же конвейер обработки запросов: ограничение скорости, проверка TSIG, поиск в зоне и генерация ответов. Полную документацию по протоколам см. в [docs/protocols.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/protocols.md).

### Сводка портов

| Порт | Протокол | Сервис | Условие |
|------|----------|--------|---------|
| 53 | UDP | DNS-запросы (только SOA) | Всегда |
| 53 | TCP | DNS-запросы, передача зон AXFR/IXFR, управление | Всегда |
| 853 | TCP+TLS | DoT — то же, что TCP, но зашифровано | Требуется `cert` конфигурация |
| 443/8443 | TCP+TLS | DoH (`/dns-query`) и REST API | Требуется `cert` конфигурация |

### UDP (Порт 53)

UDP используется для лёгких DNS-запросов, в первую очередь для поиска SOA. Ответы, превышающие 512 байт (или объявленный размер буфера EDNS0), устанавливают бит TC (усечение) согласно RFC 1035 §4.2.1, что побуждает клиентов повторять запрос через TCP. Команды управления не поддерживаются через UDP.```bash
dig @127.0.0.1 zone.ioc2rpz SOA -y hmac-sha256:keyname:base64key

### DNS поверх TLS / DoT (Порт 853)

ioc2rpz™ поддерживает распространение RPZ через DoT. TLS-слушатель автоматически запускается на порту 853, когда в конфигурации присутствует запись `cert`. DoT поддерживает те же операции, что и TCP (AXFR, IXFR, SOA, управление).

- Поддерживаемые версии TLS: 1.2 и 1.3 (`?TLSVersion = 'tlsv1.2-1.3'`)
- Повторное использование соединения поддерживается в соответствии с RFC 7858 §3.4 (несколько запросов за сеанс TLS, таймаут бездействия 30 секунд)
- TLS PIN не поддерживается
- Сообщения DNS NOTIFY отправляются незашифрованными (обычный UDP)
- Сертификаты автоматически обновляются при замене файлов на диске (задержка до ~2 минут из-за кэширования Erlang SSL)

Для настройки сертификатов см. [Настройка сертификатов](#certificate-setup).```bash
# SOA query over DoT
kdig @127.0.0.1 -p 853 zone.ioc2rpz SOA +tls -y hmac-sha256:keyname:base64key

# AXFR over DoT
dig @127.0.0.1 -p 853 zone.ioc2rpz AXFR +tls +tcp -y hmac-sha256:keyname:base64key

### Ограничение скорости

DNS-запросы ограничиваются по скорости с помощью интеллектуального (гибридного) ключа, чтобы легитимные клиенты с несколькими зонами не наказывались, а злоупотребление вариациями имени запроса блокировалось:

- **Предоставленная зона + поддерживаемый QTYPE** (`SOA`/`AXFR`/`IXFR`, класс `IN`) и **распознанные команды управления** (класс `CHAOS`/`TXT`) отслеживаются по `{client_IP, query_name, query_type}` — таким образом, вторичный сервер, опрашивающий/передающий несколько зон (например, `rpz1`, `rpz2`, `rpz3`) плюс управление с одного IP, учитывается независимо для каждой зоны+типа.
- **Всё остальное** (неизвестная/непредоставленная зона, неподдерживаемый тип запроса, неправильный класс или нераспознанное имя управления) агрегируется по `{client_IP}`, так что атакующий не может обойти лимит, варьируя имя запроса.

Когда лимит превышен, сервер возвращает DNS-ответ `REFUSED`.

| Параметр | По умолчанию | Макрос |
|-----------|---------|-------|
| Окно | 10 секунд | `?RATE_LIMIT_WINDOW` (10000 ms) |
| Макс. запросов за окно (детализированные: известная зона+тип / управление) | 1 | `?MAX_REQUESTS_PER_WINDOW` |
| Макс. запросов за окно (агрегированные: неизвестная зона / неподдерживаемый тип) | 1 | `?MAX_UNKNOWN_REQUESTS_PER_WINDOW` |

Ограничение скорости применяется ко всем транспортным протоколам DNS-запросов (UDP, TCP, TLS, DoH). Окно и порог настраиваются с помощью макросов в `include/ioc2rpz.hrl`.

### DNS NOTIFY

После обновления зоны (AXFR или IXFR) ioc2rpz™ отправляет DNS-сообщения NOTIFY ([RFC 1996](https://tools.ietf.org/html/rfc1996)) по UDP на IP-адреса, настроенные в RPZ `NotifyList`. Это побуждает вторичные DNS-серверы проверить серийный номер SOA зоны и инициировать передачу, если серийный номер изменился.```erlang
%% NotifyList in RPZ config — last field before whitelists
{rpz, {"zone.ioc2rpz", ..., ["source1"], ["10.0.0.1", "10.0.0.2"], []}}.

где /home/ioc2rpz/cfg, /home/ioc2rpz/db — это каталоги на хостовой системе.  
Вы можете передать имя пользовательского конфигурационного файла через параметр ``-e``. Например: ``-e CONF=./cfg/ioc2rpz2.conf``

## Переменные окружения

Следующие переменные окружения используются ioc2rpz™, в основном для развертываний в Docker. Они определены в `config/sys.config.src` и `config/vm.args`.

| Переменная | По умолчанию | Описание |
|----------|---------|-------------|
| `IPv4` | — | IPv4 адрес привязки |
| `IPv6` | — | IPv6 адрес привязки |
| `CONF` | — | Путь к конфигурационному файлу (например, `./cfg/ioc2rpz.conf`) |
| `DB` | `/opt/ioc2rpz/db` | Каталог базы данных для сохранения ETS |
| `CD` | `/opt/ioc2rpz` | Рабочий каталог |
| `NODE_NAME` | `ioc2rpz` | Короткое имя узла Erlang |
| `IO2Cookie` | `ioc2rpz` | Cookie распределённой Erlang-системы |

Передавайте переменные окружения в Docker с помощью `-e`:```bash
docker run -d --name ioc2rpz -e CONF=./cfg/custom.conf -e NODE_NAME=mynode ...

Обновите ваш `ioc2rpz.conf`, чтобы указать путь к смонтированному сертификату:```erlang
{cert, {"ssl/live/ns1.rpz-proxy.com/fullchain.pem", "ssl/live/ns1.rpz-proxy.com/privkey.pem", ""}}.

### Let's Encrypt (Продакшн)```bash
# Obtain certificate
sudo certbot certonly --standalone -d ns1.rpz-proxy.com

# Copy to ioc2rpz cfg directory
cp /etc/letsencrypt/live/ns1.rpz-proxy.com/fullchain.pem cfg/ioc2rpz_dot.crt
cp /etc/letsencrypt/live/ns1.rpz-proxy.com/privkey.pem cfg/ioc2rpz_dot.key

Сертификаты также явно перезагружаются во время перезагрузки конфигурации (`ioc2rpz-reload-cfg`): когда ioc2rpz обнаруживает, что файлы сертификатов изменились, он немедленно перезапускает TLS-слушатели с новым сертификатом, вместо того чтобы ждать ~2-минутного кэша Erlang SSL. Добавьте шаг `ioc2rpz-reload-cfg` в ваш хук обновления, чтобы применять новые сертификаты без простоя.

### Монтирование томов Docker

При запуске в Docker смонтируйте каталог сертификатов с хоста:```bash
docker run -d --name ioc2rpz \
  --mount type=bind,source=/etc/letsencrypt/live/ns1.rpz-proxy.com,target=/opt/ioc2rpz/ssl,readonly \
  ...

Erlang автоматически подхватывает замененные файлы сертификатов в течение ~2 минут. Сертификаты также явно перезагружаются при перезагрузке конфигурации (`ioc2rpz-reload-cfg`). Не допускайте истечения срока действия сертификатов — продлевайте их до истечения для бесперебойной работы.

> **Примечание:** Сборка из исходного кода предназначена для **разработки и тестирования**. Для продакшена рекомендуется **Docker** — см. [Docker Compose](#docker-compose) и репозиторий [ioc2rpz.dc](https://github.com/Homas/ioc2rpz.dc).

### Предварительные требования

- **Erlang/OTP 24 или новее** (проверьте с помощью `erl -version`) и подходящий [rebar3](https://www.rebar3.org).
- Набор инструментов C (для сборки зависимостей) и `git`.

### Сборка и запуск```bash
# 1. Clone the repository
git clone https://github.com/Homas/ioc2rpz.git
cd ioc2rpz

# 2. Build a release
rebar3 release

# 3. Edit the configuration (see the minimal example below)
$EDITOR cfg/ioc2rpz.conf

# 4. Start the server (foreground console, or 'start' for background)
_build/default/rel/ioc2rpz/bin/ioc2rpz console
# or: _build/default/rel/ioc2rpz/bin/ioc2rpz start

Смотрите [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/configuration.md) для авторитетного описания полей (структура кортежей source/RPZ, таймеры SOA, группы ключей, сертификаты и т.д.). Чтобы включить DoT (порт 853), DoH и HTTPS REST API, добавьте запись `{cert,{...}}` — см. [Настройка сертификатов](#certificate-setup).

### Оболочка для разработки (только для разработки/тестирования)

Следующие команды предназначены для локальной разработки и тестирования — не для использования в production:```bash
# Compile only (no release)
rebar3 compile

# Run the EUnit test suite
rebar3 eunit
# Run tests for a single module
rebar3 eunit --module=ioc2rpz_fun

# Start an interactive shell with the application and all deps loaded
rebar3 shell

## Управление ioc2rpz™
### через DNS
ioc2rpz™ поддерживает управление через DNS/TCP или DoT. Рекомендуется использовать DoT или REST API через DNS/TCP. Текущая версия ioc2rpz™ не поддерживает отдельный IP/интерфейс для управления. В любом случае настоятельно рекомендуется создать специальный ключ (или ключи) TSIG, который будет использоваться только для управления. Вы можете отключить управление через DNS.  
Поддерживаемые действия:
- Текущий статус ioc2rpz™. Запрос ``ioc2rpz-status``, класс ``CHAOS``, запись ``TXT``. например:```
dig +tcp -y dnsmkey_1:ayVnL+h2QKMszRVohrngagcEuIpN3RkecXKdwSa5WsHD5N4Y5R3NUMGM W8sIGv36gPkAtWtgarqKzN9tmHqEnA== @127.0.0.1 ioc2rpz-status TXT -c CHAOS

- Остановить ioc2rpz™. Имя RR ``ioc2rpz-terminate``, Класс RR ``CHAOS``, Тип RR ``TXT``
- Запросить образец зоны. Имя RR ``sample-zone.ioc2rpz``, Класс RR ``IN``, Тип RR ``AXFR``
### через REST
REST API (порт 8443/tcp) является предпочтительным интерфейсом управления. По соображениям безопасности весь управляющий трафик должен быть зашифрован, и REST API не запускается при отсутствии SSL-сертификата. Все конечные точки принимают как GET, так и POST методы.

Для аутентификации запросов используется базовая HTTP-аутентификация. Для аутентификации запросов используются управляющие ключи TSIG. Имя ключа TSIG используется как имя пользователя HTTP, а ключ TSIG — как пароль. Доступ к REST API ограничен ACL, заданным в записи `srv`.

Сегмент версии API поддерживает как `v1`, так и `v1.0` (например, `/api/v1/stats/serv` или `/api/v1.0/stats/serv`).

REST API поддерживает вывод в формате JSON (по умолчанию) и обычного текста на основе заголовка `Accept`:
- `application/json` — вывод JSON (по умолчанию)
- `text/plain` — вывод обычного текста```bash
# Example: plain text output
curl -u "keyname:base64key==" -k -H "Accept: text/plain" https://127.0.0.1:8443/api/v1/mgmt/update_tkeys

#### Параметры пути

| Параметр | Описание |
|-----------|-------------|
| `:rpz_name` | Имя зоны RPZ (например, `dga.ioc2rpz`) |
| `:source_name` | Имя источника IOC (например, `sample_fqdn`) |
| `:ioc` | Индикатор для поиска (FQDN или IP, например, `baddomain.com`) |

#### Конечные точки статистики

`/api/v1/stats/serv` — Статистика сервера (имя узла, общее количество правил, использование памяти)```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/stats/serv

{
  "srv": {
    "node_name": "ioc2rpz@hostname",
    "srv_total_rules": 15000,
    "hot_cache_mem": "12.5 Mb",
    "axfr_table_mem": "45.2 Mb",
    "ixfr_table_mem": "8.1 Mb"
  },
  "rpz": [...],
  "sources": [...]
}

```json
{
  "rpz": [
    {
      "name": "malware.ioc2rpz",
      "status": "ready",
      "rule_count": 5000,
      "ioc_count": 4500,
      "serial": 1709000000,
      "serial_ixfr": 1708990000,
      "update_time": 1709000000,
      "ixfr_update_time": 1708995000,
      "ixfr_nz_update_time": 1708995000
    }
  ]
}

```json
{
  "sources": [
    {"name": "sample_fqdn", "ioc_count": 150}
  ]
}

Успех: `{"status":"ok","msg":"Configuration reloaded"}`
Ошибка (HTTP 520): `{"status":"error","msg":"Configuration reload error"}`

`/api/v1/mgmt/update_tkeys` — Перезагрузить ключи TSIG из конфигурации```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/mgmt/update_tkeys

Success: `{"status":"ok","msg":"Terminating"}`

#### Точки обновления зон

`/api/v1/update/all_rpz` — Принудительное полное обновление всех зон RPZ```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/update/all_rpz

Успех: `{"status":"ok","msg":"RPZ dga.ioc2rpz will be updated"}`
Ошибка (HTTP 520): `{"status":"error","msg":"RPZ dga.ioc2rpz not found"}`

#### Конечные точки управления кэшем

`/api/v1/cache/sources/clear/all` — Удалить все источники из горячего кэша```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/clear/all

Успех: `{"status":"ok","msg":"sample_fqdn source was removed from the hot cache"}`

`/api/v1/cache/sources/load/all` — Перезагрузить все источники в горячий кэш```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/load/all

Успех:```json
{
  "status": "ok",
  "rpz": "malware.ioc2rpz",
  "iocs": ["baddomain.com", "evil.example.org"]
}

Успех:```json
{
  "ioc": "baddomain.com",
  "tkey": "dnsproxykey_1",
  "data": [
    {
      "ioc": "baddomain.com",
      "feeds": [
        {
          "feed": "malware.ioc2rpz",
          "wildcard": "true",
          "type": "fqdn",
          "rpz_serial": 1709000000,
          "ioc_expiration": 0,
          "sources": ["abuse-ch", "internal-list"]
        }
      ]
    }
  ]
}

## Мониторинг и проверки здоровья

### REST API Статистика```bash
# Server statistics
curl -u "keyname:key==" -k https://127.0.0.1:8443/api/v1/stats/serv

# RPZ zone statistics (indicator counts, serials, update times)
curl -u "keyname:key==" -k https://127.0.0.1:8443/api/v1/stats/rpz

# Source statistics
curl -u "keyname:key==" -k https://127.0.0.1:8443/api/v1/stats/source

### Проверки состояния DNS```bash
# SOA query over UDP
dig @localhost -p 53 your-zone.rpz SOA +short

# Zone transfer over TCP
dig @localhost -p 53 your-zone.rpz AXFR +tcp -y hmac-sha256:keyname:base64key

# DoT query
dig @localhost -p 853 +tls your-zone.rpz SOA

# Sample zone (built-in test zone)
dig @localhost sample-zone.ioc2rpz AXFR +tcp

Форма из 4 полей остается действительной и по умолчанию устанавливает `TrackSources` в `off`.

### **cert** запись
Запись **cert** используется для определения сертификата и закрытого ключа для DNS over TLS, REST API и DoH-коммуникаций. По вопросам генерации и управления сертификатами см. [Настройка сертификатов](#certificate-setup).

Она состоит из:
- путь к файлу, содержащему сертификат;
- путь к файлу, содержащему закрытый ключ в формате PEM;
- путь к файлу с PEM-кодированными сертификатами ЦС.

Пример записи **cert**:```
{cert,{"cfg/cert.pem", "cfg/key.pem",	"cfg/cacerts.pem"}}.

### **key** запись
TSIG-ключи используются для аутентификации и авторизации. Рекомендуется использовать разные TSIG-ключи для управления ioc2rpz™ и передачи зон.  
Запись **key** состоит из:
- Имя TSIG-ключа;
- алгоритм. Поддерживаются ``md5``, ``sha256`` и ``sha512``;
- сам ключ;
- (опционально) список групп ключей, к которым он принадлежит.

Пример записей **key**:```
{key,{"key_name_1","md5","ayVnL+h2QKMszRVohrngagcEuIpN3RkecXKdwSa5WsHD5N4Y5R3NUMGM W8sIGv36gPkAtWtgarqKzN9tmHqEnA=="}}.
{key,{"key_name_2","sha256","5Yvt70eJnf95+LJeI8H3TgKGeVparmMB7udA0pv/JRE="}}.
{key,{"key_name_3","sha512","03uuaGl9kqfenjRgIeCv6e29lVvMwviB1+cDX1I0jcVOcTU4jWFwRkfo3ULRMD+NGDfwzYvXkJ94FNEaAW4vzw==",["customers","public"]}}.

Пожалуйста, обратитесь к документации "dnssec-keygen" за подробностями. Ключи могут быть назначены группам для групповой авторизации при управлении доступом к зонам RPZ.

### **key_group** запись
Группы ключей обеспечивают групповую авторизацию для передачи и управления зонами. Вместо перечисления отдельных ключей в записях `rpz` или `srv` вы можете назначить ключи именованным группам и ссылаться на группу.

Существует два способа назначения ключей группам:
1. Встроенно через необязательное 4-е поле записи `key`: `{key, {Name, Alg, Secret, [Groups]}}`
2. Явно через запись `key_group` (показано ниже)```erlang
{key_group, {GroupName, [KeyName1, KeyName2, ...]}}.

Группы упоминаются в записях `rpz` и `srv` с помощью кортежа `{groups, ["group1", "group2"]}` в списке ключей:```erlang
{rpz, {"zone.ioc2rpz", 7202, 3600, 2592000, 7200, "true", "true", "nxdomain",
       ["dnsproxykey_1", {groups, ["customers", "public"]}],
       "fqdn", 86400, 3600, ["source1"], [], []}}.

### **source** запись

Источник — это фид индикаторов компрометации. Поддерживаются FQDN, IPv4 и IPv6-адреса. Источник представляет собой текстовый файл или фид текстовых данных. Индикаторы должны разделяться символами новой строки/возврата каретки (`/n`, `/r` или оба `/r/n`). ioc2rpz™ поддерживает неограниченное количество индикаторов.  
Запись **source** состоит из:
- имя источника;
- путь источника для полной передачи зоны (AXFR). Поддерживаются URL (http/https/ftp), локальные файлы и сценарии. Префикс **file:** используется для локальных файлов. Префикс **shell:** используется для выполнения локального скрипта/команды на хосте/контейнере, который должен вывести индикаторы и опциональную дату истечения в STDOUT;
- путь источника для инкрементальной передачи зоны (IXFR). Пути AXFR,IXFR поддерживают ключевые слова для сокращения URL и добавления временных меток обновления зоны:
  - **[:AXFR:]** — полный путь AXFR. Может использоваться только в путях IXFR;
  - **[:FTimestamp:]** — временная метка последнего обновления источника (например, 1507946281);
  - **[:ToTimestamp:]** — текущая временная метка;
- REGEX, используемый для извлечения индикаторов и времени их истечения. Первое совпадение — индикатор, второе — время истечения. Время истечения — опциональный параметр. Регулярное выражение должно быть заключено в двойные кавычки. Если указать пустой REGEX (`""`), будет использоваться стандартный REGEX (`"^([A-Za-z0-9][A-Za-z0-9\-\._]+)[^A-Za-z0-9\-\._]*.*$"`). `none` используется, если REGEX не требуется (источник уже предоставляет данные в нужном формате).
Опциональные параметры (должны использоваться все или ни один):
- UserID (используется внутренне).
- Максимальное количество IoC.
- Время горячего кэша для полного обновления источника (в секундах).
- Время горячего кэша для инкрементального обновления источника (в секундах).

Загрузка источника по HTTPS проверяет TLS-сертификат удалённого сервера. Источники с недействительными или самоподписанными сертификатами не будут загружены. Для самоподписанных сертификатов используйте источник `shell:` с `curl --insecure`.

**Ограничения локальных файлов:** пути `file:`, содержащие `..` (переход в родительский каталог), отклоняются по соображениям безопасности; используйте путь без `..` (в рабочем каталоге/каталоге данных).

**Ограничения команд shell:** исполняемый файл каждого элемента конвейера должен быть абсолютным путём (например, `/usr/bin/curl`) или утилитой безопасной обработки текста с именем без пути (`sort`, `uniq`, `grep`, `sed`, `awk`, `gawk` и т.д.); деструктивные команды и оболочки (`rm`, `bash`, `sh` и т.д.) блокируются, а подстановка команд (`$(...)`, обратные кавычки) и перенаправление вывода (`>`, `>>`) отклоняются. Отклонённые команды не выполняются и регистрируются через CEF событие 151 (выполненные команды — через 150). Полный набор правил см. в [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/configuration.md#shell-command-restrictions).

Если источник возвращает менее 50% от предыдущего количества индикаторов, обновление отклоняется, и предыдущие данные сохраняются. Это предотвращает снижение покрытия RPZ из-за деградировавших фидов. Настраивается через макрос `?SOURCE_MIN_IOC_RATIO`.

Пример записи **source**:```
%% Local file source — indicators without expiration
{source,{"sample_fqdn","file:cfg/sample_ioc_fqdn.txt","[:AXFR:]",none}}.

%% Local file source — indicators with expiration timestamps (tab-separated)
{source,{"sample_expire","file:cfg/sample_ioc_expire.txt","[:AXFR:]","^([A-Za-z0-9][A-Za-z0-9\-\._]+)\t([0-9TZ:\-]+)$"}}.

%% Shell source — fetch RPZ via AXFR and extract CNAMEs
{source,{"base.rpz1","shell:/usr/bin/dig -y KEYNAME:TSIGKEY @127.0.0.1 base.rpz.ioc2rpz.local axfr | /bin/grep -e CNAME | /bin/grep -v '*.' | /usr/bin/awk -F '.base.rpz' '{print $1}'","",none}}.

### IOC Source Attribution
Лента RPZ формируется путем объединения индикаторов из нескольких источников. Атрибуция источника позволяет API поиска IOC сообщать, **какой источник (или источники) внутри ленты** предоставил индикатор — это полезно для обработки сообщений о ложных срабатываниях. Отслеживание **по умолчанию отключено** и настраивается для каждой ленты с помощью опциональной глобальной настройки на уровне сервера.

**Конфигурация**

- Для каждой ленты: опциональный завершающий (16-й) элемент `TrackSources` кортежа `{rpz,{...}}` — `auto | true | false`.
- Глобальное значение по умолчанию для сервера: опциональный завершающий (5-й) элемент `TrackSources` кортежа `{srv,{...}}` — `off | auto | on` (по умолчанию `off`).

Оба параметра являются опциональными и обратно совместимыми: существующие конфигурационные файлы (15-полей `rpz`, 4-поля `srv`) загружаются без изменений и ведут себя как `off`.

**Приоритет разрешения** — фактическое состояние для ленты определяется следующим образом:
1. явное значение `track_sources` ленты, если задано;
2. иначе глобальное значение по умолчанию для сервера;
3. иначе встроенное значение по умолчанию `off`.

`auto` означает: отслеживать только **многоисточниковые** ленты. Одноисточниковые ленты никогда не маскируются — их единственное имя источника возвращается напрямую (без затрат на отслеживание).

**API — дополнительное поле `sources`**

Ответ `/api/v1/ioc/:ioc` получает новое поле `sources` в каждом объекте ленты. Оно является **дополнительным и обратно совместимым**: все существующие поля не изменяются, поэтому старые клиенты, игнорирующие его, продолжают работать.

- Отслеживаемая многоисточниковая лента: массив JSON с именами вносящих вклад источников.
- Одноисточниковая лента: массив из одного элемента с этим единственным именем источника.
- Отслеживание отключено или атрибуция неизвестна (например, строка в кэше до обновления до выполнения одноразовой перестройки AXFR): `null` (JSON) / `(disabled)` или `(unavailable)` (TXT).```json
{
  "feed": "mixed.ioc2rpz",
  "wildcard": "true",
  "type": "fqdn",
  "rpz_serial": 1709000000,
  "ioc_expiration": 0,
  "sources": ["abuse-ch", "internal-list"]
}