Moduli principali:

| Modulo | Responsabilità |
|--------|---------------|
| `ioc2rpz.erl` | Worker DNS TCP/TLS — accetta, analizza, convalida, risponde |
| `ioc2rpz_udp.erl` | Listener DNS UDP — query SOA |
| `ioc2rpz_conn.erl` | Recupero fonti IOC (HTTP/HTTPS/file/shell) |
| `ioc2rpz_db.erl` | Cache di zona e pacchetti basata su ETS |
| `ioc2rpz_sup.erl` | Supervisore principale, caricamento configurazione, scheduling zone |
| `ioc2rpz_rest.erl` | API REST di gestione (Cowboy) |
| `ioc2rpz_doh.erl` | Gestore DNS-over-HTTPS |

## Come usare ioc2rpz™
Puoi usare ioc2rpz™ con qualsiasi server DNS che supporti le Response Policy Zones, ad esempio versioni recenti di ISC BIND, PowerDNS e qualsiasi server DNS commerciale basato su questi prodotti (es. Infoblox, Blue Cat, Efficient IP). Un file di configurazione di esempio per BIND (named.conf) è fornito nella cartella 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>

## Interfaccia web di ioc2rpz™
[ioc2rpz.gui](https://github.com/Homas/ioc2rpz.gui) è un'interfaccia web di gestione sviluppata come progetto separato. Non è necessaria per eseguire ioc2rpz™.

## Supporto dei protocolli

ioc2rpz™ ascolta su più protocolli di trasporto. Tutti i trasporti condividono la stessa pipeline di elaborazione delle query: limitazione della frequenza, validazione TSIG, ricerca in zona e generazione della risposta. Consulta [docs/protocols.md](https://github.com/homas/ioc2rpz/blob/master/docs/protocols.md) per la documentazione completa dei protocolli.

### Riepilogo porte

| Porta | Protocollo | Servizio | Condizione |
|------|----------|---------|-----------|
| 53 | UDP | Query DNS (solo SOA) | Sempre |
| 53 | TCP | Query DNS, trasferimenti di zona AXFR/IXFR, gestione | Sempre |
| 853 | TCP+TLS | DoT — come TCP ma crittografato | Richiede configurazione `cert` |
| 443/8443 | TCP+TLS | DoH (`/dns-query`) e API REST | Richiede configurazione `cert` |

### UDP (Porta 53)

UDP viene utilizzato per query DNS leggere, principalmente ricerche SOA. Le risposte superiori a 512 byte (o alla dimensione del buffer annunciata da EDNS0) impostano il bit TC (troncamento) secondo RFC 1035 §4.2.1, spingendo i client a riprovare su TCP. I comandi di gestione non sono supportati su UDP.```bash
dig @127.0.0.1 zone.ioc2rpz SOA -y hmac-sha256:keyname:base64key

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

ioc2rpz™ supporta la distribuzione RPZ su DoT. Il listener TLS si avvia automaticamente sulla porta 853 quando un record `cert` è presente nella configurazione. DoT supporta le stesse operazioni di TCP (AXFR, IXFR, SOA, gestione).

- Versioni TLS supportate: 1.2 e 1.3 (`?TLSVersion = 'tlsv1.2-1.3'`)
- Riutilizzo della connessione supportato secondo RFC 7858 §3.4 (più query per sessione TLS, timeout di inattività di 30 secondi)
- Il PIN TLS non è supportato
- I messaggi DNS NOTIFY vengono inviati non crittografati (UDP in chiaro)
- I certificati si aggiornano automaticamente quando i file vengono sostituiti su disco (fino a ~2 minuti di ritardo a causa della cache SSL di Erlang)

Per la configurazione dei certificati, vedere [Certificati](#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

### Limitazione del tasso

Le query DNS sono limitate nel tasso utilizzando una chiave intelligente (ibrida) in modo che i client legittimi multi-zona non vengano penalizzati mentre viene bloccato l'abuso di variazione del nome della query:

- **Zona provisionata + QTYPE supportato** (`SOA`/`AXFR`/`IXFR`, classe `IN`) e **comandi di gestione riconosciuti** (classe `CHAOS`/`TXT`) sono tracciati per `{client_IP, query_name, query_type}` — quindi un secondario che interroga/trasferisce diverse zone (ad es. `rpz1`, `rpz2`, `rpz3`) più la gestione da un singolo IP viene contato indipendentemente per zona+tipo.
- **Tutto il resto** (zona sconosciuta/non provisionata, tipo di query non supportato, classe errata o nome di gestione non riconosciuto) viene aggregato per `{client_IP}`, così un attaccante non può bypassare il limite variando il nome della query.

Quando il limite viene superato, il server restituisce una risposta DNS `REFUSED`.

| Parametro | Default | Macro |
|-----------|---------|-------|
| Finestra | 10 secondi | `?RATE_LIMIT_WINDOW` (10000 ms) |
| Massimo richieste per finestra (granulare: zona+tipo noto / gestione) | 1 | `?MAX_REQUESTS_PER_WINDOW` |
| Massimo richieste per finestra (aggregato: zona sconosciuta / tipo non supportato) | 1 | `?MAX_UNKNOWN_REQUESTS_PER_WINDOW` |

La limitazione del tasso si applica a tutti i trasporti delle query DNS (UDP, TCP, TLS, DoH). La finestra e la soglia sono configurabili tramite macro in `include/ioc2rpz.hrl`.

### NOTIFICA DNS

Dopo un aggiornamento di zona (AXFR o IXFR), ioc2rpz™ invia messaggi di NOTIFICA DNS ([RFC 1996](https://tools.ietf.org/html/rfc1996)) su UDP agli indirizzi IP configurati in `NotifyList` della RPZ. Questo induce i server DNS secondari a controllare il seriale SOA della zona e ad avviare un trasferimento se il seriale è cambiato.```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 directories on a host system.  
You can pass a custom configuration file name via``-e`` parameter. E.g. ``-e CONF=./cfg/ioc2rpz2.conf``

## Variabili d'Ambiente

Le seguenti variabili d'ambiente sono utilizzate da ioc2rpz™, principalmente rilevanti per distribuzioni Docker. Sono definite in `config/sys.config.src` e `config/vm.args`.

| Variabile | Default | Descrizione |
|----------|---------|-------------|
| `IPv4` | — | Indirizzo di bind IPv4 |
| `IPv6` | — | Indirizzo di bind IPv6 |
| `CONF` | — | Percorso del file di configurazione (ad es. `./cfg/ioc2rpz.conf`) |
| `DB` | `/opt/ioc2rpz/db` | Directory del database per la persistenza ETS |
| `CD` | `/opt/ioc2rpz` | Directory di lavoro |
| `NODE_NAME` | `ioc2rpz` | Nome breve del nodo Erlang |
| `IO2Cookie` | `ioc2rpz` | Cookie distribuito di Erlang |

Passa le variabili d'ambiente a Docker con `-e`:```bash
docker run -d --name ioc2rpz -e CONF=./cfg/custom.conf -e NODE_NAME=mynode ...

Aggiorna il tuo `ioc2rpz.conf` per fare riferimento al percorso del certificato montato:```erlang
{cert, {"ssl/live/ns1.rpz-proxy.com/fullchain.pem", "ssl/live/ns1.rpz-proxy.com/privkey.pem", ""}}.

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

I certificati vengono anche ricaricati esplicitamente durante un ricaricamento della configurazione (`ioc2rpz-reload-cfg`): quando ioc2rpz rileva che i file dei certificati sono cambiati, riavvia immediatamente i listener TLS con il nuovo certificato, invece di attendere circa 2 minuti dalla cache SSL di Erlang. Aggiungi un passaggio `ioc2rpz-reload-cfg` al tuo hook di rinnovo per applicare i nuovi certificati senza tempi di inattività.

### Montaggio dei Volumi Docker

Quando si esegue in Docker, monta la directory dei certificati dall'host:```bash
docker run -d --name ioc2rpz \
  --mount type=bind,source=/etc/letsencrypt/live/ns1.rpz-proxy.com,target=/opt/ioc2rpz/ssl,readonly \
  ...

Erlang rileva automaticamente i file dei certificati sostituiti entro ~2 minuti. I certificati vengono anche ricaricati esplicitamente durante il ricaricamento della configurazione (`ioc2rpz-reload-cfg`). Non lasciare che i certificati scadano — rinnovali prima della scadenza per un servizio ininterrotto.

## Compilare dai Sorgenti

> **Nota:** La compilazione dai sorgenti è intesa per **sviluppo e test**. Per la produzione, **Docker è il metodo di distribuzione consigliato** — vedere [Docker Compose](#docker-compose) e il repository [ioc2rpz.dc](https://github.com/Homas/ioc2rpz.dc).

### Prerequisiti

- **Erlang/OTP 24 o successivo** (`erl -version` per verificare) e un [rebar3](https://www.rebar3.org) corrispondente.
- Una toolchain C (per compilare le dipendenze) e `git`.

### Compilare ed Eseguire```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

Vedi [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/master/docs/configuration.md) per il riferimento autorevole campo per campo (layout della tupla source/RPZ, timer SOA, gruppi di chiavi, certificati, ecc.). Per abilitare DoT (porta 853), DoH e l'API REST HTTPS, aggiungi una voce `{cert,{...}}` — vedi [Impostazione del certificato](#certificate-setup).

### Shell di sviluppo (solo sviluppo/test)

I seguenti comandi sono per lo sviluppo e il test locali — non per uso in produzione:```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

## Gestione di ioc2rpz™
### tramite DNS
ioc2rpz™ supporta la gestione tramite DNS/TCP o DoT. Si consiglia di utilizzare DoT o l'API REST su DNS/TCP. La versione attuale di ioc2rpz™ non supporta un IP/interfaccia di gestione separato. In ogni caso, è altamente consigliato creare una chiave TSIG designata (o più chiavi) che verrà utilizzata solo per la gestione. È possibile disattivare la gestione tramite DNS.  
Azioni supportate:
- Stato corrente di ioc2rpz™. Richiesta ``ioc2rpz-status``, classe ``CHAOS``, record ``TXT``. Ad esempio:```
dig +tcp -y dnsmkey_1:ayVnL+h2QKMszRVohrngagcEuIpN3RkecXKdwSa5WsHD5N4Y5R3NUMGM W8sIGv36gPkAtWtgarqKzN9tmHqEnA== @127.0.0.1 ioc2rpz-status TXT -c CHAOS

- Arresta ioc2rpz™. Nome RR ``ioc2rpz-terminate``, Classe RR ``CHAOS``, Tipo RR ``TXT``
- Richiedi una zona di esempio. Nome RR ``sample-zone.ioc2rpz``, Classe RR ``IN``, Tipo RR ``AXFR``
### tramite REST
L'API REST (porta 8443/tcp) è l'interfaccia di gestione preferita. Per motivi di sicurezza tutto il traffico di gestione deve essere criptato e l'API REST non viene avviata se non è presente un certificato SSL. Tutti gli endpoint accettano sia il metodo GET che POST.

L'autenticazione HTTP di base viene utilizzata per autenticare le richieste. Le chiavi TSIG di gestione vengono utilizzate per l'autenticazione delle richieste. Il nome di una chiave TSIG viene utilizzato come nome utente HTTP e la chiave TSIG come password. L'accesso all'API REST è limitato con l'ACL definito nel record `srv`.

Il segmento della versione dell'API supporta sia `v1` che `v1.0` (ad es., `/api/v1/stats/serv` o `/api/v1.0/stats/serv`).

L'API REST supporta l'output JSON (predefinito) e testo semplice in base all'intestazione `Accept`:
- `application/json` — output JSON (predefinito)
- `text/plain` — output in testo semplice```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

#### Parametri del percorso

| Parameter | Description |
|-----------|-------------|
| `:rpz_name` | nome della zona RPZ (es. `dga.ioc2rpz`) |
| `:source_name` | nome della sorgente IOC (es. `sample_fqdn`) |
| `:ioc` | Indicatore da cercare (FQDN o IP, es. `baddomain.com`) |

#### Endpoint delle statistiche

`/api/v1/stats/serv` — Statistiche del server (nome del nodo, regole totali, utilizzo 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}
  ]
}

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

`/api/v1/mgmt/update_tkeys` — Ricarica le chiavi TSIG dalla configurazione```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/mgmt/update_tkeys

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

#### Endpoint di aggiornamento delle zone

`/api/v1/update/all_rpz` — Forza il refresh completo di tutte le zone RPZ```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/update/all_rpz

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

#### Endpoint di Gestione Cache

`/api/v1/cache/sources/clear/all` — Rimuovere tutte le sorgenti dalla hot cache```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/clear/all

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

`/api/v1/cache/sources/load/all` — Ricarica tutte le sorgenti nella cache calda```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/load/all

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

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

## Monitoraggio e Controlli di Integrità

### Statistiche 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

### Controlli di integrità 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

Il formato a 4 campi rimane valido e imposta `TrackSources` su `off` per impostazione predefinita.
### **cert** record
Il record **cert** è utilizzato per definire un certificato e una chiave privata per le comunicazioni DNS over TLS, REST API e DoH. Per la generazione e gestione dei certificati, vedere [Impostazione del certificato](#certificate-setup).

Consiste in:
- percorso di un file contenente un certificato;
- percorso di un file contenente una chiave privata codificata in PEM;
- percorso di un file con certificati CA codificati in PEM.  

Esempio di record **cert**:```
{cert,{"cfg/cert.pem", "cfg/key.pem",	"cfg/cacerts.pem"}}.

### Record **key**
Le chiavi TSIG sono utilizzate per autenticazione e autorizzazione. Si consiglia di utilizzare chiavi TSIG diverse per la gestione di ioc2rpz™ e per i trasferimenti di zona.  
Il record **key** è composto da:
- nome della chiave TSIG;
- algoritmo. Sono supportati ``md5``, ``sha256`` e ``sha512``;
- la chiave;
- (opzionale) elenco di gruppi di chiavi a cui appartiene.

Esempi di record **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"]}}.

Fare riferimento alla documentazione di "dnssec-keygen" per i dettagli. Le chiavi possono essere assegnate a gruppi per l'autorizzazione basata su gruppi nel controllo di accesso alla zona RPZ.

### Record **key_group**
I gruppi di chiavi forniscono autorizzazione basata su gruppi per i trasferimenti e la gestione delle zone. Invece di elencare singole chiavi nei record `rpz` o `srv`, è possibile assegnare chiavi a gruppi nominati e fare riferimento al gruppo.

Esistono due modi per assegnare chiavi ai gruppi:
1. Inline tramite il 4° campo opzionale del record `key`: `{key, {Name, Alg, Secret, [Groups]}}`
2. Esplicitamente tramite un record `key_group` (mostrato di seguito)```erlang
{key_group, {GroupName, [KeyName1, KeyName2, ...]}}.

I gruppi vengono referenziati in `rpz` e `srv` record utilizzando la tupla `{groups, ["group1", "group2"]}` nella lista delle chiavi:```erlang
{rpz, {"zone.ioc2rpz", 7202, 3600, 2592000, 7200, "true", "true", "nxdomain",
       ["dnsproxykey_1", {groups, ["customers", "public"]}],
       "fqdn", 86400, 3600, ["source1"], [], []}}.

### **source** record
Una source è un feed di indicatori malevoli. Sono supportati FQDN, indirizzi IPv4 e IPv6. Una source è un file di testo o un feed di dati testuali. Gli indicatori devono essere separati da caratteri di newline/carriage return (/n, /r o entrambi /r/n). ioc2rpz™ supporta un numero illimitato di indicatori.  
Il record **source** è composto da:
- nome della source;
- percorso della source per il trasferimento completo della source (AXFR). Sono supportati URL (http/https/ftp), file locali e script. Il prefisso **file:** è usato per file locali. Il prefisso **shell:** è usato per eseguire uno script/comando locale su un host/container che deve restituire indicatori e una data di scadenza opzionale su STDOUT;
- percorso della source per il trasferimento incrementale della source (IXFR). I percorsi AXFR e IXFR supportano parole chiave per abbreviare gli URL e fornire timestamp di aggiornamento della zona:
  - **[:AXFR:]** - percorso AXFR completo. Può essere usato solo nei percorsi IXFR;
  - **[:FTimestamp:]** - timestamp dell'ultimo aggiornamento della source (es. 1507946281)
  - **[:ToTimestamp:]** - timestamp corrente;
- REGEX utilizzata per estrarre gli indicatori e la loro data di scadenza. Il primo match è un indicatore, il secondo match è la data di scadenza. La data di scadenza è un parametro opzionale. L'espressione regolare deve essere racchiusa tra virgolette doppie. Se si specifica una REGEX vuota (`""`), verrà utilizzata una REGEX predefinita (`"^([A-Za-z0-9][A-Za-z0-9\-\._]+)[^A-Za-z0-9\-\._]*.*$"`). `none` viene usato se non è richiesta alcuna REGEX (la source fornisce già i dati nel formato richiesto).
Parametri opzionali (devono essere usati tutti o nessuno):
- UserID (usato internamente).
- Numero massimo di IoC.
- Aggiornamento completo della source, tempo di cache calda (in secondi).
- Aggiornamento incrementale della source, tempo di cache calda (in secondi).

I download da source HTTPS verificano il certificato TLS del server remoto. Le source con certificati non validi o autofirmati non riusciranno a scaricare. Per certificati autofirmati, utilizzare una source con `shell:` e `curl --insecure`.

**Restrizioni per file locali:** i percorsi `file:` contenenti `..` (attraversamento di directory padre) sono rifiutati per sicurezza; utilizzare un percorso senza `..` (all'interno della directory di lavoro/dati).

**Restrizioni per comandi shell:** l'eseguibile di ogni segmento della pipeline deve essere un percorso assoluto (es. `/usr/bin/curl`) o un'utilità di testo sicuro con nome semplice (`sort`, `uniq`, `grep`, `sed`, `awk`, `gawk`, ecc.); i comandi distruttivi e le shell (`rm`, `bash`, `sh`, ecc.) sono bloccati, e la sostituzione di comando (`$(...)`, backtick) e la redirezione dell'output (`>`, `>>`) sono rifiutate. I comandi rifiutati non vengono eseguiti e vengono registrati tramite evento CEF 151 (comandi eseguiti tramite 150). Consultare [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/master/docs/configuration.md#shell-command-restrictions) per l'insieme completo di regole.

Se una source restituisce meno del 50% del suo precedente conteggio di indicatori, l'aggiornamento viene rifiutato e i dati precedenti vengono mantenuti. Questo impedisce che feed degradati riducano la copertura RPZ. Configurabile tramite la macro `?SOURCE_MIN_IOC_RATIO`.

Esempio di record **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}}.

### Attribuzione della fonte IOC
Un feed RPZ è costruito unendo indicatori provenienti da più fonti. L'attribuzione della fonte consente all'API di ricerca IOC di segnalare **quale(i) fonte(i) all'interno di un feed** ha contribuito a un indicatore — utile per smistare un falso positivo segnalato. Il tracciamento è **disattivato per impostazione predefinita** e controllato per feed con un'impostazione predefinita globale opzionale a livello di server.

**Configurazione**

- Per-feed: l'elemento `TrackSources` finale opzionale (16°) della tupla `{rpz,{...}}` — `auto | true | false`.
- Impostazione predefinita globale del server: l'elemento `TrackSources` finale opzionale (5°) della tupla `{srv,{...}}` — `off | auto | on` (predefinito `off`).

Entrambi sono opzionali e retrocompatibili: i file di configurazione esistenti (rpz a 15 campi, srv a 4 campi) vengono caricati invariati e si comportano come off.

**Precedenza di risoluzione** — lo stato effettivo per un feed viene risolto come:
1. il valore esplicito `track_sources` del feed, se impostato;
2. altrimenti l'impostazione predefinita globale del server;
3. altrimenti l'impostazione predefinita incorporata `off`.

`auto` significa: traccia solo i feed **multi-fonte**. I feed a fonte singola non vengono mai mascherati — il loro unico nome di fonte viene restituito direttamente (nessun costo di tracciamento).

**API — il campo additivo `sources`**

La risposta di `/api/v1/ioc/:ioc` acquisisce un nuovo campo `sources` su ogni oggetto feed. È **additivo e retrocompatibile**: tutti i campi esistenti rimangono invariati, quindi i vecchi client che lo ignorano continuano a funzionare.

- Feed multi-fonte tracciato: un array JSON dei nomi delle fonti contribuenti.
- Feed a fonte singola: un array con un singolo elemento contenente il nome di quella fonte.
- Tracciamento disabilitato o attribuzione sconosciuta (ad es. una riga cache pre-aggiornamento prima della sua ricostruzione AXFR una tantum): `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"]
}