Il tag np di DMARCbis e il suo punto cieco DNSSEC: cosa deve verificare ogni amministratore

⚡TL;DR

• Il tag np di DMARCbis (RFC 9989, maggio 2026) applica una policy ai sottodomini che non esistono nel tuo DNS. È la nuova arma contro lo spoofing di sottodomini fabbricati.
• np si basa su una cosa sola: il codice di risposta NXDOMAIN. Il valutatore DMARC lo attiva solo se il DNS conferma, con un NXDOMAIN rigoroso, che il nome non esiste.
• Molte zone DNSSEC moderne rispondono NOERROR, non NXDOMAIN. Per risparmiare firme, praticano il compact denial of existence o le «black lies». Il valutatore crede allora che il sottodominio esista e ripiega su sp.
• Risultato: np=reject viene neutralizzato senza il minimo messaggio di errore non appena sp è più permissivo. Una mail contraffatta con mittente fattura.captaindns.com passa.
• La correzione sta in una riga di configurazione: rendere sp severo quanto np, e pubblicare record DMARC espliciti sui tuoi sottodomini mittenti legittimi.

DMARCbis è uno standard pubblicato. Le RFC 9989, 9990 e 9991 (maggio 2026) sostituiscono la vecchia RFC 7489 e introducono il tag np, finalmente una risposta pulita a una vecchia falla di DMARC: il sottodominio che non è mai stato dichiarato. Prima di np, un attaccante poteva inviare da fattura.captaindns.com senza che nessuna policy si applicasse, perché quel nome non esisteva da nessuna parte nella zona. Il tag np chiude questa porta, in teoria.

In teoria. Perché np si basa su un segnale DNS preciso, il codice NXDOMAIN, e questo segnale è sparito in sordina da gran parte delle zone DNSSEC realmente in uso. Su una zona firmata da Cloudflare, AWS Route 53, Microsoft Azure DNS o NS1, una query verso un nome inesistente non restituisce NXDOMAIN. Restituisce NOERROR. E per un valutatore DMARC, NOERROR significa «questo sottodominio esiste». A quel punto applica sp, non np. Se sp è più permissivo, la protezione svanisce.

Verdetto. Chi è coinvolto: qualsiasi dominio che conta su np più severo di sp, ospitato su una zona DNSSEC in compact denial. Gravità: degrado silenzioso, non un guasto. Niente si rompe, nessun log si accende, la tua posta legittima parte come prima. Solo la promessa anti-spoofing di np viene svuotata di significato. Non è una falla di DNSSEC: DNSSEC fa esattamente ciò che gli si chiede. È un'ipotesi di DMARCbis che non regge più di fronte al DNS moderno.

A cosa serve il tag np e in cosa differisce da sp?

Il tag np definisce la policy DMARC applicata ai sottodomini che non esistono nel DNS, mentre sp definisce la policy dei sottodomini che esistono. La differenza sta in una sola parola: inesistente. Tutto il problema è qui.

Riprendiamo il problema che np risolve. Il tuo dominio captaindns.com pubblica i suoi server di posta, i suoi record SPF e DKIM, una policy DMARC severa. Ma un attaccante non ha bisogno di un sottodominio che hai dichiarato. Se ne fabbrica uno. Invia una falsa fattura da fattura.captaindns.com, un nome che non hai mai creato nella tua zona. Con DMARC v1, nessuna policy scendeva a questo livello in modo affidabile per i nomi non dichiarati, e lo spoofing passava sotto il radar. Il tag np colma esattamente questa lacuna. Per tutto il contesto dello standard, vedi la nostra guida DMARCbis.

DMARCbis distingue quindi tre ambiti, con una catena di fallback rigorosa:

Tag	Si applica a	Valori	Fallback se assente
p	Il dominio organizzativo stesso	none / quarantine / reject	Nessuno (obbligatorio)
sp	I sottodomini che esistono nel DNS	none / quarantine / reject	Ripiega su p
np	I sottodomini inesistenti (NXDOMAIN)	none / quarantine / reject	Ripiega su sp, poi p

