Spcnet.it

2026-08-16 08:07:39

Azure Private Link over IPv6: come raggiungere i servizi PaaS senza più IPv4

Il problema che risolve

Chi progetta reti Azure da qualche anno conosce bene il limite: gli endpoint privati (Private Endpoint) e Azure Private Link, il meccanismo che permette di raggiungere un servizio PaaS — storage account, database, Key Vault — attraverso un indirizzo IP privato all’interno della propria rete virtuale invece che tramite l’endpoint pubblico, hanno sempre funzionato solo su IPv4. Per le organizzazioni che stanno completando la transizione verso reti dual-stack o IPv6-only — spinte da esaurimento di spazio IPv4 privato, requisiti normativi o semplicemente modernizzazione dell’infrastruttura — questo obbligava a mantenere un livello di traduzione o connettività IPv4 residua solo per parlare con i servizi PaaS.

Microsoft ha annunciato la preview pubblica di Azure Private Link over IPv6, che elimina questa dipendenza: gli endpoint privati possono ora esporre un indirizzo IPv6, permettendo a client e workload nativamente IPv6 di raggiungere i servizi PaaS supportati senza alcuna intermediazione IPv4.

Servizi supportati nella preview

Al momento della preview pubblica, il supporto copre un sottoinsieme mirato di servizi PaaS ad alto utilizzo:

• Azure Storage (Blob, ecc.)
• Azure SQL Database
• Azure Key Vault
• Azure Data Explorer

È lecito aspettarsi che l’elenco si allarghi man mano che la feature matura verso la disponibilità generale, seguendo lo schema tipico delle preview Azure: si parte dai servizi con maggiore adozione enterprise e si estende progressivamente.

Due scenari di connettività

La documentazione distingue due modalità d’uso, entrambe rilevanti per chi progetta reti ibride:

Connettività nativa Azure

Macchine virtuali dual-stack o IPv6-only all’interno di una rete virtuale Azure accedono ai servizi PaaS tramite l’endpoint privato IPv6, con il traffico che rimane interamente sulla dorsale privata Microsoft — lo stesso principio di isolamento dal traffico pubblico che Private Link garantisce già per IPv4.

Connettività ibrida on-premises

Client IPv6 in un datacenter on-premises possono raggiungere i servizi Azure attraverso ExpressRoute, con una connessione privata end-to-end che non attraversa mai la rete pubblica Internet. Questo scenario richiede tipicamente una Virtual Network Routing Appliance (VNRA) con route definite dall’utente (UDR) per instradare correttamente il traffico IPv6 tra l’ambiente on-premises e la rete virtuale Azure.

Requisiti di configurazione

Per attivare e usare la feature in preview servono alcuni passaggi preliminari:

• Registrazione della subscription al feature flag della preview pubblica (come per la maggior parte delle feature in anteprima su Azure, tramite az feature register o dal portale).
• Rete virtuale dual-stack: la VNet deve avere spazio di indirizzamento sia IPv4 sia IPv6 configurato, non è sufficiente aggiungere IPv6 alla sola subnet dell’endpoint privato.
• Endpoint privati abilitati IPv6, creati esplicitamente con configurazione dual-stack.
• DNS coerente: le zone DNS private devono risolvere i nomi dei servizi PaaS anche verso i record AAAA (indirizzi IPv6) associati agli endpoint privati, non solo verso i record A esistenti.
• Per lo scenario ibrido, la VNRA con UDR menzionata sopra, per garantire che il traffico IPv6 proveniente da ExpressRoute venga instradato correttamente verso l’endpoint privato.

Un dettaglio che vale la pena sottolineare per chi pianifica un rollout: la configurazione DNS è spesso il punto in cui i deployment IPv6 falliscono silenziosamente. Se la zona privata continua a restituire solo record A, i client dual-stack proveranno comunque a instradare la richiesta su IPv4, vanificando parte del vantaggio della nuova feature. Vale la pena verificare esplicitamente con nslookup -type=AAAA o dig AAAA che la risoluzione avvenga come previsto prima di considerare il deployment completo.

Disponibilità regionale

La preview pubblica è per ora limitata a un numero ristretto di region:

• West Central US
• East Asia
• UK South
• Central US
• North Europe

Chi opera in altre region europee (ad esempio West Europe o Italy North) dovrà attendere l’espansione della preview o la disponibilità generale prima di poter testare la feature sui propri workload di produzione — un fattore da tenere in conto nella pianificazione di eventuali migrazioni a reti IPv6-only che dipendano da questa capacità.

Perché conviene iniziare a pianificare ora

Anche per chi non ha una scadenza imminente per l’adozione IPv6, ci sono buone ragioni pratiche per iniziare a familiarizzare con questa capacità:

