Scegli esplicitamente una popolazione collegata all'India
Uno studio sull'autenticazione dei domini in India dovrebbe specificare se si tratta di organizzazioni registrate in India, di un elenco settoriale, di istituzioni pubbliche, di domini con un particolare suffisso o di un'altra popolazione delimitata. Queste scelte possono produrre risultati diversi. L'etichetta di un paese non è giustificata semplicemente perché un dominio contiene il nome di una città indiana, utilizza un suffisso nazionale o serve clienti indiani. Lo studio necessita del mantenimento della provenienza della popolazione e di una mappatura trasparente dei domini che osserva.
Questo articolo propone un metodo e non contiene percentuali di adozione, classifiche o conclusioni sulla conformità. Nessun dominio è stato scansionato e nessun contatto organizzativo o dato privato è stato raccolto. Lo scopo è quello di rendere riproducibile uno studio futuro senza implicare che un comodo elenco web rappresenti ogni organizzazione indiana o ogni messaggio inviato dal paese.
Politica sui suffissi separata dall'idoneità organizzativa
IL Pagina delle politiche del Registro di sistema .IN distingue le zone libere dalle zone riservate alle organizzazioni qualificate. Le sue regole sullo spazio dei nomi dovrebbero essere lette nel loro ambito attuale, senza considerare l'appartenenza al suffisso come un censimento aziendale. Le politiche di denominazione di un registro di dominio descrivono lo spazio dei nomi che amministra. Non definiscono automaticamente un censimento delle imprese o di tutte le organizzazioni che inviano e-mail in India. Se lo studio utilizza un campione basato su suffisso, chiamarlo campione basato su suffisso e conservare l'ammissibilità e le fonti di selezione utilizzate. Se utilizza un'azienda, un'istruzione o una popolazione governativa, mantieni l'elenco autorevole pertinente e la sua copertura anziché sostituire l'appartenenza al suffisso del dominio.
Non affermare regole di ammissibilità legale a memoria. Il registro attuale o la documentazione governativa devono supportare qualsiasi affermazione di questo tipo e l'accesso mancato dovrebbe rimanere una limitazione della fonte. Un dominio può essere tecnicamente registrato senza che lo studio conosca il suo attuale ruolo operativo. Il metodo dovrebbe evitare di trasformare tale incertezza in una pretesa sullo status aziendale, sull’ubicazione nazionale o sulla conformità normativa.
Modella i confini delle entità prima della deduplicazione
Una singola organizzazione può avere un dominio aziendale, siti regionali, marchi di prodotti ed entità acquisite. Diverse filiali possono condividere un dominio mentre una filiale ne utilizza un altro. Decidere se l'unità è un'entità legale, un'istituzione, un marchio o un dominio e preservare le relazioni. La deduplicazione con un nome breve può unire entità non correlate; contare il sito web di ogni filiale può rappresentare in modo eccessivo una rete di grandi dimensioni.
Registrare gli identificatori della fonte e le date di validità, ove disponibili. Mantieni distinguibili le entità attive, rinominate, unite ed escluse. Lo studio dovrebbe spiegare se i domini storici rimangono nell’ambito e perché. Qui non è stato assemblato alcun set di dati di entità reali, quindi si tratta di requisiti di mappatura proposti piuttosto che di affermazioni verificate su una particolare organizzazione indiana.
Preservare nomi multilingue e internazionalizzati
Le fonti collegate all'India possono contenere diversi script e convenzioni di traslitterazione. Conserva i nomi originali e le traduzioni fornite dalla fonte senza trattarli automaticamente come entità separate. RFC 5890 definisce moduli di dominio internazionalizzati validi, mentre Norma tecnica Unicode 39 descrive l'analisi della confondibilità. Questi strumenti possono supportare la revisione della normalizzazione ma non possono stabilire l’identità organizzativa attraverso la somiglianza visiva.
Conserva il dominio non elaborato, il modulo DNS convalidato, il metodo di normalizzazione e la versione dello strumento. Uno scheletro utilizzato per il rilevamento confondibile è un artefatto di analisi, non il dominio su cui eseguire la query. Non penalizzare la denominazione internazionalizzata legittima trattando le etichette non ASCII come sospette o escludendole senza spiegazione. Se lo strumento di misurazione non è in grado di gestire un modulo supportato, segnalalo come limitazione dello strumento.
Mappa i domini web ufficiali con cautela
Per ciascuna entità, conserva la fonte che la collega al dominio selezionato e identifica se quel dominio è un sito web pubblico, un'identità di invio nota o entrambi. Non dedurre un patrimonio di posta completo da un collegamento a un sito Web. La posta dei dipendenti, le ricevute, i sondaggi e le notifiche in outsourcing possono utilizzare domini o sottodomini diversi. Sarebbe necessario un inventario interno autorizzato per avanzare affermazioni più ampie su tutti i flussi di lavoro di invio.
RFC 7208 valuta l'identità SMTP rilevante e RFC 9989 definisce DMARC allineamento e scoperta. Uno studio esclusivamente DNS dovrebbe quindi descrivere la pubblicazione delle policy nei domini mappati, non la conformità dell’autenticazione a livello di messaggio. Mantieni le identità di invio sconosciute come sconosciute anziché generare ipotesi che appaiono autorevoli nel set di dati.
Conserva i timestamp delle query e le versioni di implementazione
Definire i nomi esatti dei proprietari, i tipi di record, la configurazione del sistema di risoluzione, la finestra di osservazione, la pianificazione dei tentativi e la versione del parser prima della raccolta. Ad ogni timestamp appartiene un fuso orario; la sola data del calendario locale può nascondere osservazioni che abbracciano diversi periodi UTC. Conserva sia il timestamp originale che qualsiasi rappresentazione normalizzata. Se la raccolta richiede diversi giorni, segnala quella finestra anziché implicare un'unica istantanea simultanea.
RFC 1035 definisce la risposta DNS e le strutture dei record di risorse. Conservare record grezzi e codici di risposta in modo che un altro analista possa riprodurre la classificazione. Per DMARC , identificare la procedura di rilevamento implementata e conservarne il percorso. Un record mancante con un nome esatto non indica automaticamente l'assenza di una policy applicabile nell'ambito di un metodo di rilevamento supportato più ampio.
Mantieni le esclusioni verificabili
Crea categorie esplicite per mappatura di entità non risolta, rappresentazione di dominio non supportata, errore di nome, assenza di dati, timeout, errore del server e policy non valida. Registra la regola decidendo se ciascuno rimane al denominatore. Non rimuovere gli errori solo dopo aver ridotto il tasso di adozione. Se una query viene ritentata, conserva i tentativi e spiega quale risultato controlla la categoria finale.
Lo studio dovrebbe distinguere le esclusioni causate dall'ambito demografico dalle esclusioni causate da problemi di raccolta. Un'entità disciolta esclusa da una regola di popolazione predefinita è diversa da un'entità attiva la cui query DNS è scaduta. La combinazione di entrambi poiché non applicabile può nascondere errori di misurazione. Questa bozza non include conteggi o esclusioni perché non è stato eseguito alcun popolamento o esecuzione di query.
Un foglio di lavoro per lo studio dell'India
Crea campi per la domanda di ricerca, l'autorità della popolazione o la logica del campione limitato, la data di origine, l'identificatore dell'entità, il tipo di entità, i nomi originali, le prove del collegamento di dominio e le date di validità. Aggiungi dominio normalizzato, stato della mappatura, proprietario e tipo di query, tempo di osservazione, risolutore, versione del parser, risultato e motivo di esclusione. Conserva una tabella delle relazioni separata per domini condivisi, marchi e filiali dove il progetto lo richiede.
Prima di pubblicare un confronto, verifica che il denominatore della metrica sia stabile e che ciascun ambito geografico dichiarato corrisponda alla popolazione di origine. Un revisore indipendente dovrebbe riprodurre mappature e classificazioni selezionate dalle prove conservate. I dettagli di contatto personali e le credenziali dell'account non sono necessari per questo metodo di dominio pubblico e non devono essere aggiunti per rendere il set di dati più ricco.
Diagnosi fittizia: le filiali conteggiate come organizzazioni indipendenti
Un ricercatore immaginario combina un elenco di uffici regionali con un elenco di organizzazioni madri e conta ogni riga come un'entità indipendente. Molte righe puntano allo stesso dominio, quindi la configurazione di un'organizzazione riceve un peso sproporzionato. La revisione proposta separa le unità di sede, di unità madre e di dominio e riporta esplicitamente la ponderazione scelta.
Il team potrebbe pubblicare una visione ponderata per l'ufficio se questa è la domanda di ricerca effettiva, ma non dovrebbe chiamarlo tasso di adozione ponderato per l'organizzazione. Questo esempio è fittizio e non contiene alcuna istituzione indiana reale o percentuale misurata. Dimostra perché i confini delle entità devono essere mantenuti prima di riepilogare i risultati DNS .
Stato del rilascio
Il catalogo richiede la provenienza della popolazione, i confini delle entità, le esclusioni e i timestamp delle query. Questi artefatti originali rimangono aperti, così come la revisione specialistica umana, l'applicabilità della fonte, i percorsi di produzione, l'accessibilità e il rilascio del proprietario. Questa bozza fornisce un disegno di studio giurisdizionale distinto, non un set di dati eseguito sull’India o una valutazione di conformità. I risultati effettivi richiedono una popolazione autorizzata e conservata e osservazioni riproducibili con le limitazioni indicate.