Quando a DKIM La chiave viene visualizzata in un pannello di controllo DNS ma la verifica fallisce, controlla la risposta effettivamente recuperata dal verificatore. Gli screenshot possono nascondere un valore troncato, un suffisso di dominio duplicato o più record indipendenti. Il compito è stabilire il nome esatto del proprietario e i byte della chiave prima di modificare il firmatario.
Inizia dalla firma ricevuta
Leggere d= E s= dalla persona colpita DKIM-Signature. Il nome della ricerca li combina come selettore. _domainkey.signing-domain. Un messaggio sintetico con d=example.com E s=notify quindi utilizza notify._domainkey.example.com. Una chiave pubblicata su notifications._domainkey.example.com non lo riparerà.
Registra l'algoritmo della firma e il motivo esatto del destinatario. Chiave mancante, chiave non valida, algoritmo non adatto, mancata corrispondenza della firma e mancata corrispondenza dell'hash del corpo non sono diagnosi intercambiabili. Se esistono più firme, mantieni separati i selettori e i risultati.
Ricostruire correttamente un record TXT
DNS Record TXT può contenere più stringhe di caratteri. RFC 6376 §3.6.2.2 richiede che le stringhe all'interno di un singolo record siano concatenate senza spazi bianchi aggiunti prima dell'uso. La suddivisione di una chiave lunga tra stringhe in un record è diversa dalla creazione di più record TXT , ciascuno contenente un pezzo. Quest'ultimo non è un modo sicuro per pubblicare una chiave DKIM . La sezione 3.6.2.2 richiede un record TXT univoco per il file selettore e lascia i risultati a record multipli indefiniti; le scelte del verificatore nella sezione 6.1.2 non rendono componibili i frammenti.
I blocchi tra virgolette mostrati da uno strumento DNS sono una presentazione del record. Non dare per scontato che le virgolette visualizzate siano byte chiave letterali e non rimuovere i caratteri indiscriminatamente dall'interfaccia DNS . Segui il formato di voce supportato, interroga DNS autorevole e confronta il valore ricostruito con il valore pubblico generato. RFC 1035 §3.3.14 definisce la rappresentazione della stringa di caratteri TXT .
Controllare eventuali troncamenti ai limiti dell'interfaccia, etichette di riga incollate, separatori mancanti e modifiche accidentali al valore base64. Le registrazioni lunghe richiedono un confronto esatto, non un'ispezione visiva dei primi e degli ultimi caratteri. Conservare il valore pubblico generato originariamente per tale confronto; non sostituire mai un file con chiave privata.
Convalida insieme i tag e il materiale chiave
Sotto RFC 6376 §3.6.1, IL p= il tag trasporta i dati della chiave pubblica. Un valore vuoto indica una configurazione revocata e non completata parzialmente. IL k= il tag identifica il tipo di chiave, con RSA come impostazione predefinita in RFC 6376 ; Ed25519 utilizza l'estensione definita da RFC 8463 §4.2. La sezione 3.6.1 RFC 6376 contrassegna formalmente il record di chiave v= tag RACCOMANDATO, con DKIM1 come predefinito quando è assente. Se incluso, deve essere il primo tag e il suo valore deve essere esattamente DKIM1 ; tale valore fa distinzione tra maiuscole e minuscole.
Utilizza un validatore gestito compatibile con DKIM per analizzare il record completo e confermare che il materiale pubblico decodificato sia appropriato per il tipo di chiave indicato. Base64 valido da solo non dimostra che il contenuto sia una chiave pubblica RSA o Ed25519 adatta. Allo stesso modo, un record sintatticamente valido può contenere la chiave pubblica errata per il firmatario privato attivo.
Isolare il livello di pubblicazione dal livello di firma
Un fallimento illustrativo comporta a 2048 bit Chiave pubblica RSA copiata in due record TXT separati. Riparare la rappresentazione nel modulo multistringa a record singolo supportato dal provider DNS , quindi rileggere la risposta. Non abbreviare la chiave per silenziare l'errore dell'interfaccia senza esaminare la causa e le implicazioni sulla sicurezza.
Se la chiave pubblica corretta viene risolta intatta ma il messaggio continua a non riuscire, esamina la mappatura del selettore attivo, la corrispondenza della coppia di chiavi, l'algoritmo e le modifiche del messaggio firmato. Non continuare a ripubblicare dati DNS identici mentre le prove puntano altrove. Un fornitore gestito CNAME dovrebbe essere ricondotto alla sua registrazione chiave finale; non dovrebbe essere sostituito con una copia locale come soluzione alternativa alla sintassi generica.
Dimostrare la riparazione su un nuovo messaggio
Registra risultati autorevoli e ricorsivi, tenendo conto dei vecchi o memorizzati nella cache risposte negative. Invia tramite l'applicazione interessata e controlla il risultato del destinatario fidato. Conservare il nome del proprietario corretto, il valore pubblico ricostruito o il suo digest, il confronto dei valori generati e le prove dei test. Una riparazione è completa quando la chiave recuperata e il firmatario effettivo concordano, non semplicemente quando l'editor DNS accetta il modulo.
Controlla la struttura senza una vera chiave
Presentazione illustrativa di un record: " v=DKIM1; k=rsa; p=AB" "CD". La concatenazione produce v=DKIM1; k=rsa; p=ABCD, senza spazio inserito tra AB e CD. ABCD non è deliberatamente una chiave pubblica RSA valida e utilizzabile; questo esempio dimostra solo la struttura TXT e non deve essere pubblicato. Due record separati che terminano con p=AB e contengono CD non sono equivalenti. Dopo aver ricostruito il valore reale generato, un parser compatibile con DKIM deve ancora convalidare i tag e il materiale della chiave decodificato.
Lettura correlata
Pubblicazione DKIM TXT e CNAME : segui il modello di gestione delle chiavi del provider · Lunghezza e algoritmi della chiave DKIM : controlla il supporto attuale del ricevitore.