Definire la distribuzione come proprietà DNS osservabile
Uno studio sulla distribuzione DNS può stabilire che un particolare record è stato osservato con un particolare nome e orario del proprietario. Da solo, non può stabilire che ogni messaggio proveniente dall'organizzazione sia autenticato, che i destinatari abbiano applicato la stessa politica o che una richiesta commerciale fosse legittima. Lo studio dovrebbe definire le sue proprietà misurate prima di raccogliere i dati: la presenza dei record, la validità sintattica, la scoperta delle politiche applicabili e la conformità dei messaggi operativi sono risultati diversi.
RFC 1035 definisce le strutture dei messaggi e dei record DNS . RFC 9989 definisce DMARC scoperta e allineamento comportamento. Questi standard supportano un metodo di misurazione riproducibile, non l'affermazione che è stata eseguita una scansione. Questo manoscritto non contiene osservazioni di dominio, percentuali di adozione o risultati di messaggi dedotti.
Scegli l'unità e la popolazione prima di eseguire la query
Specificare se lo studio conta domini registrati, nomi completi, identità di invio o organizzazioni clienti. Tali unità non sono intercambiabili. Un'organizzazione può gestire più domini, mentre un dominio può ospitare diversi flussi di lavoro di invio indipendenti. Un elenco di nomi di siti Web non è automaticamente un elenco di domini che inviano posta. Registrare come è stato selezionato il campione e cosa esclude la selezione.
Blocca l'elenco di input con un identificatore di versione e un hash conservato. Definisci la gestione di duplicati, nomi internazionalizzati, punti finali, alias e cambiamenti di proprietà o stato. Non rimuovere silenziosamente i nomi difficili dopo aver visto i risultati. Se la popolazione è un campione di convenienza, descrivila in questo modo anziché presentarla come rappresentativa di tutti i domini di posta elettronica. Nessun elenco della popolazione è stato creato o interrogato per questa bozza.
Distinguere l'osservazione del nome esatto dalla scoperta
Una ricerca TXT esatta risponde a una domanda più ristretta rispetto alla determinazione di una policy DMARC applicabile. Sotto RFC 9989, il processo di scoperta può comportare a Passeggiata sull'albero DNS. Un metodo che interroga solo un nome del proprietario previsto dovrebbe etichettare il risultato con la presenza del nome esatto, non completare la distribuzione DMARC . Conservare l'algoritmo e la versione standard utilizzati in modo che un altro analista possa comprendere cosa significa un risultato negativo.
SPF ha la propria identità e regole di selezione dei record in RFC 7208. La ricerca di una politica nel dominio di un sito Web non dimostra che sia quella MAIL DA identità utilizzata dai messaggi dell'organizzazione. Uno studio basato solo sul DNS può descrivere la pubblicazione con nomi selezionati, ma non deve inventare identità di invio o sostituire nomi di marchi per il contesto SMTP osservato.
Conservare separatamente le prove autorevoli e ricorsive
Per ogni osservazione autorizzata, registrare l'esatto proprietario, tipo, classe, server o risolutore, ora e stato della risposta. Le risposte autorevoli descrivono la risposta dell'autorità interpellata; le risposte ricorsive possono riflettere i dati memorizzati nella cache e l'elaborazione propria del risolutore. Se vengono raccolti entrambi, conservarli entrambi anziché selezionare la risposta che si adatta al risultato atteso. Il loro disaccordo può essere analiticamente importante.
Documentare il modo in cui vengono rilevati i server autorevoli e il modo in cui il metodo gestisce le risposte incoerenti tra di essi. Registrare eventuali errori nel percorso di scoperta anziché etichettarli come assenza della politica finale. Un TTL ricorsivo può riflettere la durata rimanente della cache, pertanto non deve essere segnalato come TTL configurato originale senza prove. Lo studio dovrebbe preservare le trascrizioni grezze insieme ai campi normalizzati per supportare la revisione successiva.
Conserva i limiti dei record e le categorie di errore
TXT RDATA può contenere più stringhe di caratteri all'interno di un record. Ciò differisce da diversi record di risorse TXT dello stesso proprietario. Un parser di misurazione dovrebbe preservare tali limiti prima di applicare la selezione specifica del protocollo. I dati TXT non correlati possono coesistere con i record di autenticazione; non dovrebbe gonfiare il conteggio delle politiche o confluire in un'asserzione dall'aspetto valido.
Distinguere l'errore del nome, una risposta riuscita senza dati richiesti, errore del server, timeout, sintassi non valida e record pertinenti ambigui. Queste categorie non dovrebbero diventare tutte una distribuzione mancante. La tabella dei risultati dovrebbe conservare la risposta originale e la regola utilizzata per assegnare una categoria. Se il metodo riprova, predefinire la pianificazione dei tentativi e la classificazione finale in modo che gli errori temporanei non vengano gestiti in modo diverso a seconda del risultato desiderato.
Mantenere le prove DNSSEC nel proprio campo
RFC 4033 distingue stati di convalida sicuri, insicuri, fasulli e indeterminati. Un record può essere presente senza una catena convalidata in modo sicuro. Un errore di convalida può anche impedire a un risolutore di restituire dati utilizzabili. Se lo studio misura DNSSEC, deve documentare il contesto di trust-anchor e risolutore anziché presupporre che qualsiasi record visibile sia autenticato.
Non rendere lo stato DNSSEC un'esclusione nascosta che modifica il denominatore del campione. Riportare quanti nomi sono stati valutati, quali stati sono stati osservati e quali non è stato possibile determinarli, utilizzando le prove effettive raccolte. Questa bozza non contiene tali conteggi. Lo scopo del metodo è preservare l’incertezza, non trasformare i dati non disponibili in un risultato di implementazione conveniente.
Pubblicazione separata dalla conformità a livello di messaggio
Una policy SPF pubblicata non mostra quale indirizzo IP ha inviato un messaggio reale. UN DKIM key non mostra che un provider abbia firmato un particolare messaggio o abbia conservato in modo sicuro la chiave privata corrispondente. Una policy DMARC non dimostra che ogni flusso legittimo sia allineato. Tali domande richiedono prove operative dal percorso effettivo e un ricevitore fidato.
RFC 8601 spiega il confine di fiducia per Authentication-Results. Un campione di messaggi ricevuti corrispondente può supportare un'osservazione mirata a livello di messaggio, ma non convalida automaticamente ogni dominio o flusso di lavoro in uno studio DNS . Mantieni le metriche di pubblicazione e le metriche dei messaggi come misure separate con popolazioni e limitazioni proprie. Non rietichettare una percentuale di adozione DNS come conformità o protezione raggiunta.
Un foglio di lavoro di osservazione riproducibile
Crea un foglio di lavoro con versione di esempio, unità di dominio, input normalizzato, proprietario esatto della query, tipo di record, metodo di query, tempo di osservazione, trascrizione autorevole, trascrizione ricorsiva e versione del parser. Aggiungere la categoria di risultati assegnata, il percorso di rilevamento delle policy applicabili, lo stato DNSSEC laddove valutato e una spiegazione degli errori. Mantenere un collegamento alle prove grezze piuttosto che solo alla classificazione finale.
La specifica dell'analisi dovrebbe indicare il numeratore e il denominatore per ciascuna metrica. La presenza tra tutti i nomi tentati, la validità tra i nomi con risposte e la copertura delle politiche applicabili sono frazioni diverse. Se diversi sono utili, segnalateli separatamente. Definire le esclusioni prima dell'analisi e conservare un registro delle esclusioni con i motivi. In questo manoscritto non vengono forniti input originali, trascrizioni di query o risultati di misurazioni.
Diagnosi fittizia: una tabella di distribuzione diventa una richiesta di conformità
Un analista immaginario interroga un elenco di domini di siti Web aziendali e trova in alcuni di essi dati TXT dall'aspetto politico. Una presentazione etichetta il risultato della conformità dell'autenticazione e-mail. La revisione proposta identifica due lacune: il campione non stabilisce le effettive identità di invio e la presenza del record non stabilisce l'autenticazione a livello di messaggio. Il grafico dovrebbe essere rinominato per descrivere la proprietà DNS osservata e il relativo campione.
Uno studio autorizzato successivo potrebbe aggiungere inventari dei mittenti e prove dei messaggi ricevuti, ma avrebbe bisogno di una nuova definizione di metrica anziché aggiornare silenziosamente l’affermazione originale. Questo esempio non contiene domini, conteggi o scansioni reali. Illustra un errore di reporting in un metodo ipotetico, non un risultato su un'organizzazione o uno studio di distribuzione completato.
Rilasciare il metodo con i suoi limiti di evidenza
Una conclusione utile dello studio indica la popolazione, le date di osservazione, l'algoritmo di query, le categorie di risultati e ciò che le prove non possono stabilire. Evita reclami sul comportamento universale del destinatario, sulla consegna della posta in arrivo o sulla prevenzione di frodi. Una misurazione DNS trasparente resta preziosa proprio perché la sua portata è chiara.
Il catalogo richiede risposte autorevoli e ricorsive con timestamp con nomi esatti dei proprietari e tipi di record. Quelle trascrizioni originali rimangono aperte. Rimangono aperti anche la revisione da parte di specialisti umani, l’applicabilità della fonte, i percorsi di produzione, l’accessibilità e il rilascio del proprietario. Questa bozza è un metodo di misurazione proposto, non una scansione eseguita o un risultato di conformità del messaggio.