Key modules:

| Module | Responsabilidade |
|--------|---------------|
| `ioc2rpz.erl` | Worker DNS TCP/TLS — aceitar, analisar, validar, responder |
| `ioc2rpz_udp.erl` | Listener DNS UDP — consultas SOA |
| `ioc2rpz_conn.erl` | Obtenção de fontes IOC (HTTP/HTTPS/arquivo/shell) |
| `ioc2rpz_db.erl` | Cache de zonas e pacotes baseado em ETS |
| `ioc2rpz_sup.erl` | Supervisor principal, carregamento de configuração, agendamento de zonas |
| `ioc2rpz_rest.erl` | API de gerenciamento REST (Cowboy) |
| `ioc2rpz_doh.erl` | Manipulador DNS-over-HTTPS |

## Como usar o ioc2rpz™
Você pode usar o ioc2rpz™ com qualquer servidor DNS que suporte Response Policy Zones, por exemplo, versões recentes do ISC BIND, PowerDNS e qualquer servidor DNS comercial baseado nesses produtos (por exemplo, Infoblox, Blue Cat, Efficient IP). Um arquivo de configuração de exemplo do BIND (named.conf) é fornecido na pasta 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>

## Interface web do ioc2rpz™
[ioc2rpz.gui](https://github.com/Homas/ioc2rpz.gui) é uma interface web de gerenciamento desenvolvida como um projeto separado. Ela não é necessária para executar o ioc2rpz™.

## Suporte a Protocolos

O ioc2rpz™ escuta em múltiplos protocolos de transporte. Todos os transportes compartilham o mesmo pipeline de processamento de consultas: limitação de taxa (rate limiting), validação TSIG, consulta de zona e geração de resposta. Consulte [docs/protocols.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/protocols.md) para a documentação completa dos protocolos.

### Resumo de Portas

| Porta | Protocolo | Serviço | Condição |
|------|----------|---------|-----------|
| 53 | UDP | Consultas DNS (somente SOA) | Sempre |
| 53 | TCP | Consultas DNS, transferências de zona AXFR/IXFR, gerenciamento | Sempre |
| 853 | TCP+TLS | DoT — igual ao TCP, porém criptografado | Exige configuração `cert` |
| 443/8443 | TCP+TLS | DoH (`/dns-query`) e API REST | Exige configuração `cert` |

### UDP (Porta 53)

O UDP é usado para consultas DNS leves, principalmente pesquisas SOA. Respostas que excedem 512 bytes (ou o tamanho de buffer anunciado pelo EDNS0) definem o bit TC (truncamento) conforme RFC 1035 §4.2.1, levando os clientes a tentarem novamente via TCP. Comandos de gerenciamento não são suportados via UDP.```bash
dig @127.0.0.1 zone.ioc2rpz SOA -y hmac-sha256:keyname:base64key

### DNS sobre TLS / DoT (Porta 853)

ioc2rpz™ suporta distribuição de RPZ sobre DoT. O listener TLS inicia automaticamente na porta 853 quando um registo `cert` está presente na configuração. DoT suporta as mesmas operações que TCP (AXFR, IXFR, SOA, gestão).

- Versões de TLS suportadas: 1.2 e 1.3 (`?TLSVersion = 'tlsv1.2-1.3'`)
- Reutilização de ligação suportada conforme RFC 7858 §3.4 (múltiplas consultas por sessão TLS, tempo limite de inatividade de 30 segundos)
- TLS PIN não é suportado
- Mensagens DNS NOTIFY são enviadas sem encriptação (UDP simples)
- Os certificados são atualizados automaticamente quando os ficheiros são substituídos no disco (atraso de até ~2 minutos devido à cache SSL do Erlang)

Para configuração de certificados, consulte [Configuração de Certificados](#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

### Limitação de Taxa

As consultas DNS são limitadas por taxa usando uma chave inteligente (híbrida) para que clientes legítimos de várias zonas não sejam penalizados enquanto o abuso por variação de nome de consulta é bloqueado:

- **Zona provisionada + QTYPE suportado** (`SOA`/`AXFR`/`IXFR`, classe `IN`) e **comandos de gerenciamento reconhecidos** (classe `CHAOS`/`TXT`) são rastreados por `{client_IP, query_name, query_type}` — de modo que um secundário que consulta/transfere várias zonas (ex.: `rpz1`, `rpz2`, `rpz3`) além do gerenciamento a partir de um único IP é contado de forma independente por zona+tipo.
- **Todo o resto** (zona desconhecida/não provisionada, tipo de consulta não suportado, classe incorreta ou um nome de gerenciamento não reconhecido) é agregado por `{client_IP}`, de modo que um invasor não pode contornar o limite variando o nome da consulta.

Quando o limite é excedido, o servidor retorna uma resposta DNS `REFUSED`.

| Parâmetro | Padrão | Macro |
|-----------|---------|-------|
| Janela | 10 segundos | `?RATE_LIMIT_WINDOW` (10000 ms) |
| Máximo de requisições por janela (granular: zona+tipo conhecidos / gerenciamento) | 1 | `?MAX_REQUESTS_PER_WINDOW` |
| Máximo de requisições por janela (agregado: zona desconhecida / tipo não suportado) | 1 | `?MAX_UNKNOWN_REQUESTS_PER_WINDOW` |

A limitação de taxa se aplica a todos os transportes de consulta DNS (UDP, TCP, TLS, DoH). A janela e o limite são configuráveis por meio de macros em `include/ioc2rpz.hrl`.

### DNS NOTIFY

Após uma atualização de zona (AXFR ou IXFR), o ioc2rpz™ envia mensagens DNS NOTIFY ([RFC 1996](https://tools.ietf.org/html/rfc1996)) via UDP para os endereços IP configurados na `NotifyList` do RPZ. Isso leva os servidores DNS secundários a verificar o serial SOA da zona e iniciar uma transferência se o serial tiver mudado.```erlang
%% NotifyList in RPZ config — last field before whitelists
{rpz, {"zone.ioc2rpz", ..., ["source1"], ["10.0.0.1", "10.0.0.2"], []}}.

onde os diretórios /home/ioc2rpz/cfg, /home/ioc2rpz/db em um sistema host.  
Você pode passar um nome de arquivo de configuração personalizado através do parâmetro ``-e``. Ex.: ``-e CONF=./cfg/ioc2rpz2.conf``

## Variáveis de Ambiente

As seguintes variáveis de ambiente são usadas pelo ioc2rpz™, relevantes principalmente para implantações Docker. Elas são definidas em `config/sys.config.src` e `config/vm.args`.

| Variável | Padrão | Descrição |
|----------|---------|-------------|
| `IPv4` | — | Endereço de bind IPv4 |
| `IPv6` | — | Endereço de bind IPv6 |
| `CONF` | — | Caminho para o arquivo de configuração (ex.: `./cfg/ioc2rpz.conf`) |
| `DB` | `/opt/ioc2rpz/db` | Diretório do banco de dados para persistência ETS |
| `CD` | `/opt/ioc2rpz` | Diretório de trabalho |
| `NODE_NAME` | `ioc2rpz` | Nome curto do nó Erlang |
| `IO2Cookie` | `ioc2rpz` | Cookie distribuído Erlang |

Passe variáveis de ambiente para o Docker com `-e`:```bash
docker run -d --name ioc2rpz -e CONF=./cfg/custom.conf -e NODE_NAME=mynode ...

Atualize seu `ioc2rpz.conf` para referenciar o caminho do certificado montado:```erlang
{cert, {"ssl/live/ns1.rpz-proxy.com/fullchain.pem", "ssl/live/ns1.rpz-proxy.com/privkey.pem", ""}}.

### Let's Encrypt (Produção)```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

Os certificados também são recarregados explicitamente durante uma recarga de configuração (`ioc2rpz-reload-cfg`): quando o ioc2rpz detecta que os arquivos de certificado mudaram, ele reinicia os listeners TLS com o novo certificado imediatamente, em vez de aguardar o cache SSL Erlang de ~2 minutos. Adicione uma etapa `ioc2rpz-reload-cfg` ao seu hook de renovação para aplicar novos certificados sem indisponibilidade.

### Montagem de Volumes Docker

Ao executar em Docker, monte o diretório de certificados a partir do host:```bash
docker run -d --name ioc2rpz \
  --mount type=bind,source=/etc/letsencrypt/live/ns1.rpz-proxy.com,target=/opt/ioc2rpz/ssl,readonly \
  ...

O Erlang detecta automaticamente os arquivos de certificado substituídos em cerca de ~2 minutos. Os certificados também são explicitamente recarregados durante o recarregamento da configuração (`ioc2rpz-reload-cfg`). Não deixe os certificados expirarem — renove antes da expiração para um serviço ininterrupto.

## Compilando a partir do Código-Fonte

> **Nota:** A compilação a partir do código-fonte é destinada a **desenvolvimento e testes**. Para produção, **Docker é o método de implantação recomendado** — consulte [Docker Compose](#docker-compose) e o repositório [ioc2rpz.dc](https://github.com/Homas/ioc2rpz.dc).

### Pré-requisitos

- **Erlang/OTP 24 ou mais recente** (`erl -version` para verificar) e um [rebar3](https://www.rebar3.org) correspondente.
- Uma toolchain C (para compilar dependências) e `git`.

### Compilar e Executar```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

Consulte [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/configuration.md) para a referência autoritativa campo a campo (layout da tupla source/RPZ, temporizadores SOA, grupos de chaves, certificados, etc.). Para habilitar DoT (porta 853), DoH e a API REST HTTPS, adicione uma entrada `{cert,{...}}` — consulte [Configuração de Certificados](#certificate-setup).

### Shell de Desenvolvimento (somente desenvolvimento/testes)

Os seguintes comandos são para desenvolvimento e testes locais — não para uso em produção:```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

## Gerenciamento do ioc2rpz™
### via DNS
O ioc2rpz™ suporta gerenciamento via DNS/TCP ou DoT. Recomenda-se usar DoT ou API REST em vez de DNS/TCP. A versão atual do ioc2rpz™ não suporta um IP/interface de gerenciamento separado. Em qualquer caso, é altamente recomendável criar uma chave TSIG designada (ou chaves) que será usada apenas para gerenciamento. Você pode desativar o gerenciamento via DNS.  
Ações suportadas:
- Status atual do ioc2rpz™. Solicite ``ioc2rpz-status``, classe ``CHAOS``, registro ``TXT``. ex.:```
dig +tcp -y dnsmkey_1:ayVnL+h2QKMszRVohrngagcEuIpN3RkecXKdwSa5WsHD5N4Y5R3NUMGM W8sIGv36gPkAtWtgarqKzN9tmHqEnA== @127.0.0.1 ioc2rpz-status TXT -c CHAOS

- Parar ioc2rpz™. RR Name ``ioc2rpz-terminate``, RR Class ``CHAOS``, RR Type ``TXT``
- Solicitar uma zona de exemplo. RR Name ``sample-zone.ioc2rpz``, RR Class ``IN``, RR Type ``AXFR``
### via REST
A API REST (porta 8443/tcp) é a interface de gerenciamento preferida. Por razões de segurança, todo o tráfego de gerenciamento deve ser criptografado e a API REST não é iniciada se não houver certificado SSL. Todos os endpoints aceitam tanto métodos GET quanto POST.

A autenticação HTTP Basic é usada para autenticar requisições. Chaves TSIG de gerenciamento são usadas para autenticação de requisições. Um nome de chave TSIG é usado como nome de usuário HTTP e a chave TSIG como senha. O acesso à API REST é restrito pela ACL definida no registro `srv`.

O segmento de versão da API suporta tanto `v1` quanto `v1.0` (por exemplo, `/api/v1/stats/serv` ou `/api/v1.0/stats/serv`).

A API REST suporta saída JSON (padrão) e texto simples com base no cabeçalho `Accept`:
- `application/json` — saída JSON (padrão)
- `text/plain` — saída em texto simples```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

#### Parâmetros de Caminho

| Parâmetro | Descrição |
|-----------|-------------|
| `:rpz_name` | Nome da zona RPZ (ex.: `dga.ioc2rpz`) |
| `:source_name` | Nome da fonte de IOC (ex.: `sample_fqdn`) |
| `:ioc` | Indicador a consultar (FQDN ou IP, ex.: `baddomain.com`) |

#### Endpoints de Estatísticas

`/api/v1/stats/serv` — Estatísticas do servidor (nome do nó, total de regras, uso de memória)```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}
  ]
}