• Esaurimento dello spazio IPv4 privato: le grandi organizzazioni con centinaia di VNet e subnet spesso si scontrano con conflitti di indirizzamento RFC 1918 quando serve fare peering tra reti create in tempi diversi o durante fusioni aziendali. IPv6 elimina strutturalmente questo problema.
• Compliance e requisiti governativi: diverse amministrazioni pubbliche, in Italia come altrove, hanno tabelle di marcia che richiedono supporto IPv6 nativo per i servizi digitali entro scadenze specifiche.
• Riduzione della complessità NAT: meno traduzione di indirizzi significa meno stato da gestire e da diagnosticare quando qualcosa si rompe — un vantaggio concreto in fase di troubleshooting di rete.

Per un architetto di rete Azure, il percorso pragmatico consiste nel registrare fin da ora una subscription non di produzione alla preview, distribuire una VNet dual-stack di test e verificare il comportamento end-to-end (inclusa la risoluzione DNS) prima che la feature diventi disponibile su larga scala. Arrivare preparati alla disponibilità generale, quando probabilmente coprirà più servizi e più region, evita di dover improvvisare un redesign di rete sotto pressione.

Conclusione

Azure Private Link over IPv6 chiude una lacuna che gli architetti di rete Azure conoscono da anni: l’impossibilità di raggiungere i servizi PaaS più comuni tramite endpoint privati IPv6 senza intermediazione IPv4. La preview è ancora limitata per servizi e region, ma la direzione è chiara e coerente con il resto dell’ecosistema Azure networking (Application Gateway ed ExpressRoute hanno già ricevuto supporto IPv6 esteso nell’ultimo periodo). Chi gestisce infrastrutture ibride o pianifica una transizione IPv6 farebbe bene a iniziare i test già in questa fase di anteprima.

Fonte: Azure Private Link Over IPv6 Enters Public Preview — Petri IT Knowledgebase. Annuncio ufficiale: Microsoft Tech Community.

Announcing Public Preview - Azure Private Link over IPv6 | Microsoft Community Hub

1. Overview Private Link over IPv6 (PL IPv6) enables customers to securely access Azure PaaS services over IPv6-based connectivity. This capability is...

^{amitmishra (TECHCOMMUNITY.MICROSOFT.COM)}

Spcnet.it

2026-08-16 08:07:57

Agent Plugins 1.0: lo standard che rende portabili skill e server MCP tra VS Code, Copilot CLI e SDK

Il problema che Agent Plugins 1.0 prova a risolvere

Chi lavora quotidianamente con GitHub Copilot conosce bene la frammentazione degli ultimi due anni: skill scritte per VS Code che non funzionano su Copilot CLI, configurazioni MCP duplicate tra client diversi, agenti custom da ricostruire da zero ogni volta che si cambia strumento. Con Agent Plugins 1.0, annunciato a metà agosto 2026, GitHub prova a chiudere questa frammentazione introducendo uno standard aperto — non un formato proprietario — per pacchettizzare skill e server MCP in un plugin installabile una sola volta e utilizzabile su più superfici: VS Code, Copilot CLI, Copilot SDK, l’app Copilot e il coding agent cloud.

È un cambio di prospettiva interessante anche per chi non usa Copilot come strumento principale: la specifica Agent Plugins non è un’invenzione isolata, ma converge con formati simili già visti in altri ecosistemi (Claude, OpenPlugin), e questo la rende rilevante per chiunque costruisca strumenti per agenti AI, non solo per i team Microsoft/GitHub.

Anatomia di un Agent Plugin

Un plugin conforme allo standard 1.0 è una directory con una struttura riconoscibile. Il file centrale è plugin.json, che dichiara esplicitamente lo schema a cui aderisce:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "my-dev-tools",
  "description": "Utility per lo sviluppo React",
  "version": "1.2.0"
}

I soli campi obbligatori sono $schema e name; tutto il resto (version, description, author, homepage, repository, license, keywords) è opzionale ma consigliato per la pubblicazione su un marketplace.

Attorno al manifest, la struttura tipica di un plugin più completo è questa:

my-testing-plugin/
  plugin.json              # Metadati del plugin
  skills/
    test-runner/
      SKILL.md              # Istruzioni della skill
      run-tests.sh           # Script di supporto
  agents/
    test-reviewer.agent.md   # Agente custom (client-specific)
  hooks/
    hooks.json                # Configurazione hook (client-specific)
  scripts/
    validate-tests.sh
  .mcp.json                   # Definizione dei server MCP

La distinzione più importante per chi progetta un plugin è tra componenti portabili e componenti client-specific:

• Portabili (parte dello standard 1.0): server MCP (integrazioni con tool esterni) e skill, cioè istruzioni, script e risorse caricate on-demand dall’agente.
• Client-specific (solo VS Code, ad esempio): agenti custom con personalità e configurazione tool dedicata, hook che eseguono comandi shell in punti precisi del ciclo di vita dell’agente, e slash command richiamabili in chat con /.