Un caso d'uso tipico: p=none, sp=none, np=reject

La configurazione più comune tra le organizzazioni che adottano np è più o meno questa:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=none; sp=none; np=reject; rua=mailto:dmarc@captaindns.com"

La logica dell'amministratore è ragionevole. Il dominio radice è in osservazione (p=none), perché occorre monitorare il traffico legittimo prima di irrigidire le regole. Anche i sottodomini reali (sp=none), il tempo di mappare i servizi che inviano. Ma i sottodomini che non esistono, nessuno ha un motivo legittimo per usarli: tanto vale rifiutarli subito (np=reject). È il riflesso giusto. Il problema non è la logica. Il problema è che, su una zona DNSSEC moderna, questo np=reject forse non scatterà mai.

Tieni a mente il meccanismo del fallback: np viene consultato solo se il ricevente ha stabilito che il sottodominio non esiste. Altrimenti applica sp. Tutta la falla sta in quel «ha stabilito che il sottodominio non esiste».

Come decide DMARCbis che un sottodominio non esiste?

DMARCbis considera un sottodominio inesistente solo quando il DNS restituisce il codice NXDOMAIN. È un criterio rigido, ereditato da un principio DNS formalizzato dalla RFC 8020: «niente al di sotto». Se un nome restituisce NXDOMAIN, allora quel nome e tutto ciò che potrebbe esistere al di sotto di esso non esistono. Il ricevente DMARC si affida a questa garanzia per scegliere tra sp e np.

La parola «NXDOMAIN» qui è tutt'altro che banale. Non significa «non ho trovato niente». Significa precisamente «questo nome non esiste nella zona». E il DNS distingue due situazioni di assenza che spesso si confondono.

La differenza tra NXDOMAIN e NODATA

Due risposte DNS significano «assenza», ma non dicono la stessa cosa. Il ricevente DMARC reagisce solo alla prima.

• NXDOMAIN (codice di stato NXDOMAIN): il nome stesso non esiste. Nessun record, di nessun tipo, a quel nome. È ciò che DMARCbis si aspetta per attivare np.
• NODATA (codice di stato NOERROR, sezione risposta vuota): il nome esiste, ma non per il tipo richiesto. Per esempio, blog.captaindns.com ha un record AAAA ma non un MX. La query MX restituisce NOERROR senza dati. Il nome esiste. np non si applica.

La distinzione è perfettamente logica in un DNS classico. Un attaccante che invia da un sottodominio fabbricato provoca un NXDOMAIN, perché il nome non è mai stato creato. np fa presa. Tutto bene. Lo scivolamento avviene quando la zona è firmata con DNSSEC e decide di non restituire più NXDOMAIN.

Il restringimento introdotto da DMARCbis

Un dettaglio storico spiega perché la falla è più ampia di quanto si pensi. L'estensione sperimentale precedente, la RFC 9091 (PSD DMARC), era più tollerante: per giudicare l'esistenza di un sottodominio, accettava anche un'assenza di dati sui tipi A, AAAA e MX, non solo un NXDOMAIN puro. In altre parole, un NODATA su questi tipi contava come «questo sottodominio non riceve posta».

DMARCbis ha ristretto questo test. La RFC 9989 si basa sul solo NXDOMAIN come segnale di inesistenza. Questa scelta rende lo standard più pulito sulla carta: un criterio unico, senza ambiguità di tipo. Ma elimina la rete che, sotto la RFC 9091, avrebbe intercettato una parte delle zone DNSSEC che rispondono NOERROR. Il restringimento, pensato per il rigore, è proprio ciò che apre il punto cieco di fronte al compact denial.

Cos'è il compact denial of existence?

