Key modules:

| Module | Responsibility |
|--------|---------------|
| `ioc2rpz.erl` | Trabajador DNS TCP/TLS — aceptar, analizar, validar, responder |
| `ioc2rpz_udp.erl` | Oyente DNS UDP — consultas SOA |
| `ioc2rpz_conn.erl` | Obtención de fuentes IOC (HTTP/HTTPS/archivo/shell) |
| `ioc2rpz_db.erl` | Caché de zonas y paquetes basada en ETS |
| `ioc2rpz_sup.erl` | Supervisor principal, carga de configuración, programación de zonas |
| `ioc2rpz_rest.erl` | API de gestión REST (Cowboy) |
| `ioc2rpz_doh.erl` | Manejador DNS-over-HTTPS |

## Cómo usar ioc2rpz™
Puede usar ioc2rpz™ con cualquier servidor DNS que admita Zonas de Política de Respuesta (Response Policy Zones), p. ej. versiones recientes de ISC BIND, PowerDNS y cualquier servidor DNS comercial basado en estos productos (p. ej. Infoblox, Blue Cat, Efficient IP). Se proporciona un archivo de configuración de bind de ejemplo (named.conf) en la carpeta 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>

## Interfaz web de ioc2rpz™
[ioc2rpz.gui](https://github.com/Homas/ioc2rpz.gui) es una interfaz web de gestión desarrollada como un proyecto independiente. No es necesaria para ejecutar ioc2rpz™.

## Soporte de protocolos

ioc2rpz™ escucha en múltiples protocolos de transporte. Todos los transportes comparten la misma canalización de procesamiento de consultas: limitación de tasa, validación TSIG, búsqueda en zonas y generación de respuestas. Consulte [docs/protocols.md](https://github.com/homas/ioc2rpz/blob/master/docs/protocols.md) para obtener la documentación completa de protocolos.

### Resumen de puertos

| Port | Protocol | Service | Condition |
|------|----------|---------|-----------|
| 53 | UDP | Consultas DNS (solo SOA) | Siempre |
| 53 | TCP | Consultas DNS, transferencias de zona AXFR/IXFR, gestión | Siempre |
| 853 | TCP+TLS | DoT — igual que TCP pero cifrado | Requiere configuración `cert` |
| 443/8443 | TCP+TLS | DoH (`/dns-query`) y API REST | Requiere configuración `cert` |

### UDP (Puerto 53)

UDP se utiliza para consultas DNS ligeras, principalmente búsquedas SOA. Las respuestas que superan los 512 bytes (o el tamaño de búfer anunciado por EDNS0) establecen el bit TC (truncamiento) según RFC 1035 §4.2.1, lo que hace que los clientes reintenten por TCP. Los comandos de gestión no son compatibles a través de UDP.```bash
dig @127.0.0.1 zone.ioc2rpz SOA -y hmac-sha256:keyname:base64key

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

ioc2rpz™ soporta la distribución de RPZ sobre DoT. El listener TLS se inicia automáticamente en el puerto 853 cuando hay un registro `cert` presente en la configuración. DoT soporta las mismas operaciones que TCP (AXFR, IXFR, SOA, gestión).

- Versiones TLS soportadas: 1.2 y 1.3 (`?TLSVersion = 'tlsv1.2-1.3'`)
- Reutilización de conexiones soportada según RFC 7858 §3.4 (múltiples consultas por sesión TLS, tiempo de inactividad de 30 segundos)
- TLS PIN no está soportado
- Los mensajes DNS NOTIFY se envían sin cifrar (UDP simple)
- Los certificados se actualizan automáticamente cuando los archivos se reemplazan en disco (hasta ~2 minutos de retraso debido al caché SSL de Erlang)

Para la configuración de certificados, consulte [Configuración 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

### Limitación de tasa

Las consultas DNS se limitan en tasa utilizando una clave (híbrida) inteligente para que los clientes legítimos de múltiples zonas no sean penalizados mientras se bloquea el abuso por variación del nombre de consulta:

- **Zona aprovisionada + QTYPE compatible** (`SOA`/`AXFR`/`IXFR`, clase `IN`) y **comandos de gestión reconocidos** (clase `CHAOS`/`TXT`) se rastrean por `{client_IP, query_name, query_type}` — por lo que un secundario que consulta/transfiere varias zonas (p. ej. `rpz1`, `rpz2`, `rpz3`) además de la gestión desde una IP se cuenta de forma independiente por zona+tipo.
- **Cualquier otra cosa** (zona desconocida/no aprovisionada, tipo de consulta no compatible, clase incorrecta o nombre de gestión no reconocido) se agrega por `{client_IP}`, de modo que un atacante no puede evitar el límite variando el nombre de consulta.

Cuando se supera el límite, el servidor devuelve una respuesta DNS `REFUSED`.

| Parámetro | Valor predeterminado | Macro |
|-----------|---------|-------|
| Ventana | 10 segundos | `?RATE_LIMIT_WINDOW` (10000 ms) |
| Máx. solicitudes por ventana (granular: zona+tipo conocida / gestión) | 1 | `?MAX_REQUESTS_PER_WINDOW` |
| Máx. solicitudes por ventana (agregado: zona desconocida / tipo no compatible) | 1 | `?MAX_UNKNOWN_REQUESTS_PER_WINDOW` |

La limitación de tasa se aplica a todos los transportes de consultas DNS (UDP, TCP, TLS, DoH). La ventana y el umbral son configurables mediante macros en `include/ioc2rpz.hrl`.

### NOTIFY de DNS

Después de una actualización de zona (AXFR o IXFR), ioc2rpz™ envía mensajes de NOTIFY de DNS ([RFC 1996](https://tools.ietf.org/html/rfc1996)) por UDP a las direcciones IP configuradas en la `NotifyList` de la RPZ. Esto solicita a los servidores DNS secundarios que comprueben el serial SOA de la zona e inicien una transferencia si el serial ha cambiado.```erlang
%% NotifyList in RPZ config — last field before whitelists
{rpz, {"zone.ioc2rpz", ..., ["source1"], ["10.0.0.1", "10.0.0.2"], []}}.

where /home/ioc2rpz/cfg, /home/ioc2rpz/db directorios en un sistema host.  
Puede pasar un nombre de archivo de configuración personalizado mediante el parámetro ``-e``. Por ejemplo: ``-e CONF=./cfg/ioc2rpz2.conf``

## Variables de entorno

Las siguientes variables de entorno son utilizadas por ioc2rpz™, principalmente relevantes para despliegues de Docker. Se definen en `config/sys.config.src` y `config/vm.args`.

| Variable | Default | Descripción |
|----------|---------|-------------|
| `IPv4` | — | Dirección de enlace IPv4 |
| `IPv6` | — | Dirección de enlace IPv6 |
| `CONF` | — | Ruta al archivo de configuración (p. ej. `./cfg/ioc2rpz.conf`) |
| `DB` | `/opt/ioc2rpz/db` | Directorio de base de datos para la persistencia ETS |
| `CD` | `/opt/ioc2rpz` | Directorio de trabajo |
| `NODE_NAME` | `ioc2rpz` | Nombre corto del nodo Erlang |
| `IO2Cookie` | `ioc2rpz` | Cookie distribuida de Erlang |

Pase las variables de entorno a Docker con `-e`:```bash
docker run -d --name ioc2rpz -e CONF=./cfg/custom.conf -e NODE_NAME=mynode ...

Actualiza tu `ioc2rpz.conf` para que haga referencia a la ruta del certificado montado:```erlang
{cert, {"ssl/live/ns1.rpz-proxy.com/fullchain.pem", "ssl/live/ns1.rpz-proxy.com/privkey.pem", ""}}.

### Let's Encrypt (Producción)```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

Los certificados también se recargan explícitamente durante una recarga de configuración (`ioc2rpz-reload-cfg`): cuando ioc2rpz detecta que los archivos de certificado cambiaron, reinicia los listeners TLS con el nuevo certificado inmediatamente, en lugar de esperar a la caché SSL de Erlang de ~2 minutos. Añade un paso `ioc2rpz-reload-cfg` a tu hook de renovación para aplicar los nuevos certificados sin tiempo de inactividad.

### Montaje de volúmenes en Docker

Cuando se ejecuta en Docker, monta el directorio de certificados desde el host:```bash
docker run -d --name ioc2rpz \
  --mount type=bind,source=/etc/letsencrypt/live/ns1.rpz-proxy.com,target=/opt/ioc2rpz/ssl,readonly \
  ...

Erlang detecta automáticamente los archivos de certificado reemplazados en aproximadamente 2 minutos. Los certificados también se recargan explícitamente durante la recarga de configuración (`ioc2rpz-reload-cfg`). No deje que los certificados caduquen — renueve antes de la expiración para un servicio ininterrumpido.

## Compilación desde el código fuente

> **Nota:** Compilar desde el código fuente está pensado para **desarrollo y pruebas**. Para producción, **Docker es el método de despliegue recomendado** — consulte [Docker Compose](#docker-compose) y el repositorio [ioc2rpz.dc](https://github.com/Homas/ioc2rpz.dc).

### Requisitos previos

- **Erlang/OTP 24 o superior** (`erl -version` para comprobarlo) y un [rebar3](https://www.rebar3.org) compatible.
- Una cadena de herramientas de C (para compilar dependencias) y `git`.

### Compilar y ejecutar```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

Consulta [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/master/docs/configuration.md) para la referencia autoritativa campo por campo (disposición de tuplas source/RPZ, temporizadores SOA, grupos de claves, certificados, etc.). Para habilitar DoT (puerto 853), DoH y la API REST HTTPS, añade una entrada `{cert,{...}}` — consulta [Configuración de certificados](#certificate-setup).

### Shell de desarrollo (solo desarrollo/pruebas)

Los siguientes comandos son para desarrollo y pruebas locales — no para uso en producción:```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

## Gestión de ioc2rpz™
### vía DNS
ioc2rpz™ admite gestión mediante DNS/TCP o DoT. Se recomienda utilizar DoT o la API REST sobre DNS/TCP. La versión actual de ioc2rpz™ no admite una IP/interfaz de gestión separada. En cualquier caso, se recomienda encarecidamente crear una clave TSIG designada (o claves) para uso exclusivo de gestión. Puedes desactivar la gestión a través de DNS.  
Acciones admitidas:
- Estado actual de ioc2rpz™. Solicita ``ioc2rpz-status``, clase ``CHAOS``, registro ``TXT``. p. ej.:```
dig +tcp -y dnsmkey_1:ayVnL+h2QKMszRVohrngagcEuIpN3RkecXKdwSa5WsHD5N4Y5R3NUMGM W8sIGv36gPkAtWtgarqKzN9tmHqEnA== @127.0.0.1 ioc2rpz-status TXT -c CHAOS

- Detener ioc2rpz™. RR Name ``ioc2rpz-terminate``, RR Class ``CHAOS``, RR Type ``TXT``
- Solicitar una zona de muestra. RR Name ``sample-zone.ioc2rpz``, RR Class ``IN``, RR Type ``AXFR``
### mediante REST
La API REST (puerto 8443/tcp) es la interfaz de gestión preferida. Por razones de seguridad, todo el tráfico de gestión debe estar cifrado y la API REST no se inicia si no hay un certificado SSL. Todos los endpoints aceptan tanto métodos GET como POST.

Se utiliza autenticación HTTP básica para autenticar las solicitudes. Las claves TSIG de gestión se utilizan para la autenticación de solicitudes. El nombre de una clave TSIG se utiliza como nombre de usuario HTTP y la clave TSIG como contraseña. El acceso a la API REST está restringido con la ACL definida en el registro `srv`.

El segmento de versión de la API admite tanto `v1` como `v1.0` (p. ej., `/api/v1/stats/serv` o `/api/v1.0/stats/serv`).

La API REST admite salida JSON (predeterminada) y texto plano según el encabezado `Accept`:
- `application/json` — salida JSON (predeterminada)
- `text/plain` — salida en texto plano```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 ruta

| Parámetro | Descripción |
|-----------|-------------|
| `:rpz_name` | Nombre de la zona RPZ (p. ej. `dga.ioc2rpz`) |
| `:source_name` | Nombre de la fuente de IOC (p. ej. `sample_fqdn`) |
| `:ioc` | Indicador a buscar (FQDN o IP, p. ej. `baddomain.com`) |

#### Endpoints de estadísticas

`/api/v1/stats/serv` — Estadísticas del servidor (nombre del nodo, reglas totales, uso de memoria)```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}
  ]
}