Questa separazione è la vera innovazione pratica: uno stesso plugin può portare le sue skill e i suoi server MCP ovunque, mentre le personalizzazioni specifiche di un client restano lì dove hanno senso, senza rompere la compatibilità altrove.

Configurare i server MCP dentro un plugin

I server MCP si dichiarano in .mcp.json (o mcp.json), con variabili d’ambiente che il runtime dell’agente risolve automaticamente al momento del caricamento:

{
  "mcpServers": {
    "plugin-database": {
      "command": "${PLUGIN_ROOT}/servers/db-server",
      "args": ["--config", "${PLUGIN_ROOT}/config.json"],
      "env": {
        "DB_PATH": "${PLUGIN_ROOT}/data"
      }
    }
  }
}

La variabile ${PLUGIN_ROOT} punta sempre alla directory del plugin installato, indipendentemente da dove l’utente finale lo abbia scaricato — un dettaglio che elimina un’intera classe di bug legati a percorsi assoluti hardcoded nei plugin distribuiti da terze parti.

Hook: automazioni sul ciclo di vita dell’agente

Per i client che supportano questa estensione (il formato è compatibile con la sintassi già nota da Claude), gli hook permettono di agganciare comandi shell a eventi specifici, ad esempio dopo l’uso di un tool:

{
  "hooks": {
    "PostToolUse": [
      {
        "type": "command",
        "command": "${PLUGIN_ROOT}/scripts/format.sh"
      }
    ]
  }
}

Un caso d’uso concreto: formattare automaticamente il codice generato dall’agente subito dopo ogni modifica a un file, senza dover ricordare di lanciare il linter manualmente.

Migrare un plugin Copilot esistente

Chi ha già plugin Copilot “vecchio formato” non deve riscrivere nulla da zero. GitHub descrive un percorso di migrazione minimo:

1. Aggiungere il campo $schema al plugin.json esistente, puntandolo allo schema Agent Plugins 1.0.
2. Mantenere le skill dove sono già, sotto skills/.
3. Spostare i file specifici di Copilot (agenti, comandi, regole, hook, canvas) dentro una directory dedicata com.github.copilot/, così da separarli chiaramente dalla parte portabile.

I plugin GitHub Copilot esistenti restano comunque supportati senza obbligo di migrazione: è un aggiornamento incrementale, non un breaking change forzato.

Governance aziendale: managed-settings.json

Per i team enterprise, probabilmente l’aspetto più rilevante non è la portabilità in sé ma il controllo centralizzato che ne deriva. Il file managed-settings.json permette di definire una baseline aziendale su cosa è installabile:

{
  "extraKnownMarketplaces": {
    "company-tools": {
      "source": { "source": "github", "repo": "vostra-org/plugin-marketplace" }
    }
  },
  "enabledPlugins": {
    "code-formatter@company-tools": true
  }
}

Tre leve principali:

• enabledPlugins — installa automaticamente o blocca esplicitamente plugin specifici per tutti gli utenti gestiti.
• extraKnownMarketplaces — aggiunge marketplace interni oltre a quelli pubblici di default.
• strictKnownMarketplaces — se attivato, limita l’installazione ai soli marketplace esplicitamente autorizzati, impedendo l’uso di sorgenti non gestite.

Le impostazioni enterprise agiscono come baseline additiva: i team possono comunque aggiungere plugin approvati sopra la configurazione centrale, senza però poter aggirare i blocchi imposti a livello organizzativo. Per chi gestisce flotte di sviluppatori con policy di sicurezza stringenti, è la differenza tra “confidare che ognuno installi solo cose sicure” e avere un controllo verificabile.

Dove si installano i plugin

Il canale di scoperta di default è l’Awesome Copilot marketplace, disponibile fin da subito in VS Code, Copilot CLI e nell’app Copilot. Per plugin locali o in sviluppo, VS Code offre una registrazione esplicita via impostazioni:

"chat.pluginLocations": {
    "/percorso/al/mio-plugin": true,
    "/percorso/a/un-altro-plugin": false
}

Un dettaglio utile in fase di debug: se un plugin non viene rilevato, vale la pena controllare che chat.plugins.enabled sia attivo, che il nome nel manifest sia in kebab-case (obbligatorio per lo standard 1.0), e — per problemi di installazione persistenti — ripulire la cache locale in ~/.config/Code/agentPlugins/ su Linux.

Conclusione

Agent Plugins 1.0 non introduce funzionalità radicalmente nuove rispetto a quello che skill e server MCP già facevano singolarmente: il suo valore è nella standardizzazione del confezionamento e nella governance che ne deriva. Per un team che sviluppa strumenti interni per i propri agenti AI — che siano skill per il debug, integrazioni con sistemi proprietari via MCP, o automazioni sul ciclo di vita dell’agente — poter scrivere il plugin una sola volta e vederlo funzionare su CLI, editor e SDK senza riscritture è un risparmio di manutenzione concreto, non solo un dettaglio architetturale. Vale la pena tenerlo d’occhio anche per chi non usa Copilot: essendo uno standard aperto, è probabile che altri agent tool ne adottino la compatibilità nei prossimi mesi.