Il compact denial of existence è una tecnica DNSSEC che dimostra l'inesistenza di un nome restituendo NOERROR con un unico record NSEC sintetizzato al volo, invece del classico NXDOMAIN. Molti grandi provider DNS con zone firmate l'hanno adottata per un motivo semplice: il costo.

Dimostrare un'assenza in DNSSEC costa caro. Il metodo tradizionale (NSEC o NSEC3) richiede di restituire dei record che racchiudono il nome richiesto nell'ordine canonico della zona, ciascuno accompagnato dalla sua firma RRSIG. Per un servizio che firma milioni di zone e vede passare fiumi di query verso nomi inesistenti (scansioni, errori di battitura, sonde), questo significa firme da calcolare, archiviare e trasmettere in continuazione. Il compact denial aggira il problema: invece di scovare i veri vicini, il server fabbrica al volo un intervallo NSEC minimo attorno al nome richiesto, lo firma una volta sola e risponde NOERROR. Meno calcolo, meno byte sul filo, una sola firma.

Per segnalare che l'assenza è reale e non un semplice NODATA, la tecnica marca la risposta con uno pseudo-tipo chiamato NXNAME (tipo 128). Un resolver che comprende questo marcatore sa che dietro quel NOERROR si nasconde «il nome non esiste». Il problema: questa traduzione resta nel resolver, non risale fino al valutatore DMARC sotto forma di NXDOMAIN.

Il flag CO che potrebbe cambiare tutto

La specifica prevede una salvaguardia, in teoria. Un flag opzionale lato resolver, «CO» (Compact Answers OK), permette al resolver di annunciare che gestisce il compact denial e, in cambio, di ricostruire un vero NXDOMAIN per il proprio client quando la risposta porta il marcatore NXNAME. Sulla carta, questo meccanismo richiude il punto cieco.

In pratica, nessuno lo attiva. I grandi resolver pubblici non impostano questo flag di default, e il valutatore DMARC che gira dietro di essi riceve il NOERROR grezzo. La correzione esiste nel testo, non nel traffico reale.

Per approfondire. NSEC e NSEC3 sono i due meccanismi storici di prova di assenza in DNSSEC; NSEC3 applica un hash ai nomi per complicare l'enumerazione della zona, NSEC li espone in chiaro. La cache aggressiva dei resolver (RFC 8198) permette di riutilizzare una prova NSEC per rispondere ad altri nomi inesistenti senza query, ma nemmeno essa ripristina il codice NXDOMAIN quando la prova è un NSEC sintetico in NOERROR. La cache accelera, non corregge nulla per np.

Lo scenario passo passo: quando NOERROR fa ripiegare np su sp

Ecco lo svolgimento completo, dall'invio fraudolento alla consegna. La zona captaindns.com è firmata in compact denial e pubblica p=none; sp=none; np=reject. Un attaccante invia una falsa fattura da fattura.captaindns.com, un sottodominio che non esiste nella zona.

1. La mail arriva al ricevente con From: contabilita@fattura.captaindns.com. L'autenticazione SPF e DKIM fallisce, il che è previsto: l'attaccante non controlla il dominio.
2. Il ricevente avvia il tree walk DMARCbis e risale i label finché non trova la policy. La scopre su _dmarc.captaindns.com: p=none; sp=none; np=reject.
3. Ora deve decidere: questo sottodominio fattura.captaindns.com esiste o no? Dalla sua risposta dipende la scelta tra sp (esistente) e np (inesistente).
4. Interroga il DNS per fattura.captaindns.com. La zona è firmata in compact denial.
5. La risposta torna con NOERROR, con un NSEC sintetizzato che porta il marcatore NXNAME. Il codice di stato, quello che il valutatore DMARC legge, è NOERROR, non NXDOMAIN.
6. Il ricevente conclude che il sottodominio esiste. Per lui, NOERROR significa presenza. Scarta np e seleziona sp.
7. Applica sp=none. La falsa fattura viene consegnata. Il np=reject pubblicato non è mai stato consultato.