Éxito: `{"status":"ok","msg":"Configuration reloaded"}`
Error (HTTP 520): `{"status":"error","msg":"Configuration reload error"}`

`/api/v1/mgmt/update_tkeys` — Recargar las claves TSIG desde la configuración```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/mgmt/update_tkeys

Éxito: `{"status":"ok","msg":"Terminating"}`

#### Endpoints de actualización de zonas

`/api/v1/update/all_rpz` — Fuerza una actualización completa de todas las zonas RPZ```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/update/all_rpz

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

#### Endpoints de gestión de caché

`/api/v1/cache/sources/clear/all` — Elimina todas las fuentes de la caché activa```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/clear/all

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

`/api/v1/cache/sources/load/all` — Recargar todas las fuentes en la caché en caliente```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/load/all

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

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

## Monitoreo y Comprobaciones de Salud

### Estadísticas de 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

### Comprobaciones de salud de 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

La forma de 4 campos sigue siendo válida y, por defecto, establece `TrackSources` en `off`.
### Registro **cert**
El registro **cert** se utiliza para definir un certificado y una clave privada para las comunicaciones DNS sobre TLS, API REST y DoH. Para la generación y gestión de certificados, consulte [Configuración de certificados](#certificate-setup).

Consta de:
- la ruta a un archivo que contiene un certificado;
- la ruta a un archivo que contiene una clave privada codificada en PEM;
- la ruta a un archivo con certificados de CA codificados en PEM.  

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

### Registro **key**
Las claves TSIG se utilizan para la autenticación y autorización. Se recomienda utilizar diferentes claves TSIG para la gestión de ioc2rpz™ y las transferencias de zonas.  
El registro **key** consta de:
- nombre de la clave TSIG;
- algoritmo. Se admiten ``md5``, ``sha256`` y ``sha512``;
- la clave;
- (opcional) lista de grupos de claves a los que pertenece.

Ejemplo 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 la documentación de "dnssec-keygen" para obtener más detalles. Las claves pueden asignarse a grupos para la autorización basada en grupos en el control de acceso a zonas RPZ.

### **key_group** registro
Los grupos de claves proporcionan autorización basada en grupos para las transferencias y la administración de zonas. En lugar de enumerar claves individuales en los registros `rpz` o `srv`, puede asignar claves a grupos con nombre y hacer referencia al grupo.

Hay dos formas de asignar claves a grupos:
1. En línea, mediante el campo opcional 4.º del registro `key`: `{key, {Name, Alg, Secret, [Groups]}}`
2. Explícitamente, mediante un registro `key_group` (se muestra a continuación)```erlang
{key_group, {GroupName, [KeyName1, KeyName2, ...]}}.

Los grupos se referencian en los registros `rpz` y `srv` mediante la tupla `{groups, ["group1", "group2"]}` en la lista de claves:```erlang
{rpz, {"zone.ioc2rpz", 7202, 3600, 2592000, 7200, "true", "true", "nxdomain",
       ["dnsproxykey_1", {groups, ["customers", "public"]}],
       "fqdn", 86400, 3600, ["source1"], [], []}}.

### **source** record
Una fuente es un feed de indicadores maliciosos. Se admiten FQDNs, direcciones IPv4 e IPv6. Una fuente es un archivo de texto o un feed de datos de texto. Los indicadores deben separarse mediante caracteres de nueva línea/retorno de carro (/n,/r o ambos /r/n). ioc2rpz™ admite un número ilimitado de indicadores.  
El registro **source** consta de:
- nombre de la fuente;
- ruta de la fuente para la transferencia completa de la fuente (AXFR). Se admiten URLs(http/https/ftp), archivos locales y scripts. El prefijo **file:** se utiliza para archivos locales. El prefijo **shell:** se utiliza para ejecutar un script/comando local en un host/contenedor que debe devolver indicadores y una fecha de expiración opcional a STDOUT;
- ruta de la fuente para la transferencia incremental de la fuente (IXFR). Las rutas AXFR,IXFR admiten palabras clave para acortar URLs y proporcionar marcas de tiempo de actualización de zona:
  - **[:AXFR:]** - ruta AXFR completa. Solo se puede usar en rutas IXFR;
  - **[:FTimestamp:]** - marca de tiempo de la última actualización de la fuente (p. ej. 1507946281)
  - **[:ToTimestamp:]** - marca de tiempo actual;
- REGEX que se utiliza para extraer indicadores y su tiempo de expiración. La primera coincidencia es un indicador, la segunda es un tiempo de expiración. El tiempo de expiración es un parámetro opcional. Una expresión regular debe incluirse entre comillas dobles. Si se especifica una REGEX vacía (`""`), se utilizará una REGEX predeterminada (`"^([A-Za-z0-9][A-Za-z0-9\-\._]+)[^A-Za-z0-9\-\._]*.*$"`). Se utiliza `none` si no se requiere REGEX (la fuente ya proporciona datos en el formato requerido).
Parámetros opcionales (deben usarse todos o ninguno):
- UserID (utilizado internamente).
- Número máximo de IoCs.
- Actualización completa de la fuente, tiempo de caché caliente (en segundos).
- Actualización incremental de la fuente, tiempo de caché caliente (en segundos).

Las descargas de fuentes HTTPS verifican el certificado TLS del servidor remoto. Las fuentes con certificados no válidos o autofirmados fallarán al descargarse. Para certificados autofirmados, use una fuente `shell:` con `curl --insecure`.

**Restricciones de archivos locales:** las rutas `file:` que contengan `..` (recorrido del directorio padre) se rechazan por seguridad; use una ruta sin `..` (dentro del directorio de trabajo/datos).

**Restricciones de comandos shell:** el ejecutable de cada segmento de la tubería debe ser una ruta absoluta (p. ej. `/usr/bin/curl`) o una utilidad de texto segura de nombre simple (`sort`, `uniq`, `grep`, `sed`, `awk`, `gawk`, etc.); los comandos destructivos y shells (`rm`, `bash`, `sh`, etc.) están bloqueados, y la sustitución de comandos (`$(...)`, comillas invertidas) y la redirección de salida (`>`, `>>`) se rechazan. Los comandos rechazados no se ejecutan y se registran mediante el evento CEF 151 (los comandos ejecutados se registran mediante 150). Consulte [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/master/docs/configuration.md#shell-command-restrictions) para conocer el conjunto de reglas completo.

Si una fuente devuelve menos del 50% de su recuento anterior de indicadores, la actualización se rechaza y se conservan los datos anteriores. Esto evita que los feeds degradados reduzcan la cobertura de RPZ. Configurable mediante la macro `?SOURCE_MIN_IOC_RATIO`.

Ejemplo 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}}.