Fonte: Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app — GitHub Changelog

Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app - GitHub Changelog

You can now build a plugin once and use it across all compatible agent clients. We published Agent Plugins 1.0 on August 6 with AWS, Anysphere, Microsoft, OpenAI, and Vercel.…

^{Allison (The GitHub Blog)}

(in)sicurezza digitale

2026-08-15 13:02:34

HoneyMyte aggiorna CoolClient: la backdoor di Mustang Panda ora si nasconde con un rootkit kernel

Un driver kernel firmato, tre stadi di caricamento cifrati e un binario legittimo Sangfor usato come cavallo di Troia: è la nuova versione di CoolClient, la backdoor con cui il gruppo di cyberspionaggio cinese HoneyMyte (alias Mustang Panda) sta colpendo enti governativi in Myanmar, Mongolia, Pakistan e Russia. La novità che fa scattare l’allarme tra i ricercatori non è la campagna in sé — HoneyMyte è attivo da oltre un decennio — ma l’aggiunta di un rootkit a livello kernel che rende l’impianto praticamente invisibile agli strumenti di sicurezza tradizionali.

Chi è HoneyMyte e perché la sua evoluzione conta

HoneyMyte, meglio noto nella letteratura di settore come Mustang Panda (o anche Bronze President, Red Delta, Stately Taurus a seconda del vendor), è uno dei gruppi APT cinesi più prolifici degli ultimi anni. Il suo modus operandi classico prevede campagne di spear-phishing e compromissioni mirate contro ministeri, agenzie governative e ONG in Asia, con incursioni sempre più frequenti anche verso l’Europa dell’Est e la Russia — un dettaglio che conferma come la geografia dello spionaggio cinese non si limiti più al solo vicinato asiatico.

Il gruppo è storicamente associato a PlugX, uno dei RAT più longevi e riutilizzati nell’ecosistema APT cinese, spesso impiegato come primo impianto post-compromissione prima del rilascio di payload più specializzati. Secondo l’analisi tecnica pubblicata da Kaspersky Securelist, è esattamente questo lo schema osservato nella campagna più recente: PlugX apre la porta, CoolClient la blinda dall’interno.

La catena di infezione: da un binario Sangfor al rootkit kernel

La sofisticazione della catena di compromissione è il vero elemento di interesse tecnico. Dopo l’accesso iniziale tramite PlugX, gli operatori HoneyMyte rilasciano un eseguibile legittimo del vendor di sicurezza Sangfor (rinominato defender.exe), sfruttato come DLL sideloader per caricare libngs.dll, il primo stadio offuscato con XOR a 32 byte. Questo a sua volta decifra e carica loadcert.ini, un secondo stadio che gestisce i comandi e orchestra l’installazione del driver.

Il payload viene quindi iniettato nel processo synchost.exe, mentre il componente più critico dell’intera catena — il driver kernel msagent.sys — viene installato come servizio Windows (media_updaten) con persistenza garantita anche tramite chiave di registro AutoRun. Il driver risulta firmato con un certificato digitale intestato a Nanjing Ranyi Technology Co., Ltd., valido nel biennio 2013-2014: una firma probabilmente rubata o riutilizzata, prassi comune tra gli attori APT cinesi per garantire ai propri driver il caricamento senza generare allarmi da parte di Driver Signature Enforcement.

Cosa fa davvero il rootkit

Una volta caricato, msagent.sys mette a disposizione dell’impianto un set di 33 handler IOCTL, di cui solo 3 effettivamente utilizzati dalla versione corrente di CoolClient — segno che il driver è pensato come piattaforma riutilizzabile per operazioni future, non come strumento usa e getta. Le capacità osservate includono:

• Occultamento del processo CoolClient tramite scollegamento dalla PsLoadedModuleList
• Protezione di file e directory attraverso un minifilter con altitudine assegnata dinamicamente per evitare conflitti con altri driver installati
• Protezione delle chiavi di registro associate all’impianto (es. Wid_H1deF5Dirs)
• Filtraggio del traffico di rete via Nsiproxy per nascondere le connessioni verso l’infrastruttura C2
• Hook sugli oggetti processo e thread tramite ObRegisterCallbacks, per bloccare l’accesso di EDR e antivirus al processo protetto

Il payload finale, cert.ini, gestisce le comunicazioni verso un’infrastruttura C2 piuttosto ampia e diversificata, che mescola domini dynamic DNS, servizi di hosting gratuito e domini camuffati da marchi legittimi come Lenovo — una tecnica di mimetizzazione tipica per superare i controlli basati su reputazione.

Perché conta per i difensori