Sette passaggi, nessun errore, nessun log di anomalia. L'amministratore ha pubblicato np=reject in buona fede e crede protetti i suoi sottodomini inesistenti. Non lo sono.

L'osservazione è riproducibile. Ecco cosa restituisce una query diretta verso un nome inesistente su una zona firmata da Cloudflare:

$ dig +dnssec +norecurse randomabc123.cloudflare.com A @ns3.cloudflare.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
randomabc123.cloudflare.com. IN NSEC \000.randomabc123.cloudflare.com. RRSIG NSEC TYPE128

Lo stato è NOERROR. L'NSEC copre un intervallo minimo (\000.randomabc123...) e la presenza del tipo 128 (NXNAME) conferma il compact denial. Un valutatore DMARC posto dietro un resolver classico vedrà questo NOERROR così com'è.

Per contrasto, una zona firmata che risponde correttamente:

$ dig +dnssec randomabc123.fbi.gov A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

Stato NXDOMAIN, prova di assenza in NSEC3. Qui np scatta normalmente. Stessa famiglia di protocollo, comportamento opposto. Il provider DNS fa tutta la differenza.

Chi è davvero coinvolto da questo punto cieco?

Tre condizioni devono verificarsi contemporaneamente perché la falla faccia presa. Se ne manca una, il tuo np resta rispettato. È ciò che molti articoli tacciono: il problema non è né universale né inevitabile.

Tre condizioni devono verificarsi insieme

1. La tua policy pubblica un np più severo del fallback sp. Se np e sp sono identici, non c'è nulla da perdere: che il ricevente applichi l'uno o l'altro, il risultato è lo stesso.
2. La tua zona è firmata con DNSSEC e pratica il compact denial o le «black lies». Una zona non firmata, o firmata ma che restituisce un vero NXDOMAIN, non pone questo problema.
3. Il valutatore DMARC del ricevente si fida del codice di risposta. È il comportamento predefinito della quasi totalità delle implementazioni: distinguono solo NOERROR da NXDOMAIN, non lo pseudo-tipo NXNAME.

La sfumatura che tutti sbagliano: np contro sp

Il punto decisivo: np viene vanificato solo se è più severo di sp. Finché il ricevente ripiega su sp, è il valore di sp a decidere la sorte della mail contraffatta.

Policy pubblicata	Ciò che np promette	Applicato su una zona in compact denial	Esposto?
sp=none; np=reject	Rifiutare i sottodomini fasulli	sp=none: la mail passa	Sì, falla spalancata
sp=quarantine; np=reject	Rifiutare	sp=quarantine: spam invece del rifiuto	Parziale
sp=reject; np=reject	Rifiutare	sp=reject: rifiuto comunque	No
sp assente, p=reject, np=reject	Rifiutare	Ripiego su p=reject	No

La riga in fondo è la tua via d'uscita. Se sp (o il suo fallback) è già severo quanto np, il punto cieco non ha alcun effetto. È la base della correzione.

La trappola dei wildcard

Il compact denial non è l'unico modo per neutralizzare np. Anche un wildcard DNS lo fa, e senza alcun DNSSEC. Se la tua zona contiene *.captaindns.com, allora qualsiasi nome sotto captaindns.com restituisce una risposta positiva: il wildcard fabbrica un'esistenza per tutti. Un sottodominio che non hai mai dichiarato ora «esiste» dal punto di vista del DNS, quindi np non si applica mai e il ricevente ripiega su sp. Un wildcard A o AAAA ampio annulla il tuo np con la stessa certezza di una zona in compact denial.

Lato provider, i nostri test dig, che puoi riprodurre, danno la tabella seguente. Diversi tra i più grandi servizi di DNS gestito rispondono NOERROR invece di NXDOMAIN sulle zone che firmano:

Provider DNS	Dominio firmato testato	Risposta al nome inesistente	np rispettato?
Cloudflare	cloudflare.com	NOERROR + NSEC con NXNAME (tipo 128)	No
NS1 (IBM)	ns1.com	NOERROR + NSEC con NXNAME	No
AWS Route 53	login.gov	NOERROR + NSEC minimo, senza NXNAME	No
Azure DNS	office.com, hhs.gov	NOERROR + NSEC minimo, senza NXNAME	No
Google Cloud DNS	fbi.gov	NXDOMAIN (NSEC3)	Sì

Due lezioni. Primo, due varianti distinte rompono np. Il compact denial rigoroso con marcatore NXNAME (Cloudflare, NS1) e le «black lies» più datate, un NOERROR nudo senza NXNAME (Route 53, Azure). Non importa la variante: il denominatore comune è il codice, NOERROR invece di NXDOMAIN. Questo allarga nettamente il perimetro. Secondo, non è una fatalità: Google Cloud DNS restituisce un NXDOMAIN classico e lascia funzionare np. Il provider conta.

Una parola di onestà sulla portata. Non avanziamo alcuna percentuale: misurare la prevalenza esatta delle zone in compact denial richiederebbe una scansione globale che non abbiamo condotto. Ma Cloudflare figura tra i più grandi provider DNS al mondo, e Route 53 come Azure DNS pesano molto nell'infrastruttura aziendale. Quando quattro attori di questo calibro restituiscono NOERROR sulle loro zone firmate, una larga parte delle zone DNSSEC realmente in uso è coinvolta. Per Oracle Cloud DNS e Dyn non abbiamo osservato una zona firmata sfruttabile: non li collochiamo né in un campo né nell'altro.

Come verificare se il tuo np è rispettato?

Tre verifiche bastano per sapere se il tuo np è davvero applicato. Ognuna risponde a una delle tre condizioni della falla. Metti in conto cinque minuti.

Passo 1: la tua zona è firmata con DNSSEC?

Comincia dal più semplice. Se la tua zona non è firmata, il punto cieco del compact denial non ti tocca (fai comunque attenzione alla trappola del wildcard vista sopra). Verifica la presenza di record DNSKEY e DS con il verificatore DNSSEC di CaptainDNS, o da riga di comando:

dig DNSKEY captaindns.com +short
dig DS captaindns.com +short

Una zona firmata restituisce almeno una chiave DNSKEY e, lato parent, un record DS. Zona firmata: passa al passo 2. Zona non firmata: il passo 3 resta utile per il caso del wildcard.

Passo 2: un sottodominio fasullo restituisce NXDOMAIN o NOERROR?

È il test centrale. Interroga un nome che non hai mai creato e leggi il codice di stato, non i dati:

dig +dnssec un-nome-che-non-esiste-9x7q.captaindns.com A

Individua la riga ;; ->>HEADER<<-. Due esiti possibili:

• status: NXDOMAIN: perfetto, il tuo np scatta normalmente. Sei nel caso Google Cloud DNS.
• status: NOERROR: la tua zona nasconde l'inesistenza dietro un NOERROR. Il tuo np ripiega su sp. Passa al passo 3 per misurare l'esposizione reale.

Testa anche da un resolver pubblico, perché è ciò che vedono i riceventi di posta. Le nostre prove confermano che 8.8.8.8, 1.1.1.1 e 9.9.9.9 inoltrano il NOERROR senza ricostruire NXDOMAIN. Poiché il flag CO non è attivo, il valutatore DMARC a valle riceve appunto un NOERROR.

Passo 3: np è più severo di sp?

Ultima domanda, la più decisiva. Recupera il tuo record e confronta np con sp (e con il fallback p se sp è assente):

dig TXT _dmarc.captaindns.com +short

Confronta i valori con la tabella della sezione precedente. Se np è più severo del fallback sp, e il passo 2 ha dato NOERROR, la tua protezione dei sottodomini inesistenti è neutralizzata. Per leggere la sintassi completa e individuare un tag malformato, passa il record nel verificatore di record DMARC. Se np e il fallback sono già allo stesso livello, respira: il punto cieco non ha alcuna presa su di te.

