{"id":19433,"date":"2026-05-17T11:50:17","date_gmt":"2026-05-17T09:50:17","guid":{"rendered":"https:\/\/webhosting.de\/dns-zone-transfer-security-axfr-protection-sicherheitsleitfaden\/"},"modified":"2026-05-17T11:50:17","modified_gmt":"2026-05-17T09:50:17","slug":"trasferimento-di-zone-dns-sicurezza-protezione-axfr-guida-alla-sicurezza","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/dns-zone-transfer-security-axfr-protection-sicherheitsleitfaden\/","title":{"rendered":"Trasferimenti di zone DNS e sicurezza: protezione contro gli abusi"},"content":{"rendered":"<p>Mostro come una zona dns con controllo <strong>AXFR<\/strong>- e i trasferimenti IXFR, le condivisioni IP e il TSIG rimangono protetti dallo spionaggio. Spiego anche i rischi dei trasferimenti aperti, i livelli di sicurezza praticabili, la configurazione rigida e <strong>Monitoraggio<\/strong> contro gli abusi.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>Per aiutarvi a rendere sicuri i trasferimenti di zone, vi riassumer\u00f2 in breve gli argomenti principali. Inizier\u00f2 con le basi delle zone e dei meccanismi di trasferimento, per poi passare direttamente alle implicazioni per la sicurezza. Vi mostrer\u00f2 quindi i passi pratici di hardening che funzionano in qualsiasi ambiente. Descrivo poi come riconoscere in modo affidabile le attivit\u00e0 sospette e reagire rapidamente. Infine, categorizzo l'argomento in processi di hosting e di team in modo che <strong>Operazione<\/strong> e sicurezza vanno di pari passo.<\/p>\n<ul>\n  <li><strong>AXFR\/IXFR<\/strong> Limitare in modo mirato<\/li>\n  <li><strong>TSIG<\/strong>-Utilizzare l'autenticazione in modo coerente<\/li>\n  <li><strong>IP<\/strong>-in base agli elenchi di permessi invece di \u201equalsiasi\u201c.\u201c<\/li>\n  <li><strong>Separazione<\/strong> zone interne ed esterne<\/li>\n  <li><strong>Monitoraggio<\/strong> e reazione<\/li>\n<\/ul>\n\n<h2>Zone DNS e trasferimento di zone spiegati brevemente<\/h2>\n<p>Una zona DNS raggruppa tutte le voci che controllano la risoluzione di un dominio, tra cui <strong>A<\/strong>-AAA, NS, MX e TXT. Mantengo questi dati su un server primario e li distribuisco ai secondari in modo che non ci siano lacune dovute a guasti. Il trasferimento mantiene sincronizzati diversi server autorevoli e garantisce tempi di risposta brevi in tutto il mondo. Senza questa replica, aumenta il rischio di risposte non aggiornate, con conseguenti interruzioni dei servizi di posta e web. Allo stesso tempo, una configurazione errata durante i trasferimenti apre superfici di attacco nel momento in cui terze parti accedono all'intero sistema. <strong>Zona<\/strong> sono autorizzati a leggere.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/dns-sicherheit-serverraum-4837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>AXFR e IXFR: differenze con conseguenze sulla sicurezza<\/h2>\n<p>L'AXFR trasmette l'intera zona in un'unica soluzione, formando cos\u00ec una zona completa. <strong>Immagine<\/strong> dell'infrastruttura. IXFR invia solo le modifiche rispetto all'ultima versione, risparmiando larghezza di banda e tempo. L'aspetto pi\u00f9 importante per la sicurezza \u00e8 chi \u00e8 autorizzato a inviare richieste, non quale tipo di richiesta viene trasmessa. Se si lasciano AXFR o IXFR aperti a qualsiasi mittente, chiunque pu\u00f2 vedere l'intera struttura. Per questo motivo mi affido ad autorizzazioni ristrette, definisco chiaramente i secondari e utilizzo ulteriori <strong>Esami<\/strong> ad ogni richiesta di informazioni.<\/p>\n\n<h2>Perch\u00e9 i trasferimenti in zona aperta sono rischiosi<\/h2>\n<p>Un trasferimento di zona completo rivela tutti i nomi di host, compresi eventuali sistemi di prova e di amministrazione, nonch\u00e9 sistemi esterni e interni. <strong>IP<\/strong>-Obiettivi. Questo fornisce agli aggressori un elenco compatto per scansioni sistematiche e campagne di phishing mirate. Vengono inoltre alla luce configurazioni errate, come le interfacce di gestione o gli endpoint VPN nella zona pubblica. Queste informazioni accelerano notevolmente il rilevamento nelle prime fasi di un attacco. Per evitare che ci\u00f2 accada, inchiodo i trasferimenti a partner noti e limito rigorosamente l'accesso. <strong>log<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/dns_sicherheit_meeting_9382.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Confronto tra i livelli di sicurezza per i trasferimenti di zona<\/h2>\n<p>Distinguo tre livelli di sicurezza, da utilizzare a seconda del rischio e dell'ambiente. I trasferimenti aperti a \u201equalsiasi\u201c sembrano comodi, ma forniscono immediatamente agli estranei una completa <strong>Elenco degli host<\/strong>. Le condivisioni verso host NS che sono mostrati nella zona sono migliori, ma queste informazioni sono visibili pubblicamente. Il modo pi\u00f9 sicuro di lavorare \u00e8 quello di utilizzare elenchi di indirizzi IP fissi per i secondari e un'autenticazione aggiuntiva. In questo modo si riduce notevolmente il rischio di interrogazioni non autorizzate e si protegge il sistema. <strong>Integrit\u00e0<\/strong> la vostra distribuzione.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Livello<\/th>\n      <th>Regola<\/th>\n      <th>Il rischio<\/th>\n      <th>Nota di attuazione<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Basso<\/td>\n      <td>Trasferimento per tutte le fonti<\/td>\n      <td>Divulgazione completa della zona<\/td>\n      <td>Assicurarsi di spegnere e <strong>Elenco dei permessi<\/strong> set<\/td>\n    <\/tr>\n    <tr>\n      <td>Medio<\/td>\n      <td>Solo gli host NS della zona<\/td>\n      <td>La restrizione esiste, ma pu\u00f2 essere derivata pubblicamente<\/td>\n      <td>Meglio solido <strong>IP<\/strong> e introdurre TSIG<\/td>\n    <\/tr>\n    <tr>\n      <td>Alto<\/td>\n      <td>IP fissi + TSIG<\/td>\n      <td>Superficie di attacco significativamente ridotta<\/td>\n      <td>Eseguire regolarmente test e <strong>ruotare<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Ho sempre orientato lo stato dell'obiettivo verso il livello alto, soprattutto nelle zone aziendali. Autorizzazioni rigorose e firme crittografiche creano un controllo affidabile. Inoltre, controllo regolarmente i registri del server e imposto avvisi per le richieste insolite. Documento chiaramente ogni modifica alle zone o agli IP secondari. In questo modo garantisco che lo stato rimanga riproducibile e <strong>testabile<\/strong>.<\/p>\n\n<h2>Limitare rigorosamente l'accesso: la configurazione in pratica<\/h2>\n<p>Consento solo i trasferimenti verso IP secondari definiti con precisione e rifiuto qualsiasi altra fonte. In BIND utilizzo allow-transfer e ACL, in Windows DNS le propriet\u00e0 della zona con quote IP specifiche. PowerDNS e Unbound offrono direttive simili, che definisco chiaramente per ogni istanza. Se state pianificando una nuova infrastruttura, \u00e8 meglio leggere brevemente su <a href=\"https:\/\/webhosting.de\/it\/configurare-il-proprio-nameserver-zone-dns-record-di-dominio-colla-guida-power\/\">Impostare il proprio server dei nomi<\/a> e definire regole rigorose fin dall'inizio. In questo modo si evitano le impostazioni predefinite, comode ma insicure, e si mette in sicurezza il sistema. <strong>Trasferimento<\/strong> sostenibile.<\/p>\n<p>Verifico l'effetto di ogni regola con un test AXFR mirato da una fonte non autorizzata. Se questo fallisce, il blocco funziona e registro la configurazione. Quando sposto i secondari, prima di cambiare il ruolo regolo l'allowlist. In questo modo evito l'effetto finestra, in cui pi\u00f9 fonti avrebbero accesso per un breve periodo. Questa sequenza rende le modifiche calcolabili e <strong>controllabile<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/dns-security-zone-transfer-3478.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utilizzare e gestire correttamente i TSIG<\/h2>\n<p>TSIG integra il filtraggio IP con una firma crittografica per ogni richiesta e risposta. Il primario e il secondario condividono una chiave segreta, il che significa che solo i partner legittimi effettuano trasferimenti validi. Assegno una chiave separata per ogni coppia di partner e la conservo rigorosamente separata dalle altre chiavi. <strong>I segreti<\/strong>. La chiave non deve essere inserita nel sistema di controllo delle versioni, ma deve essere conservata in un archivio segreto sicuro. Documento anche ogni distribuzione, in modo che i revisori possano tracciare il flusso di trasferimenti e di <strong>controllo<\/strong> pu\u00f2.<\/p>\n<h3>Manutenzione e rotazione delle chiavi<\/h3>\n<p>Ruoto regolarmente le chiavi TSIG e organizzo finestre temporali fisse per lo scambio. Prima del cambio, attivo temporaneamente entrambe le chiavi in modo che non ci siano interruzioni nel trasferimento. Dopo l'avvenuta sincronizzazione, rimuovo la vecchia chiave da tutti i sistemi. Poi controllo i registri per assicurarmi che appaia solo la nuova chiave. In questo modo, riduco al minimo il rischio di chiavi obsolete e proteggo il sistema. <strong>Autenticit\u00e0<\/strong> il trasferimento.<\/p>\n\n<h2>Selezione dell'algoritmo, sincronizzazione temporale e dettagli della piattaforma<\/h2>\n<p>Uso algoritmi HMAC moderni (ad esempio hmac-sha256) per TSIG ed evito varianti obsolete. \u00c8 importante una sincronizzazione temporale affidabile tramite NTP: TSIG convalida le richieste entro una finestra temporale ristretta; scostamenti temporali maggiori portano al rifiuto. In BIND, definisco chiaramente le chiavi e le assegnazioni per partner, in Windows DNS verifico se i trasferimenti da zona a zona sono protetti con TSIG o, negli ambienti AD, con GSS-TSIG. GSS-TSIG utilizza le identit\u00e0 Kerberos e si adatta perfettamente ai domini con deleghe basate sui ruoli. Mantengo chiavi o account separati per zona e secondario per limitare rigorosamente l'impatto di un segreto compromesso.<\/p>\n<p>Non dimentico nemmeno IPv6: l'elenco dei permessi include gli indirizzi v4 e v6 dei secondari. Se i secondari sono dietro NAT, mi accordo su indirizzi di uscita stabili e documentati; gli IP di origine dinamici sono tab\u00f9 per i trasferimenti. Negli ambienti multi-cloud, definisco con precisione le reti consentite per ogni provider e verifico ogni percorso con una firma.<\/p>\n\n<h2>Ridurre al minimo l'AXFR<\/h2>\n<p>AXFR fornisce sempre la zona completa, che nella pratica utilizzo il meno possibile. Uso IXFR per le modifiche quotidiane, evitando cos\u00ec grandi trasferimenti di dati. Inizialmente, quando creo un nuovo secondario, permetto ad AXFR di essere usato una sola volta, dopodich\u00e9 <strong>Sincronizzazione<\/strong>. Se c'\u00e8 un numero insolitamente alto di fotogrammi pieni, verifico se un secondario si riavvia continuamente o perde contatori. In questo modo trovo le cause tecniche e mantengo basso il numero di fotogrammi pieni sensibili nella zona, riducendo cos\u00ec al minimo i problemi di sicurezza. <strong>esposizione<\/strong> ridotto.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/dns_zone_security_nacht1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NOTIFY, seriali SOA e garanzia di coerenza<\/h2>\n<p>Controllo i trasferimenti in modo proattivo con NOTIFY e seriali SOA puliti. Dopo i cambi di zona, il primario invia NOTIFY ai secondari autorizzati (senza trasmissioni), che poi si aggiornano tramite IXFR. Uso allow-notify\/also-notify per limitare esattamente chi \u00e8 autorizzato a inviare o ricevere segnali, in modo che nessuna fonte esterna attivi gli aggiornamenti. Mantengo il seriale SOA deterministico (ad esempio, yyyymmddnn) in modo che le repliche siano uniche e sia pi\u00f9 facile riconoscere le derive. Se si perdono degli incrementi, attivo specificamente una risincronizzazione e verifico se \u00e8 stato effettivamente utilizzato IXFR invece di AXFR.<\/p>\n<p>Per le linee stesse, proteggo solo TCP\/53 verso i secondari, perch\u00e9 AXFR\/IXFR funzionano via TCP. Nei firewall, imposto regole rigide per ogni direzione, eventualmente con limiti di velocit\u00e0 per le configurazioni delle connessioni. Se si desidera la riservatezza anche sul percorso di trasporto, si pu\u00f2 prendere in considerazione XFR-over-TLS (XoT), a condizione che entrambe le parti lo supportino; in tal caso proteggo l'identit\u00e0 con ancore di fiducia chiare come con TSIG.<\/p>\n\n<h2>Separare in modo netto le zone interne da quelle esterne<\/h2>\n<p>Mantengo costantemente i sistemi interni in zone DNS private e pubblico all'esterno solo ci\u00f2 di cui i servizi hanno realmente bisogno. <strong>necessit\u00e0<\/strong>. Gli host di test e di amministrazione non appartengono al DNS pubblico e quindi non appaiono in nessun trasferimento di zona. Utilizzo anche il protocollo DNSSEC per l'integrit\u00e0 e l'autenticit\u00e0 delle risposte, sapendo che il protocollo DNSSEC non protegge dai trasferimenti non autorizzati. Se volete saperne di pi\u00f9 su questo argomento, potete trovare maggiori informazioni nella guida compatta a <a href=\"https:\/\/webhosting.de\/it\/dnssec-firma-gestione-delle-chiavi-sicurezza-del-dominio-sicurezza-della-rotazione\/\">Firma DNSSEC<\/a> consigli utili sulla firma e sulla manutenzione delle chiavi. Questa separazione riduce i rischi, aumenta l'igiene dei dati e mantiene il pubblico in contatto con le persone. <strong>Superficie di attacco<\/strong> piccolo.<\/p>\n\n<h2>Architettura: primario nascosto e secondari anycast<\/h2>\n<p>Se possibile, posiziono il primario come \u201eprimario nascosto\u201c dietro i firewall ed espongo solo i secondari come NS della zona. I secondari possono utilizzare anycast per rispondere rapidamente in tutto il mondo, mentre il primario accetta solo percorsi di gestione definiti. I trasferimenti vengono eseguiti solo tra il primario nascosto e i secondari, rigorosamente tramite Allowlist e TSIG. Nelle configurazioni multi-sito, ancoro almeno due secondari per regione e monitoro attivamente il percorso di trasferimento. In questo modo il canale di amministrazione rimane stretto, il percorso di risposta \u00e8 efficiente e gli aggressori non vedono mai direttamente il primario.<\/p>\n<p>Utile anche la separazione dei ruoli per le fonti di aggiornamento (ad es. firmatario, costruttore di zone) e per gli endpoint di trasferimento. Automatizzo la pipeline in modo che solo gli stati delle zone verificati e firmati raggiungano il primario e solo allora inizia la replica. In questo modo, le configurazioni errate vengono individuate tempestivamente e non vengono distribuite su tutto il territorio.<\/p>\n\n<h2>Monitoraggio, registrazione e risposta rapida<\/h2>\n<p>Analizzo i log del server per individuare tentativi sospetti di AXFR e IXFR e imposto allarmi con soglie chiare. Sorgenti inaspettate, frequenti tentativi falliti o trasferimenti completi al di fuori delle finestre di modifica indicano problemi. I controlli strutturati, come descritto nella panoramica, aiutano ad analizzare le cause. <a href=\"https:\/\/webhosting.de\/it\/riconoscere-le-misconfigurazioni-dns-strumenti-di-analisi-degli-errori-suggerimenti-per-i-dns\/\">Configurazioni DNS errate<\/a> sono descritti. Se rilevo un incidente, blocco immediatamente i trasferimenti verso l'elenco dei permessi noti e controllo le voci pubbliche per verificare la presenza di contenuti superflui. In seguito, indurisco gli host esposti, applico le patch e rendo pi\u00f9 rigorosa la <strong>Processi<\/strong> per le modifiche future.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/dns-security-devdesk-4312.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limitazione della velocit\u00e0 e controlli di rete<\/h2>\n<p>Oltre ai filtri per le applicazioni, utilizzo la protezione di rete: limiti di velocit\u00e0 TCP sulla porta 53, protezione contro i SYN flood e quote di connessione per i trasferimenti simultanei. In BIND e PowerDNS, limito il numero di XFR che possono essere eseguiti in parallelo, in modo che un uso improprio non blocchi altre zone. Abilito la limitazione della velocit\u00e0 di risposta (RRL) per le risposte autoritative, anche se non limita i trasferimenti stessi, in modo da ridurre l'abuso simultaneo. Sui firewall e sui bilanciatori di carico, creo regole esplicite per secondario con registrazione degli eventi di caduta. Questo mi permette di riconoscere tempestivamente gli schemi pi\u00f9 evidenti e di adottare contromisure mirate.<\/p>\n<p>Utilizzo categorie chiaramente separate per la registrazione (ad esempio, xfer-in\/xfer-out, notifica, sicurezza). Metriche come il tempo di convergenza, il numero di NOTIFICHE fallite, il rapporto IXFR\/AXFR e la dimensione media dei trasferimenti confluiscono nei dashboard. I valori limite sono derivati dalle normali finestre di modifica; le deviazioni vengono attivate come ticket o avvisi via cercapersone.<\/p>\n\n<h2>DNS nel contesto di hosting: verifica del fornitore<\/h2>\n<p>Per quanto riguarda le offerte di hosting, verifico se il provider fornisce filtri di trasferimento granulari, TSIG e registri puliti. Sono importanti anche server autoritari distribuiti e ridondanti e una chiara separazione dai resolver. Presto attenzione alla semplice integrazione nell'automazione, in modo che le modifiche possano essere implementate in modo riproducibile e sicuro. DNSSEC, CAA, SPF e DMARC, che voglio attivare e mantenere senza deviazioni, sono altrettanto importanti. Un fornitore che copre questi punti rende il <strong>Operazione<\/strong> e riduce in modo permanente i rischi per la sicurezza.<\/p>\n\n<h2>Automazione, zone catalogo e disciplina del cambiamento<\/h2>\n<p>Gestisco i secondari in modo programmatico, ad esempio tramite zone di catalogo o modelli IaC. Questo mi permette di mantenere gli elenchi dei partner autorizzati al trasferimento coerenti tra le varie istanze. Ogni modifica viene sottoposta allo stesso processo di revisione del codice: principio dei quattro occhi, test in staging, quindi rollout. Le chiavi TSIG finiscono in un archivio segreto; le distribuzioni le inseriscono in fase di esecuzione senza diffonderle nel file system. Documento le modifiche degli IP secondari, le convenzioni sui numeri di serie e le procedure di emergenza nello stesso repository delle sorgenti di zona, in modo che siano tracciabili e a prova di audit.<\/p>\n<p>Per i backup, salvo gli stati e le configurazioni delle zone in forma crittografata. Dopo i ripristini, verifico che non siano state ripristinate le azioni \u201equalsiasi\u201c o le impostazioni predefinite. Eseguo il backup delle zone del catalogo allo stesso modo delle zone produttive, perch\u00e9 chiunque possa leggerle riconoscer\u00e0 la struttura interna della vostra configurazione DNS.<\/p>\n\n<h2>Errori tipici e come evitarli<\/h2>\n<p>Un errore comune \u00e8 una condivisione di trasferimento aperta \u201equalsiasi\u201c, che sostituisco costantemente con elenchi IP fissi. Altrettanto critiche sono le chiavi TSIG obsolete, che vengono mitigate con una rotazione regolare e una documentazione chiara. I problemi sorgono anche quando i sistemi interni scivolano inavvertitamente nelle zone pubbliche, cosa che prevengo attraverso una rigorosa separazione e controlli ricorrenti. La mancanza di avvisi significa anche che si notano solo in ritardo le fuoriuscite inosservate; per questo motivo imposto notifiche basate su soglie. Infine, sono attento alla sicurezza delle revisioni: registro ogni modifica delle regole, la verifico attivamente e confermo le modifiche. <strong>Effetto<\/strong> con controlli incrociati.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/dns-sicherheit-rechenzentrum-8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Test e verifiche: Runbook e strumenti<\/h2>\n<p>Ho pronta una breve lista di controllo per convalidare regolarmente la sicurezza:<\/p>\n<ul>\n  <li>Da una fonte straniera: <code>dig AXFR deinezone.tld @ns1.deinedomain.tld +tcp<\/code> - Aspettativa: trasferimento fallito.<\/li>\n  <li>Con TSIG da fonte autorizzata: <code>dig AXFR deinezone.tld @secondary.example +tcp -y keyname:BASE64SECRET<\/code> - Aspettativa: trasferimento riuscito e firmato.<\/li>\n  <li>Test del percorso NOTIFICA: <code>rndc notify deinezone.tld<\/code> e controllare i registri per i NOTIFY accettati.<\/li>\n  <li>Forza IXFR: <code>rndc ritrasferimento deinezone.tld<\/code> e garantire che non si verifichi alcun AXFR finch\u00e9 la cronologia \u00e8 disponibile.<\/li>\n  <li>Controllare la configurazione: <code>named-checkconf<\/code> e <code>nome-checkzone<\/code> prima di ogni lancio.<\/li>\n<\/ul>\n<p>Registro i risultati, archivio i relativi estratti di registro e li confronto con gli elenchi di autorizzazioni definiti. In sede di audit, posso dimostrare che le fonti non autorizzate non hanno accesso e che i trasferimenti avvengono solo attraverso canali firmati e approvati. In questo modo il controllo \u00e8 misurabile, non solo presunto.<\/p>\n\n<h2>Sommario: Come mantenere sicuro il trasferimento di zona<\/h2>\n<p>Limito rigorosamente i trasferimenti alle societ\u00e0 secondarie autorizzate, set <strong>TSIG<\/strong> e registrare ogni modifica. Inizialmente ho bisogno solo di trasferimenti completi, poi lavoro in modo incrementale e mantengo le immagini complete sensibili al minimo. Separo chiaramente le zone interne da quelle esterne, in modo che i sistemi riservati non compaiano mai nei record di dati pubblici. Un monitoraggio affidabile mi permette di riconoscere rapidamente le anomalie e di reagire immediatamente. In questo modo, la zona DNS rimane trasparente per le operazioni, ma opaca per gli aggressori, e la zona DNS rimane trasparente per gli aggressori. <strong>Protezione<\/strong> ha effetto nei punti cruciali.<\/p>","protected":false},"excerpt":{"rendered":"<p>Imparate a prevenire i trasferimenti di zona aperti e a proteggere in modo professionale la vostra infrastruttura DNS con una sofisticata sicurezza del trasferimento di zona dns e un'efficace protezione axfr.<\/p>","protected":false},"author":1,"featured_media":19426,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-19433","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"67","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"dns zone","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19426","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19433","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=19433"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19433\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/19426"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=19433"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=19433"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=19433"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}