L’uso di un rootkit kernel-mode alza sensibilmente l’asticella per il rilevamento: molti EDR faticano a ispezionare in profondità il comportamento dei driver firmati, specialmente quando l’altitudine del minifilter viene assegnata dinamicamente proprio per evitare collisioni rilevabili. Per i team di detection engineering, la superficie di hunting più promettente resta quella comportamentale: caricamento anomalo di driver con certificati datati o revocati, servizi Windows con nomi generici tipo “media_updaten”, processi synchost.exe con parent process inatteso, e DLL sideloading su binari di sicurezza legittimi come quelli Sangfor — tecnica, quest’ultima, sempre più gettonata proprio perché i prodotti di sicurezza godono di whitelist implicite.

La geografia delle vittime — Myanmar, Mongolia, Pakistan e Russia — conferma inoltre come HoneyMyte mantenga un interesse costante verso i vicini asiatici della Cina e, sempre più spesso, verso obiettivi russi: un segnale che nemmeno le relazioni diplomatiche tra Pechino e Mosca mettono al riparo Mosca dall’intelligence gathering cinese.

Indicatori di compromissione

# Hash
msagent.sys (driver kernel): 2d7c8780e97409770a9d4f31c66c9d63 / 9460E150E1981D5C165043520C5C12FE
libngs.dll (loader stage 1): 9717F005C5FB98E08D2AD983D88F94EE / F518D8E5FE70D9090F6280C68A95998F
ctxmui.dll: EB79558B037669792652A816E2C669DE

# Domini C2
cloudtroe.giize[.]com
employers.theworkpc[.]com
freeread.casacam[.]net
us.lenovoappstore[.]com
sundanish.freeddns[.]org
torinarlabs.webredirect[.]org
news.dursamjbataar[.]org
video.dursamjbataar[.]org
black-popular[.]com
whatismybestthing[.]com

# Percorsi di installazione
C:\Program Files\Microsoft\Windows Defender\
C:\Program Files\Windows Media Player\mediares\
C:\ProgramData\symantecdir\

# TTP MITRE ATT&CK
T1574.002 - DLL Side-Loading (binario Sangfor)
T1547.001 - Persistenza via registro AutoRun
T1134.003 - Process injection (synchost.exe)
T1548.004 - UAC bypass (RPC + PPID spoofing)
T1547.011 - Servizio Windows dannoso (media_updaten)
T1112 - Manipolazione chiavi di registro
T1562.008 - Disabilitazione esclusioni Windows Defender via WMIC
T1014 - Rootkit kernel-mode
T1047 - Windows Management Instrumentation

Fonte tecnica principale: Kaspersky Securelist.

Spcnet.it

2026-08-15 06:48:58

DNS su Linux: la guida completa a resolv.conf, systemd-resolved e troubleshooting con dig e getent

Perché la risoluzione DNS su Linux è più complicata di quanto sembri

Chiunque amministri server Linux prima o poi si scontra con il fastidioso “Temporary failure in name resolution” o con un DNS che risolve alcuni domini e non altri. La causa quasi sempre non è il DNS in sé, ma la catena di componenti che sta tra un comando come curl e la vera query verso un nameserver: /etc/nsswitch.conf, /etc/resolv.conf, e — sulle distribuzioni moderne — systemd-resolved o NetworkManager che gestiscono tutto al posto nostro, spesso silenziosamente.

In questo articolo ricostruiamo l’intera catena di risoluzione dei nomi su Linux, i comandi giusti per ispezionarla e un metodo pratico per isolare il problema in pochi minuti, invece di procedere per tentativi.

L’ordine di risoluzione: nsswitch.conf

Il primo file da guardare non è resolv.conf, ma /etc/nsswitch.conf. La riga che interessa è quella che inizia con hosts:, tipicamente:

hosts: files dns myhostname

Questo significa che il sistema consulta prima /etc/hosts (voce files), poi il DNS, e infine risolve il proprio hostname locale. Se un dominio dovrebbe risolvere correttamente ma non lo fa, e in /etc/hosts c’è una voce residua o sbagliata, il DNS non c’entra affatto: la query non arriva nemmeno a un resolver.

Chi gestisce davvero /etc/resolv.conf

Sulle distribuzioni Linux di qualche anno fa, /etc/resolv.conf era un file statico che si editava a mano. Da Ubuntu 18.04 in poi, e su gran parte delle distribuzioni moderne (Fedora, molte immagini cloud di Debian/RHEL), quel file è generato dinamicamente — modificarlo a mano spesso non produce alcun effetto persistente, perché viene sovrascritto al prossimo evento di rete.

Il modo più veloce per capire chi ha il controllo è guardare cosa punta il file:

ls -la /etc/resolv.conf

• Se è un file regolare, probabilmente la configurazione è statica.
• Se è un symlink verso /run/systemd/resolve/stub-resolv.conf, il sistema usa systemd-resolved.
• Se punta a /run/NetworkManager/resolv.conf, è NetworkManager a gestire il DNS.