Sucesso: `{"status":"ok","msg":"Configuration reloaded"}`
Erro (HTTP 520): `{"status":"error","msg":"Configuration reload error"}`

`/api/v1/mgmt/update_tkeys` — Recarregar chaves TSIG da configuração```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/mgmt/update_tkeys

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

#### Endpoints de Atualização de Zonas

`/api/v1/update/all_rpz` — Força a atualização completa de todas as zonas RPZ```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/update/all_rpz

Sucesso: `{"status":"ok","msg":"RPZ dga.ioc2rpz will be updated"}`
Erro (HTTP 520): `{"status":"error","msg":"RPZ dga.ioc2rpz not found"}`

#### Endpoints de Gerenciamento de Cache

`/api/v1/cache/sources/clear/all` — Remove todas as fontes do cache ativo```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/clear/all

Success: `{"status":"ok","msg":"sample_fqdn source was removed from the hot cache"}`

`/api/v1/cache/sources/load/all` — Recarregar todas as fontes no cache quente```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/load/all

Sucesso:```json
{
  "status": "ok",
  "rpz": "malware.ioc2rpz",
  "iocs": ["baddomain.com", "evil.example.org"]
}

Sucesso:```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"]
        }
      ]
    }
  ]
}

## Monitoramento e Verificações de Saúde