Come mettere in sicurezza i tuoi sottodomini fin da subito?

La correzione non dipende da una patch futura del DNS o dell'IETF. La applichi oggi, lato configurazione, rendendo la tua policy insensibile al fatto che np possa essere ignorato. Il principio: non lasciare mai che np regga da solo una protezione che sp non garantisce.

La ricetta a doppia sicurezza

Allinea sp a np. Se vuoi rifiutare i sottodomini inesistenti, rifiuta anche i sottodomini esistenti non legittimi, e rendilo il tuo fallback:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@captaindns.com"

Con sp=reject, non importa se il ricevente crede il sottodominio esistente o no: in entrambi i casi rifiuta. Il compact denial non ha più alcuna presa. È l'unica configurazione che chiude il punto cieco qualunque sia il comportamento della tua zona DNSSEC. Se il tuo dominio radice non è pronto per p=reject, puoi mantenere p più morbido, ma tieni sp e np allo stesso livello severo.

Pubblicare record sui sottodomini che inviano

sp=reject blocca tutto ciò che non è esplicitamente autorizzato. I tuoi sottodomini che inviano legittimamente (newsletter.captaindns.com, notifications.captaindns.com) devono quindi avere la propria configurazione di autenticazione e, idealmente, il proprio record DMARC. Mappa prima i tuoi mittenti tramite i report aggregati rua, poi pubblica per ciascuno un record dedicato prima di irrigidire sp. Questo inventario è anche ciò che ti evita di rifiutare per errore un servizio interno.

Un record pulito, con p, sp e np coerenti, si genera e si convalida senza sforzo. Lo strumento di migrazione DMARCbis riprende il tuo record esistente e lo porta allo standard senza rompere la retrocompatibilità v=DMARC1.

La scelta del provider DNS conta

Il comportamento della prova di assenza non è configurabile presso la maggior parte dei provider gestiti: è imposto dal servizio. Se pretendi che np funzioni lato ricevente senza dipendere da sp, il comportamento NXDOMAIN del tuo provider diventa un criterio di scelta a pieno titolo, al pari della latenza o del prezzo. Non è un motivo per fuggire da Cloudflare o Route 53, i cui vantaggi restano reali. È un motivo per conoscere la loro risposta a un nome inesistente, e per configurare il tuo sp di conseguenza. Finché sp è allineato a np, il provider smette di essere un problema.

A che punto è l'IETF su questo tema?

Ad oggi, nessuna soluzione è stata decisa. La tensione tra il tag np e il compact denial of existence è stata sollevata all'interno del gruppo di lavoro dmarc dell'IETF, ma non ha ancora portato a una correzione normativa, e la RFC 9989 non affronta la questione. È un motivo in più per mettere in sicurezza lato configurazione, senza aspettare.

Circolano tre ipotesi, nessuna è definitiva:

• Leggere lo pseudo-tipo NXNAME. Le librerie DMARC potrebbero imparare a interpretare il marcatore NXNAME (tipo 128) come un NXDOMAIN, il che ripristinerebbe np per le zone in compact denial rigoroso. Questo lascerebbe fuori le «black lies» senza NXNAME, come quelle di Route 53 o Azure.
• Attivare il flag CO. L'ecosistema potrebbe generalizzare l'attivazione del flag Compact Answers OK lato resolver, per ricostruire NXDOMAIN a monte del valutatore DMARC. Questo presuppone un coordinamento ampio che nulla lascia prevedere a breve termine.
• Reintegrare NODATA. Una futura revisione dello standard potrebbe ripristinare la tolleranza della RFC 9091, accettando di nuovo un NODATA su A, AAAA e MX come segnale di inesistenza.

Nessuna di queste ipotesi ha una tempistica. Non contare su una correzione rapida. La buona notizia: non ti serve. Allineare sp a np neutralizza il punto cieco fin da oggi, indipendentemente da ciò che deciderà l'IETF.