Sapere quale dei due componenti è “al comando” evita l’errore più comune: editare resolv.conf a mano, vederlo funzionare per pochi secondi, e poi ritrovarsi la modifica cancellata al riavvio dell’interfaccia di rete.

Il formato di resolv.conf

nameserver 1.1.1.1
nameserver 8.8.8.8
search example.com
options ndots:5

Alcuni dettagli spesso ignorati ma rilevanti in produzione:

• nameserver — Linux ne considera al massimo tre; gli altri vengono ignorati.
• search — suffisso di dominio aggiunto automaticamente a hostname “corti” (senza punti o con pochi punti).
• options ndots:5 — controlla quando un nome viene considerato “già qualificato” e quando invece riceve il suffisso di search. È un parametro che in ambienti Kubernetes causa non pochi grattacapi, perché una query con pochi punti può generare fino a 5 lookup DNS prima di andare a buon fine.

systemd-resolved: il resolver locale che (quasi) nessuno vede

Sulla maggior parte delle distribuzioni moderne, le query DNS delle applicazioni non vanno direttamente a Internet: passano per un listener locale su 127.0.0.53:53, gestito da systemd-resolved, che si occupa di caching e — dove configurato — di DNSSEC. Lo strumento per interagirci è resolvectl.

# Stato completo per interfaccia
resolvectl status

# Query esplicita tramite systemd-resolved
resolvectl query esempio.it

# Svuotare la cache (utile dopo un cambio DNS o un test)
sudo resolvectl flush-caches

# Statistiche su cache hit/miss
resolvectl statistics

Per impostare server DNS validi per l’intero sistema, indipendentemente dall’interfaccia attiva, si edita /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

e si riavvia il servizio:

sudo systemctl restart systemd-resolved

dig, getent e la differenza che fa risparmiare ore di debug

Il tool principale per interrogare direttamente un server DNS è dig (pacchetto dnsutils su Debian/Ubuntu, bind-utils su Fedora/RHEL):

dig esempio.it
dig @8.8.8.8 esempio.it        # interroga un resolver specifico
dig esempio.it MX               # record di posta
dig esempio.it AAAA              # IPv6
dig esempio.it NS                # nameserver autoritativi
dig -x 104.21.1.1                # reverse lookup
dig +short esempio.it            # output compatto
dig +trace esempio.it            # ricostruisce l'intera catena, dai root server in giù
dig +dnssec esempio.it           # verifica la firma DNSSEC

Il punto chiave, spesso sottovalutato: dig ignora completamente /etc/nsswitch.conf e /etc/hosts. Parla direttamente con un server DNS. Questo lo rende perfetto per isolare i problemi, ma pericoloso se usato come unico strumento diagnostico: dig può funzionare perfettamente mentre l’applicazione continua a fallire, perché il problema è nel percorso NSS (Name Service Switch), non nel DNS.

Per replicare esattamente quello che fa un’applicazione, si usa getent:

getent hosts esempio.it

Se dig funziona ma getent no, il problema non è di rete: è nella configurazione NSS, in /etc/hosts, o nel modulo myhostname. È una distinzione che vale la pena memorizzare, perché sposta immediatamente l’indagine nella direzione giusta.

Un metodo, non solo comandi: la checklist di troubleshooting

Di fronte a un errore di risoluzione, seguire un ordine preciso evita di girare a vuoto:

1. Controllare che /etc/resolv.conf contenga un nameserver valido e capire chi lo gestisce (ls -la).
2. Verificare che /etc/nsswitch.conf includa dns nella riga hosts.
3. Testare un resolver pubblico direttamente: dig @1.1.1.1 google.com. Se funziona, la rete verso l’esterno è a posto.
4. Testare il resolver locale: dig google.com. Se qui fallisce ma il passo precedente no, il problema è nella configurazione locale (systemd-resolved, NetworkManager, o un resolver aziendale irraggiungibile).
5. Controllare lo stato del servizio: systemctl status systemd-resolved.
6. Guardare gli assegnamenti DNS per interfaccia con resolvectl status — particolarmente utile in scenari con VPN e split-DNS.
7. Svuotare la cache con resolvectl flush-caches se si sospettano record stale.
8. Confrontare dig e getent: se divergono, il problema è nel percorso NSS.
9. Per fallimenti persistenti e inspiegabili, dig +trace ricostruisce l’intera catena di delega dai root server fino all’autoritativo, rivelando problemi come delegazioni NS rotte o glue record mancanti.

Split-DNS e VPN: un caso che confonde molti

Con una VPN aziendale attiva, resolvectl status mostra a quale interfaccia è associato ciascun dominio DNS. Se il dominio associato al link VPN è ~., quell’interfaccia diventa la route DNS predefinita per tutte le query. Se invece è qualcosa come ~interna.azienda.it, solo le query per quel dominio specifico vengono instradate sul tunnel — le altre continuano a passare per il resolver pubblico. Non riconoscere questa differenza è una causa frequente di “il sito interno non si risolve, ma internet funziona” o viceversa.