### Estatísticas da API REST```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

### Verificações de Integridade do 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

O formulário de 4 campos continua válido e define `TrackSources` como `off` por padrão.
### Registro **cert**
O registro **cert** é usado para definir um certificado e uma chave privada para comunicações DNS over TLS, REST API e DoH. Para geração e gerenciamento de certificados, consulte [Configuração de Certificado](#certificate-setup).

É composto por:
- caminho para um arquivo contendo um certificado;
- caminho para um arquivo contendo uma chave privada codificada em PEM;
- caminho para um arquivo com certificados de CA codificados em PEM.  

Exemplo de registro **cert**:```
{cert,{"cfg/cert.pem", "cfg/key.pem",	"cfg/cacerts.pem"}}.

### Registro **key**
As chaves TSIG são usadas para autenticação e autorização. É recomendado usar chaves TSIG diferentes para o gerenciamento do ioc2rpz™ e transferências de zonas.  
O registro **key** consiste em:
- Nome da chave TSIG;
- algoritmo. ``md5``, ``sha256`` e ``sha512`` são suportados;
- a chave;
- (opcional) lista de grupos de chaves aos quais ela pertence.

Exemplo de registros **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"]}}.

Consulte a documentação "dnssec-keygen" para obter detalhes. As chaves podem ser atribuídas a grupos para autorização baseada em grupos no controle de acesso de zonas RPZ.

### **key_group** registro
Os grupos de chaves fornecem autorização baseada em grupos para transferências e gerenciamento de zonas. Em vez de listar chaves individuais em registros `rpz` ou `srv`, você pode atribuir chaves a grupos nomeados e referenciar o grupo.

Há duas maneiras de atribuir chaves a grupos:
1. Inline, através do campo opcional de 4ª posição do registro `key`: `{key, {Name, Alg, Secret, [Groups]}}`
2. Explicitamente, através de um registro `key_group` (mostrado abaixo)```erlang
{key_group, {GroupName, [KeyName1, KeyName2, ...]}}.

Grupos são referenciados nos registros `rpz` e `srv` usando a tupla `{groups, ["group1", "group2"]}` na lista de chaves:```erlang
{rpz, {"zone.ioc2rpz", 7202, 3600, 2592000, 7200, "true", "true", "nxdomain",
       ["dnsproxykey_1", {groups, ["customers", "public"]}],
       "fqdn", 86400, 3600, ["source1"], [], []}}.

### **source** registro
Um source é um feed de indicadores maliciosos. FQDNs, endereços IPv4 e IPv6 são suportados. Um source é um arquivo de texto ou um feed de dados de texto. Os indicadores devem ser separados por caracteres de nova linha/retorno de carro (/n,/r ou ambos /r/n). O ioc2rpz™ suporta uma contagem ilimitada de indicadores.  
**source** registro consiste em:
- nome do source;
- caminho do source para transferência completa do source (AXFR). URLs(http/https/ftp), arquivos locais e scripts são suportados. O prefixo **file:** é usado para arquivos locais. O prefixo **shell:** é usado para executar um script/comando local em um host/contêiner que deve retornar indicadores e data de expiração opcional para STDOUT;
- caminho do source para transferência incremental do source (IXFR). Caminhos AXFR,IXFR suportam palavras-chave para encurtar URLs e fornecer timestamps de atualização de zona:
  - **[:AXFR:]** - caminho AXFR completo. Só pode ser usado em caminhos IXFR;
  - **[:FTimestamp:]** - timestamp de quando o source foi atualizado pela última vez  (ex.: 1507946281)
  - **[:ToTimestamp:]** - timestamp atual;
- REGEX usada para extrair indicadores e seu tempo de expiração. A primeira correspondência é um indicador, a segunda correspondência é um tempo de expiração. O tempo de expiração é um parâmetro opcional. Uma expressão regular deve ser incluída entre aspas duplas. Se você especificar uma REGEX vazia (`""`), uma REGEX padrão será usada (`"^([A-Za-z0-9][A-Za-z0-9\-\._]+)[^A-Za-z0-9\-\._]*.*$"`). `none` é usado se nenhuma REGEX for necessária (o source já fornece dados no formato exigido).
Parâmetros opcionais (todos ou nenhum devem ser usados):
- UserID (usado internamente).
- Número máximo de IoCs.
- Atualização completa do source, tempo de hot cache (em segundos).
- Atualização incremental do source, tempo de hot cache (em segundos).

Downloads de sources via HTTPS verificam o certificado TLS do servidor remoto. Sources com certificados inválidos ou autoassinados falharão no download. Para certificados autoassinados, use um source `shell:` com `curl --insecure`.

**Restrições de arquivo local:** caminhos `file:` que contenham `..` (travessia de diretório pai) são rejeitados por segurança; use um caminho sem `..` (dentro do diretório de trabalho/dados).

**Restrições de comando shell:** o executável de cada segmento do pipeline deve ser um caminho absoluto (ex.: `/usr/bin/curl`) ou um utilitário de texto seguro de nome simples (`sort`, `uniq`, `grep`, `sed`, `awk`, `gawk`, etc.); comandos destrutivos e shells (`rm`, `bash`, `sh`, etc.) são bloqueados, e substituição de comando (`$(...)`, crases) e redirecionamento de saída (`>`, `>>`) são rejeitados. Comandos rejeitados não são executados e são registrados via evento CEF 151 (comandos executados via 150). Consulte [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/configuration.md#shell-command-restrictions) para o conjunto completo de regras.

Se um source retornar menos de 50% da contagem anterior de indicadores, a atualização é rejeitada e os dados anteriores são mantidos. Isso evita que feeds degradados reduzam a cobertura do RPZ. Configurável via macro `?SOURCE_MIN_IOC_RATIO`.

Exemplo de registro **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}}.

### Atribuição de Fonte de IOC
Um feed RPZ é construído mesclando indicadores de múltiplas fontes. A atribuição de fonte permite que a API de consulta de IOC informe **quais fonte(s) dentro de um feed** contribuíram com um indicador — útil para triar um falso positivo relatado. O rastreamento está **desativado por padrão** e é controlado por feed, com um padrão global opcional no nível do servidor.

**Configuração**

- Por feed: o elemento `TrackSources` opcional final (16º) da tupla `{rpz,{...}}` — `auto | true | false`.
- Padrão global do servidor: o elemento `TrackSources` opcional final (5º) da tupla `{srv,{...}}` — `off | auto | on` (padrão `off`).

Ambos são opcionais e compatíveis com versões anteriores: arquivos de configuração existentes (`rpz` de 15 campos, `srv` de 4 campos) são carregados inalterados e se comportam como off.

**Precedência de resolução** — o estado efetivo de um feed é resolvido como:
1. o valor `track_sources` explícito do feed, se definido;
2. caso contrário, o padrão global do servidor;
3. caso contrário, o padrão interno `off`.

`auto` significa: rastrear apenas feeds **de múltiplas fontes**. Feeds de fonte única nunca são mascarados — o nome da sua única fonte é retornado diretamente (sem custo de rastreamento).

**API — o campo aditivo `sources`**

A resposta `/api/v1/ioc/:ioc` ganha um novo campo `sources` em cada objeto de feed. Ele é **aditivo e compatível com versões anteriores**: todos os campos existentes permanecem inalterados, então clientes antigos que o ignoram continuam funcionando.

- Feed rastreado com múltiplas fontes: um array JSON dos nomes das fontes contribuintes.
- Feed de fonte única: um array de um único elemento com o nome dessa fonte.
- Rastreamento desativado ou atribuição desconhecida (ex.: uma linha em cache anterior à atualização, antes da reconstrução única via AXFR): `null` (JSON) / `(disabled)` ou `(unavailable)` (TXT).```json
{
  "feed": "mixed.ioc2rpz",
  "wildcard": "true",
  "type": "fqdn",
  "rpz_serial": 1709000000,
  "ioc_expiration": 0,
  "sources": ["abuse-ch", "internal-list"]
}