L'esistenza appartiene al dominio, non a un tipo di record
Il tag np fornisce a DMARC politica di valutazione per sottodomini inesistenti secondo la politica rilevata applicabile. È utile solo quando la decisione di esistere è solida. "NO Un record,” “nessun DMARC registrazione TXT" e "il dominio dell'autore non esiste" sono affermazioni diverse. Trattarle come sinonimi può applicare la politica sbagliata a un dominio reale o nascondere un'interruzione della risoluzione dietro una risposta falsa negativa.
RFC 9989 sezione 4.7 distingue np da sp. Il primo si rivolge a sottodomini inesistenti; quest'ultimo si rivolge ai sottodomini esistenti. Nessuno dei due sostituisce la determinazione di quale record di polizza si applica. La policy valida del dominio autore ha la priorità e il suo tag p viene utilizzato per quel dominio. I calcoli della policy principale vengono effettuati successivamente, quando il dominio dell'autore non ha una propria policy applicabile.
Specifica il genitore e mantieni gli esempi fittizi
Usa north.example come inventato dominio organizzativo con questa policy: v=DMARC1;p=none; sp=quarantine; np=reject; psd=n. Supponiamo che ogni caso seguente utilizzi un messaggio altrimenti valido la cui autenticazione non produce un passaggio allineato. Si tratta di documenti con risultati derivati manualmente, non di osservazioni DNS , tentativi di consegna o dichiarazioni sui record di qualsiasi organizzazione.
Per live.north.example , stipulare un record di indirizzo e nessuna politica DMARC propria. La scoperta raggiunge il confine genitore e l'esistenza viene stabilita. La valutazione richiesta proviene da sp=quarantine. Il p=none del genitore non sostituisce la preferenza più specifica del sottodominio esistente. Conserva il tag selezionato nel risultato in modo che un revisore possa capire perché è stata scelta la quarantena.
Per empty.north.example , stipulare an Record MX ma nessun record. La risposta NOERROR/ NODATA autorevole di una query è compatibile con quel nome esistente. Senza una politica DMARC propria, si applica ancora sp=quarantine . Questo caso separa deliberatamente un tipo di record mancante da un dominio mancante; una pedina che lo etichetta come inesistente semplicemente perché ha chiesto solo A fallirebbe la decisione attesa.
Interpreta NXDOMAIN con il nome giusto
Per gone.north.example , stipula una risposta NXDOMAIN autorevole per il dominio dell'autore stesso, senza una catena di alias e nessuna policy propria. La policy principale selezionata utilizza np=reject. RFC 9989 Appendice A.4 spiega che l'esistenza DMARC non richiede un particolare tipo di record relativo alla posta. La sua definizione segue l'esistenza DNS piuttosto che il concetto più ristretto di SMTP di destinazione risolvibile.
Una risposta NXDOMAIN per _dmarc.live.north.example negherebbe il nome del figlio richiesto, non dimostrerebbe che live.north.example è assente. La direzione dell'inferenza è importante. RFC 8020 spiega che anche un nome negato non ha discendenti; non dice che il rifiuto di un figlio cancella il suo genitore. L'elaborazione dell'alias può anche rendere il nome rifiutato diverso dalla domanda originale, quindi conservare il nome effettivo la cui esistenza è stata negata.
Un non terminale vuoto è un altro caso limite utile: un nodo può esistere nella gerarchia DNS perché ha discendenti anche quando non ha record propri. Non comprimere quell'esistenza strutturale in NXDOMAIN . Il progettista dell'apparecchiatura dovrebbe specificare l'albero, non semplicemente una comoda etichetta di testo allegata a una risposta vuota.
Ispezionare NODATA e gli errori di risoluzione separatamente
NODATA non è un codice di risposta DNS indipendente. RFC 2308 sezione 2.2 descrive una classificazione di risposta negativa che necessita di un contesto di risposta. Una sezione Risposta vuota può accompagnare un rinvio e gli alias possono influenzare il nome e il tipo effettivamente risolti. Salvare la domanda, il codice di risposta, la catena di alias e le informazioni sull'autorità prima di trarre una conclusione sull'esistenza.
SERVFAIL , timeout e una risposta incompleta non sono prova di inesistenza. RFC 1035 sezione 4.1.1 distingue l'errore del server dall'errore del nome. Nel caso immaginario broken.north.example , SERVFAIL lascia l'esistenza irrisolta; non seleziona np da solo. RFC 9989 la sezione 4.10.1 lascia la gestione degli errori DNS alla discrezione del destinatario, incluso il possibile differimento temporaneo. Un valutatore deve mantenere questo stato irrisolto invece di richiedere una normale ricerca negativa.
Applicare deliberatamente la precedenza e il fallback delle policy
Ora fornisci a own.north.example un v=DMARC1; p=none policy con il nome esatto _dmarc . Il suo stesso valore p fornisce la valutazione; le preferenze np e sp del genitore non lo sostituiscono. Questa è una regola di policy discovery, non un’eccezione inventata per i domini figli permissivi. La configurazione secondaria esistente necessita ancora di un proprietario autorizzato e di una revisione della sicurezza motivata.
Se np è assente dal record principale selezionato, il suo valore predefinito nella sezione 4.7 è sp quando sp esiste, altrimenti p. Per il genitore di esempio, la rimozione di np mette in quarantena la valutazione del sottodominio inesistente. Rimuovendo sia np che sp non ne rimane nessuno. Questo fallback merita un test separato perché una scorciatoia che salta direttamente da np mancante a p ignorerebbe l'impostazione predefinita sp documentata.
La modalità di test e la gestione del ricevitore rimangono livelli aggiuntivi. Se il record applicabile include t=y, derivare prima la policy selezionata e poi applicarne la semantica di test. Inoltre, una valutazione del rifiuto richiesta non garantisce un rifiuto finale: l'analisi del ricevitore e i requisiti di interoperabilità nella RFC 9989 rimangono rilevanti. La tabella allegata a questo articolo registra la selezione delle policy, non il posizionamento osservato della casella di posta.
Conserva un pacchetto di prove invece di un badge verde
La commissione esatta è: confrontare i casi esistenti, NODATA e NXDOMAIN e ricavare la politica selezionata. Il confronto fittizio supporta la revisione della logica prevista, ma non chiude il cancello dell'evidenza operativa originale. Non sono state raccolte query in tempo reale, incontri con autorità controllata o risultati del ricevitore. Anche l'attuale revisione degli errata è irrisolta dopo che gli endpoint inaccessibili sono stati interrotti.
Un follow-up approvato dovrebbe conservare l'esatto dominio dell'autore, il record della politica applicabile, le prove dell'esistenza, il percorso di fallback, la versione del destinatario e la valutazione risultante. Mantieni la revisione della progettazione DNS separata dalla proprietà delle politiche di posta. L'applicabilità della produzione, la revisione specialistica, l'accettazione visiva e l'autorizzazione alla pubblicazione rimangono in sospeso. Una spiegazione np affidabile rende visibile l’incertezza proprio laddove uno strumento imprudente potrebbe nasconderla.