🎯 Piano d'azione: mettere in sicurezza np su una zona DNSSEC

1. Testa la tua zona. Interroga un nome inesistente: dig +dnssec bidon-9x7q.captaindns.com A. Un status: NOERROR segnala il punto cieco.
2. Confronta np e sp. Recupera il tuo record _dmarc e verifica se np è più severo del fallback sp. Se sì, e il passo 1 ha dato NOERROR, sei esposto.
3. Allinea sp a np. Pubblica sp=reject; np=reject (o il livello severo a cui punti) per rendere la protezione indipendente dal codice di risposta DNS.
4. Inventaria i tuoi mittenti. Mappa i sottodomini che inviano davvero tramite i report rua, prima di irrigidire sp, per non rifiutare nulla di legittimo.
5. Pubblica record dedicati su ogni sottodominio mittente legittimo.
6. Elimina i wildcard ampi (*.captaindns.com in A/AAAA) che fanno «esistere» qualsiasi nome e annullano np, con o senza DNSSEC.
7. Integra il comportamento NXDOMAIN del tuo provider DNS nei tuoi criteri, senza farne un motivo di migrazione affrettata.

FAQ

Il tag np protegge davvero i miei sottodomini inesistenti?

Sì, ma a una condizione che non è sempre soddisfatta: il DNS deve restituire un vero NXDOMAIN per i nomi inesistenti. Se la tua zona è firmata con DNSSEC e pratica il compact denial of existence, restituisce NOERROR al suo posto. Il valutatore DMARC crede allora che il sottodominio esista, scarta np e applica sp. Se sp è più permissivo di np, la protezione viene neutralizzata senza alcun segnale.

Come faccio a sapere se la mia zona DNSSEC risponde NOERROR o NXDOMAIN?

Interroga un nome che non hai mai creato e leggi il codice di stato: dig +dnssec un-nome-fasullo-9x7q.captaindns.com A. Individua la riga ;; ->>HEADER<<-. Un status: NXDOMAIN significa che np funziona. Un status: NOERROR segnala che la tua zona nasconde l'inesistenza, e che np ripiega su sp.

Il compact denial of existence rompe anche SPF o DKIM?

No. SPF e DKIM non dipendono dal rilevamento dell'inesistenza di un sottodominio. Il compact denial riguarda solo la logica DMARCbis che sceglie tra sp e np a seconda che il nome esista o no. Le tue verifiche SPF e DKIM, così come la policy p del tuo dominio radice, non sono coinvolte.

Sono coinvolto se non uso DNSSEC?

In genere no: una zona non firmata restituisce un NXDOMAIN classico per i nomi inesistenti, e np scatta normalmente. Un'eccezione: i wildcard. Un record *.captaindns.com in A o AAAA fa «esistere» qualsiasi nome dal punto di vista del DNS, il che annulla np anche senza DNSSEC. Verifica di non avere un wildcard ampio.

Bisogna disattivare DNSSEC perché np funzioni?

No, assolutamente. DNSSEC protegge l'integrità delle tue risposte DNS e disattivarlo aprirebbe rischi ben più gravi del punto cieco di np. La correzione giusta non è toccare DNSSEC, ma allineare sp a np nel tuo record DMARC, così che la protezione non dipenda più dal codice di risposta.

Quale policy pubblicare per essere protetto nonostante il punto cieco?

Rendi sp severo quanto np. Per esempio v=DMARC1; p=reject; sp=reject; np=reject. Con sp=reject, non importa se il ricevente crede il sottodominio esistente o inesistente: in entrambi i casi rifiuta. È l'unica configurazione che chiude il punto cieco qualunque sia il comportamento DNSSEC della tua zona. Pubblica prima record dedicati sui tuoi sottodomini mittenti legittimi.

I resolver pubblici come 8.8.8.8 correggono il problema?

