Ricorsione non disponibile: una politica DNS, non un tunnel rotto

Il nome interno si risolve, e lo stesso server risponde a un nome esterno con un rifiuto sulla ricorsione. Questa combinazione non è una contraddizione. Pubblicare le proprie zone e risolvere l’intera internet sono due servizi separati che un server può offrire, e può fare il primo senza il secondo. Tratta il rifiuto come una dichiarazione di politica, poi verifica se la politica corrisponde al progetto.

Un rifiuto e un timeout sono risposte diverse

Annota il nome, il tipo di query, il server che risponde, lo stato e i record restituiti. Un avviso di ricorsione non invalida automaticamente una risposta autorevole arrivata con esso. Scrivi lo stato prima di interpretarlo. Uno stato ricostruito a memoria un’ora dopo è un fatto diverso.

L’intestazione DNS porta una richiesta di ricorsione e un’indicazione se il server la offre, e la specifica del protocollo tiene quei flag separati dai dati della risposta. Per questo una risposta può essere utile e portare comunque un reclamo. Un timeout, una risposta negativa e un rifiuto sono tre risultati diversi. Ognuno punta a uno strato diverso, e solo il rifiuto è il server che ti parla di politica.

Leggi prima il codice di stato, poi decidi se l’avviso conta per questa query. Una risposta autorevole che nomina la zona è utilizzabile anche quando il bit ricorsivo viene rifiutato. Un rifiuto senza risposta è un risultato di politica, non un percorso di pacchetti rotto.

Che cosa ha registrato il resolver come tua origine

Il client può arrivare da un pool di indirizzi fuori dagli intervalli ricorsivi consentiti del server, oppure una traduzione può farlo sembrare un gateway. L’indirizzo dell’adattatore del client non è una prova di ciò che il resolver ha ricevuto. Chiedi all’amministratore del server l’origine osservata invece di dedurla dal tuo lato del percorso. I due indirizzi possono differire a ogni salto che traduce.

Interroga lo stesso nome dal client e da un host di cui il server si fida già. La differenza tra le due risposte è la condizione di origine, ed è più utile di ciascuna risposta da sola.

dig +short host.corp.example
dig +short example.com

Se la distribuzione vuole la ricorsione per i client VPN, l’amministratore autorizza l’intervallo di origini adatto tramite i controlli propri del server. Aprire la ricorsione a ogni rete perché un test passi è un cambiamento molto più grande di quello in prova. Scrivi l’intervallo autorizzato accanto alla regola, perché il prossimo revisore chiederà a quali origini la politica doveva servire. Un intervallo di origini senza proprietario è il modo in cui un test temporaneo diventa permanente.

Il DNS diviso è un progetto, non un guasto

Alcune distribuzioni inviano solo i domini di lavoro al resolver privato e tutto il resto a un altro resolver approvato. È un progetto di instradamento delle query, e non è la prova che il server privato abbia bisogno di una politica più permissiva. Con quel progetto, un nome esterno che fallisce attraverso il resolver privato è il risultato previsto e non un guasto. Il rifiuto è il progetto che funziona, non un sintomo da soffocare.

Un resolver pubblico può ripristinare la navigazione mentre rompe nomi interni o invia query private dove non dovrebbero andare. Scrivi il comportamento previsto prima di cambiare qualsiasi indirizzo di resolver.

Verifica la politica con due query

Dopo la correzione prevista, interroga un nome privato consentito e un nome esterno dal client reale. Ciò che torna dovrebbe essere ciò che la politica promette, non solo una diagnostica più silenziosa. Annota il server che risponde con ogni risposta, poi confronta la coppia con la politica. Il confronto è il test, e una singola ricerca riuscita non lo è.

resolvectl query host.corp.example
resolvectl query example.com

Se il nome privato funziona e il nome pubblico viene rifiutato, la politica fa ciò che dice. Se anche il nome privato fallisce, il problema è la zona, la rotta o l’autorizzazione dell’origine, e la ricorsione è una distrazione. Entrambi gli esiti sono utili, e ciascuno esclude la metà delle ipotesi rimaste.

Leggi il rifiuto come prova

Un rifiuto è una risposta. Significa che il server ha ricevuto la query e ha rifiutato di svolgere il lavoro richiesto, il che è diverso da un pacchetto che non è mai arrivato. Questa distinzione è tutta la diagnosi. Registrala come risposta, non come guasto di connettività.

Questa distinzione ti dice dove guardare: i log del server, la sua politica di accesso e l’origine che ha registrato. Un cambiamento del firewall non può correggere un rifiuto di politica, e un cambiamento di politica non può correggere una rotta mancante. Tieni separate le due ipotesi finché una delle due ha una prova.

Scrivi l’esito e il proprietario della politica nel ticket, così la persona successiva parte dalla decisione e non dall’avviso. Nomina l’intervallo di origini autorizzato e i due nomi che hai provato. Un ticket con questi tre fatti può essere rieseguito; uno che dice "la ricorsione è rotta" no.