Fissare un DNS statico senza che venga sovrascritto

Su sistemi gestiti da NetworkManager, il modo corretto non è editare resolv.conf ma dire a NetworkManager di non sovrascrivere le impostazioni manuali:

nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"

Su sistemi con systemd-resolved, la via pulita è impostare DNS= e FallbackDNS= in resolved.conf, come visto sopra. Solo come ultima risorsa — ad esempio su container minimali senza questi servizi — ha senso rendere resolv.conf immutabile:

sudo chattr +i /etc/resolv.conf   # blocca il file
sudo chattr -i /etc/resolv.conf   # sblocca per un aggiornamento futuro

Quale resolver scegliere

Per server in produzione, affidarsi al solo router di casa/ufficio è rischioso: se il router si blocca o si riavvia, cade anche la risoluzione DNS di tutti i servizi a valle. Tra i resolver pubblici più usati in ambito professionale: Cloudflare (1.1.1.1 / 1.0.0.1, orientato a bassa latenza e privacy), Google (8.8.8.8 / 8.8.4.4, rete anycast molto ridondata) e Quad9 (9.9.9.9, che filtra domini noti per malware già a livello di resolver).

Conclusione

La risoluzione DNS su Linux non è un singolo componente ma una catena — NSS, resolv.conf, systemd-resolved o NetworkManager, e infine il resolver remoto. La maggior parte dei problemi “misteriosi” si risolve rapidamente se si segue la catena nell’ordine giusto invece di riavviare servizi a caso. Tenere a mente la differenza tra dig (parla direttamente col DNS) e getent (replica il percorso reale delle applicazioni) è probabilmente il singolo accorgimento che fa risparmiare più tempo in debug.

Fonte: Linux Nameservers and DNS Resolution — LinuxBlog.io

Linux nameservers and DNS Resolution | LinuxBlog.io

A practical guide to DNS resolution on Linux: how /etc/resolv.conf, systemd-resolved, and dig work together, and how to troubleshoot common nameserver failures.

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-08-14 07:34:51

WebMCP: come i siti web espongono strumenti agli agenti AI, spiegato con Cloudflare Browser Run

Il problema degli agenti AI che “guardano” il browser

Chi ha provato a far navigare un agente AI su un sito web sa quanto sia fragile il paradigma attuale: screenshot della pagina, analisi visiva per capire dove cliccare, simulazione del click, nuovo screenshot per verificare cosa è successo, e via così ad ogni passaggio. Funziona, ma è lento, costoso in token e si rompe alla prima modifica del layout o al primo elemento che carica in ritardo. È lo stesso problema che affligge da anni gli script di web scraping tradizionali, solo applicato ad agenti che devono anche “capire” cosa stanno guardando.

WebMCP (Web Model Context Protocol) nasce per rovesciare questo approccio: invece di far indovinare all’agente dove cliccare, è il sito stesso a dichiarare quali azioni sono disponibili, con che parametri, e come invocarle direttamente in codice. Cloudflare ha da poco reso disponibile il supporto sperimentale a WebMCP nella sua piattaforma Browser Run, un’occasione utile per capire come funziona davvero questo standard ancora in bozza.

Cos’è WebMCP e chi lo sta sviluppando

La proposta iniziale è stata pubblicata nell’agosto 2025 da ingegneri di Microsoft e Google, e oggi è portata avanti principalmente dal team Chrome come bozza sperimentale — non è ancora uno standard web consolidato, ma è già implementabile e testabile in Chrome beta. L’idea centrale è una nuova API del browser, navigator.modelContext, che qualsiasi pagina web può usare per registrare “tool” strutturati, nello stesso spirito del Model Context Protocol usato da Claude e altri assistenti per esporre funzionalità a un LLM — solo che qui il “server” MCP è JavaScript in esecuzione lato pagina, e l’host è il browser stesso.

navigator.modelContext.registerTool({
  name: "scroll_to_section",
  description: "Scorre la pagina fino a una sezione specifica",
  inputSchema: {
    type: "object",
    properties: { id: { type: "string" } },
    required: ["id"]
  },
  async execute({ id }) {
    document.getElementById(String(id))?.scrollIntoView({ behavior: "smooth" });
    return "ok";
  }
});

Un agente che visita la pagina può interrogare l’elenco dei tool disponibili in un dato momento — che cambia dinamicamente in base allo stato della pagina — ed eseguirli con parametri tipizzati, invece di simulare interazioni DOM.

Provarlo con Cloudflare Browser Run

Cloudflare ha aggiunto un pool sperimentale di sessioni browser con Chrome beta (dove WebMCP è disponibile) alla sua piattaforma Browser Run, separato dal pool di produzione che resta su Chrome stabile. Per avviare una sessione di test basta la CLI wrangler:

# assicurarsi di avere l'ultima versione di wrangler
npm i -g wrangler@latest

# creare una sessione browser "lab" con keep-alive di 5 minuti
wrangler browser create --lab --keepAlive 300

Dalla console DevTools della sessione si può interrogare direttamente l’elenco dei tool esposti da un sito che implementa WebMCP (Cloudflare fornisce come demo pubblica una finta catena di hotel):

navigator.modelContextTesting.listTools();
// [
//   { "name": "view_hotel", "description": "...", "inputSchema": "..." },
//   { "name": "search_location", "description": "...", "inputSchema": "..." },
//   { "name": "lookup_amenity", "description": "...", "inputSchema": "..." }
// ]

Eseguire un tool è altrettanto diretto:

await navigator.modelContextTesting.executeTool(
  "search_location",
  JSON.stringify({ query: "Paris" })
);

Un dettaglio interessante per chi progetta flussi che coinvolgono azioni sensibili (pagamenti, prenotazioni, conferme): la specifica prevede nativamente lo human-in-the-loop. Un tool come complete_booking può sospendere l’esecuzione in attesa che l’utente confermi manualmente un’azione nell’interfaccia, prima di restituire il risultato all’agente.

Collegare un agente AI reale

Per far interagire un vero agente con siti WebMCP, Cloudflare consiglia di appoggiarsi a Chrome DevTools MCP, configurabile in client come Claude Code o Cursor puntando al WebSocket endpoint della sessione lab:

{
  "browser-rendering-cdp": {
    "command": [
      "npx", "-y", "chrome-devtools-mcp@latest",
      "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/devtools/browser?keep_alive=600000&lab=true",
      "--wsHeaders={\"Authorization\":\"Bearer <CLOUDFLARE_API_TOKEN>\"}"
    ]
  }
}

Il parametro lab=true è ciò che instrada la connessione verso una sessione con WebMCP abilitato invece che verso il pool di produzione standard.

Il lato server: esporre i tool di un Worker al browser

Per chi già costruisce agenti su Cloudflare Workers usando McpAgent, il pacchetto agents include un adapter sperimentale, registerWebMcp, che fa da ponte tra i tool esposti da un server MCP remoto e il registro navigator.modelContext della pagina:

import { registerWebMcp } from "agents/experimental/webmcp";

const handle = await registerWebMcp({
  url: "/mcp",
  prefix: "remote.",
  getHeaders: async () => ({ Authorization: `Bearer ${await getToken()}` })
});

L’adapter scopre i tool del server (tools/list), li registra come shim locali il cui execute inoltra la chiamata al server via client.callTool(), e si mantiene sincronizzato ascoltando le notifiche tools/list_changed. Il risultato pratico è una separazione naturale: tutto ciò che riguarda il DOM (scorrimento, focus, clipboard, stato locale in Zustand o IndexedDB) resta tool in-page; tutto ciò che richiede storage durevole, credenziali segrete o chiamate a API di terze parti resta lato server, ma diventa comunque visibile e invocabile dall’AI del browser attraverso lo stesso registro.

Cosa considerare prima di adottarlo

Vale la pena essere chiari sulla maturità dello standard: le API navigator.modelContext e navigator.modelContextTesting funzionano oggi solo in sessioni Chrome beta o “lab”, non in produzione stabile, e sia la specifica sia l’adapter di Cloudflare sono etichettati esplicitamente come sperimentali, soggetti a modifiche non retrocompatibili. Sul fronte sicurezza, esporre tool strutturati a un agente terzo significa anche esporre una superficie potenzialmente sfruttabile — collisioni di nomi tra tool silenziose, o un agente compromesso che invoca un tool con parametri malevoli, sono scenari da considerare al pari di qualsiasi altra API pubblica. Per chi sviluppa siti pensati per essere “agent-friendly” — e-commerce, prenotazioni, dashboard SaaS — è comunque il momento giusto per iniziare a sperimentare, prima che il pattern diventi lo standard de facto per l’interazione tra agenti AI e web.

Conclusione

WebMCP propone un cambio di paradigma sensato: far dichiarare alle applicazioni web le proprie capacità in modo strutturato, invece di costringere gli agenti AI a reverse-engineering visivo dell’interfaccia. Non è ancora pronto per la produzione, ma la direzione — supportata sia da Google sia da Microsoft, e ora testabile concretamente su Cloudflare Browser Run — merita di essere seguita da chi sviluppa applicazioni web che prima o poi dovranno “parlare” anche con un agente, non solo con un umano davanti a un browser.

Fonte: Cloudflare Browser Run Docs – WebMCP e Cloudflare Agents – WebMCP adapter

WebMCP · Cloudflare Browser Run docs

Use WebMCP to let AI agents discover and execute structured tools exposed by websites, replacing fragile screenshot-analyze-click loops with direct function calls.

^{Cloudflare Docs}