No. I nostri test confermano che 8.8.8.8, 1.1.1.1 e 9.9.9.9 inoltrano il NOERROR di una zona in compact denial senza ricostruire NXDOMAIN. Il flag opzionale CO (Compact Answers OK), che permetterebbe questa ricostruzione, non è attivo di default. Il valutatore DMARC posto dietro questi resolver riceve quindi un NOERROR.

Google Cloud DNS è davvero risparmiato?

Sì, secondo i nostri test. Una query verso un nome inesistente su una zona firmata da Google Cloud DNS restituisce un status: NXDOMAIN classico, con prova di assenza in NSEC3. Il tag np scatta quindi normalmente. È il controesempio che dimostra come il problema non sia inerente a DNSSEC, ma alla scelta del compact denial fatta da alcuni provider.

L'IETF correggerà questo comportamento?

La questione è stata sollevata all'interno del gruppo di lavoro dmarc dell'IETF, ma ad oggi nessuna soluzione è stata decisa e la RFC 9989 non la affronta. Esistono tre ipotesi (leggere lo pseudo-tipo NXNAME, generalizzare il flag CO, reintegrare NODATA), nessuna ha una tempistica. Non contare su una correzione rapida: metti in sicurezza lato configurazione adesso.

Il tag np sostituisce sp?

No, sono complementari. Il tag sp si applica ai sottodomini che esistono nel tuo DNS, np a quelli che non esistono. La catena di fallback va da np a sp a p. È proprio perché il ricevente ripiega su sp quando non può confermare l'inesistenza che il divario tra i due valori crea il punto cieco.

Glossario

• NXDOMAIN: codice di risposta DNS che indica che il nome richiesto non esiste nella zona. È l'unico segnale che DMARCbis accetta per attivare np.
• NODATA: risposta in NOERROR con sezione dati vuota. Il nome esiste, ma non per il tipo richiesto. Non attiva np.
• NOERROR: codice di stato DNS che indica l'assenza di errore. Usato sia per una risposta positiva sia, nel compact denial, per dimostrare un'inesistenza, il che inganna il valutatore DMARC.
• Compact denial of existence: tecnica DNSSEC che dimostra l'inesistenza di un nome tramite un unico NSEC sintetizzato e una risposta NOERROR, per risparmiare firme e larghezza di banda.
• NXNAME (tipo 128): pseudo-tipo che segnala, in una risposta in compact denial, che l'assenza è reale (il nome non esiste), e non un semplice NODATA.
• Black lies: variante più datata dello stesso principio, un NOERROR con NSEC minimo ma senza marcatore NXNAME, usata in particolare da AWS Route 53 e Azure DNS.
• Flag CO (Compact Answers OK): opzione lato resolver che permette di ricostruire un NXDOMAIN a partire da una risposta in compact denial. Raramente attiva in pratica.
• Tag np: policy DMARCbis applicata ai sottodomini inesistenti. Fallback: sp, poi p.

---

Genera un record pulito in un minuto: crea una policy DMARC con p, sp e np coerenti grazie al generatore DMARC, poi convalida il risultato prima della pubblicazione.

---

📚 Guide DMARC e DNSSEC correlate

• Capire la catena di fiducia DNSSEC in 5 minuti: come DNSKEY, DS e RRSIG si concatenano dalla radice alla tua zona.
• Attivare DNSSEC: guida passo passo per registrar: la procedura concreta in base al tuo registrar.
• SERVFAIL dopo l'attivazione di DNSSEC: diagnosi e correzione: risolvere i guasti di risoluzione legati a una firma danneggiata.

Fonti

1. RFC 9989 : DMARC (DMARCbis)
2. RFC 9824 : Compact Denial of Existence in DNSSEC
3. RFC 9091 : Experimental DMARC Extension for PSDs
4. RFC 8020 : NXDOMAIN, there really is nothing underneath
5. RFC 8198 : Aggressive Use of DNSSEC-Validated Cache