Ciò che un jolly amplia deliberatamente
Un rapporto che il consumatore potrebbe essere disposto a ricevere DMARC report per qualsiasi dominio anziché pubblicare un proprietario di autorizzazione per ciascuna relazione. RFC 9990 consente esplicitamente un record DNS con caratteri jolly a tale scopo. Il suo esempio pone a registrazione TXT A *. _report._dmarc.example.com con almeno v=DMARC1. Si tratta di un ampio consenso da parte del dominio ricevente, non di un meccanismo che dimostri che ogni cliente segnalante è stato controllato.
La distinzione è operativamente importante. Un fornitore può legittimamente scegliere un’ampia assunzione richiedendo separatamente la verifica a livello di account prima di mostrare i dati a un cliente. Il record DNS non implementa tali controlli sull'account. Una revisione della sicurezza dovrebbe identificare esattamente quale limite viene modificato dal carattere jolly e quali limiti rimangono di responsabilità dell'applicazione ricevente e dei suoi proprietari. RFC 9990 , sezione 4
Mantieni le query esatte visibili sotto il carattere jolly
Il reporter costruisce ancora la ricerca dell'autorizzazione dal dominio in cui è stata recuperata la policy, _report. Etichette _dmarc e l'host di destinazione. Un carattere jolly è una strategia di pubblicazione DNS in grado di rispondere a tali domande; non elimina la necessità di comprendere il proprietario interrogato o il valore restituito. Conserva il proprietario esatto e la risposta quando verifichi una relazione particolare.
La risposta di conferma deve superare le regole di analisi della verifica esterna, incluso il primo v=DMARC1. Il valore della versione rimane DMARC1 con il caso richiesto. L'intenzione di un amministratore di utilizzare un carattere jolly non è una prova che una particolare query venga risolta come previsto nell'albero DNS distribuito. I record con il nome esatto e la struttura DNS possono influenzare la risoluzione reale, quindi i test proposti devono mantenere la risposta effettiva invece di presumere che uno screenshot dimostri la copertura. RFC 9990 , sezione 4; RFC 9989 , sezione 4.7
Autorizzazione di assunzione separata dalla proprietà e dall'accesso ai dati
Un carattere jolly indica che il dominio ricevente è disposto a ricevere i report coperti dall'accordo del protocollo. Non stabilisce che una persona che accede a una dashboard controlli il dominio indicato all'interno di un report. Inoltre, non stabilisce che il mittente di un elemento caricato sia affidabile o che un rapporto appartenga all'account che lo riceve.
Definisci separatamente i requisiti di accettazione a livello di applicazione: associazione dominio-tenant, accesso autenticato, tracciamento della provenienza, gestione dei duplicati e revisione dei domini imprevisti. Si tratta di controlli proposti, non di affermazioni su una piattaforma EmailAuth implementata. Un rapporto che menziona un'organizzazione non deve creare automaticamente una relazione di proprietà o esporre dati al primo account che rivendica il nome.
Mantieni la fatturazione, l'onboarding e l'autorizzazione dei dati fuori dall'inferenza DNS . Un'ampia disponibilità a ricevere traffico non significa consenso a iscrivere un'organizzazione a un servizio a pagamento o a pubblicare la configurazione osservata. Se un flusso di lavoro necessita di queste azioni, richiede decisioni e prove esplicite oltre il record con caratteri jolly. La revisione dovrebbe nominare il proprietario responsabile per ciascun confine anziché considerare un singolo risultato DNS come un'approvazione completa.
Tenere conto degli abusi e della pressione sulle risorse
RFC 9990 avverte che il contenuto del report può attaccare il decompressore o il parser XML e che i dati del report potrebbero essere contraffatti. Un servizio di accoglienza ampio dovrebbe quindi presupporre che il permesso di ricevere rapporti non rende ogni file in arrivo sicuro o accurato. La pianificazione della capacità, i limiti del parser e i controlli di provenienza fanno parte della progettazione dell'autorizzazione.
Proponi dimensioni limitate dei messaggi, limiti di dimensione decompressa, budget di tempo per l'analisi, isolamento delle code e avvisi per volumi di origine imprevisti. I valori numerici devono essere selezionati e testati per l'ambiente reale piuttosto che copiati da un limite universale inventato. Preservare le ragioni del rifiuto ed evitare che una fonte rumorosa oscuri prove del cliente non correlate. Nessuno di questi controlli viene dichiarato distribuito o testato qui. RFC 9990 , sezione 8.1 e 8.2
Autorizzazione al ritiro e alla memorizzazione nella cache
Un utente di report sopraffatto dal volume può rimuovere il record DNS di conferma, ma RFC 9990 rileva che la memorizzazione nella cache positiva può ritardare l'effetto fino al TTL del record. Non promettere l'immediata cessazione dei rapporti dopo una modifica DNS . I sistemi di assunzione potrebbero anche dover gestire i report già generati o in coda indipendentemente dal nuovo stato di ricerca.
Un piano di ritiro dovrebbe identificare il titolare del record, il percorso di approvazione, le prove TTL pertinenti, il comportamento di assunzione durante la transizione e le responsabilità di comunicazione. La rimozione di un carattere jolly può influire su molte relazioni legittime contemporaneamente. Una proposta di passaggio all'autorizzazione esplicita per dominio richiede un inventario di tali relazioni e un piano di verifica, non solo un record cancellazione.
Mantenere la distinzione tra revoca DNS e revoca dell'accesso all'applicazione. La rimozione dell'autorizzazione alla ricezione non comporta di per sé l'eliminazione dei report archiviati, la chiusura degli account cliente o la revoca delle sessioni utente esistenti. Si tratta di controlli separati con implicazioni di autorizzazione e conservazione separate. RFC 9990 , sezione 4
Revisione dei confini immaginari e progettazione dei test
Consideriamo un consumatore immaginario su reports.example.net che propone *. _report._dmarc.reports.example.net con il valore v=DMARC1; . Per una policy ipotetica su blue.example.com , la query esatta sarebbe blue.example.com._report._dmarc.reports.example.net . Per questo esempio non è stata eseguita alcuna query, pubblicazione o correzione DNS .
Il piano in caso positivo manterrebbe la query esatta e confermerebbe che il valore di autorizzazione restituito supera l'analisi. Il piano del caso negativo deve essere scelto con attenzione: un altro dominio di origine diretto alla stessa destinazione ampiamente autorizzata non è necessariamente non autorizzato, perché il carattere jolly copre intenzionalmente i domini di origine in generale. Invece, un host di destinazione controllato separatamente senza autorizzazione può illustrare il confine della destinazione esterna, a condizione che qualsiasi apparecchiatura effettiva sia autorizzata e isolata.
Il foglio di lavoro deve elencare il proprietario del carattere jolly, la copertura prevista, i proprietari esatti del test, le risposte, l'analisi della versione, il limite dell'host di destinazione e i controlli di accesso del tenant. Dovrebbe inoltre registrare il piano di ripristino e i limiti sull'elaborazione dei report. I risultati attesi sono ipotesi di progettazione fino all'esecuzione dei test limitati effettivi; non devono essere etichettati come superati semplicemente perché il ragionamento è plausibile.
Prove originali irrisolte e cancelli di rilascio
Il catalogo richiede l'esatta autorizzazione del titolare e la risposta, compreso un test positivo e un test di destinazione non autorizzata. Quelle osservazioni originali rimangono aperte. Questo manoscritto fornisce un progetto di test proposto e nomi fittizi, non una distribuzione di caratteri jolly funzionante o una valutazione dell'accesso all'account.
Prima della pubblicazione come guida operativa verificata, un revisore qualificato deve ispezionare le risposte DNS effettive e confermare che il test negativo supera effettivamente il limite di autorizzazione previsto. Le prove originali, la revisione umana, l'applicabilità della fonte, i percorsi di produzione, l'accessibilità visiva e il rilascio del proprietario rimangono aperti. Per questo lavoro non è stato eseguito alcun contatto esterno, caricamento di report o modifica DNS .