### Atribución de fuentes IOC
Un feed RPZ se construye fusionando indicadores de múltiples fuentes. La atribución de fuentes permite que la API de búsqueda de IOC informe **qué fuente(s) dentro de un feed** contribuyeron con un indicador — útil para el triage de un falso positivo reportado. El seguimiento está **desactivado por defecto** y se controla por feed con un valor global predeterminado opcional a nivel de servidor.

**Configuración**

- Por feed: el elemento `TrackSources` opcional final (16.º) de la tupla `{rpz,{...}}` — `auto | true | false`.
- Valor global predeterminado del servidor: el elemento `TrackSources` opcional final (5.º) de la tupla `{srv,{...}}` — `off | auto | on` (por defecto `off`).

Ambos son opcionales y compatibles con versiones anteriores: los archivos de configuración existentes (`rpz` de 15 campos, `srv` de 4 campos) se cargan sin cambios y se comportan como `off`.

**Precedencia de resolución** — el estado efectivo para un feed se resuelve como:
1. el valor explícito `track_sources` del feed, si está definido;
2. de lo contrario, el valor global predeterminado del servidor;
3. de lo contrario, el valor predeterminado integrado `off`.

`auto` significa: rastrear solo feeds **multifuente**. Los feeds de una sola fuente nunca se enmascaran — su único nombre de fuente se devuelve directamente (sin coste de seguimiento).

**API — el campo aditivo `sources`**

La respuesta de `/api/v1/ioc/:ioc` gana un nuevo campo `sources` en cada objeto de feed. Es **aditivo y compatible con versiones anteriores**: todos los campos existentes no cambian, por lo que los clientes antiguos que lo ignoren seguirán funcionando.

- Feed multifuente rastreado: un array JSON con los nombres de las fuentes que contribuyen.
- Feed de una sola fuente: un array de un solo elemento con ese único nombre de fuente.
- Seguimiento desactivado o atribución desconocida (p. ej., una fila en caché anterior a la actualización, antes de su reconstrucción AXFR única): `null` (JSON) / `(disabled)` o `(unavailable)` (TXT).```json
{
  "feed": "mixed.ioc2rpz",
  "wildcard": "true",
  "type": "fqdn",
  "rpz_serial": 1709000000,
  "ioc_expiration": 0,
  "sources": ["abuse-ch", "internal-list"]
}