Testare un DNS diviso senza far trapelare nomi interni

Interrogare un resolver pubblico per un nome interno lo fa trapelare e salta la regola che volevi testare. La query raggiunge un server che non controlli, la risposta arriva da uno spazio dei nomi che non avrebbe mai dovuto vederlo, e il risultato non dice nulla sul fatto che il DNS diviso funzioni. Testare un DNS diviso significa testare il percorso del resolver che un’applicazione usa davvero. Quel percorso è scelto dal sistema operativo, dall’elenco dei domini nel profilo VPN e a volte dal browser.

Scegli due nomi e prevedi prima entrambe le risposte

Chiedi al responsabile della rete un nome di test interno documentato e scegli un nome pubblico ordinario che non dica nulla sull’organizzazione. Scrivi cosa dovrebbe succedere per ciascuno prima di eseguire qualsiasi cosa: il nome interno dovrebbe raggiungere il resolver del tunnel e restituire un indirizzo interno, mentre il nome pubblico dovrebbe essere risolto tramite il resolver che il sistema usa normalmente. Queste due previsioni sono il test, perché senza di esse qualsiasi risposta può essere giustificata a posteriori. Mantieni la coppia fissa tra un’esecuzione e l’altra, così un confronto successivo significa qualcosa.

Controlla le regole effettive, non quelle previste. L’elenco dei domini collegato alla connessione VPN decide quali suffissi vanno a quale resolver, e un refuso in quell’elenco produce una divisione plausibile ma sbagliata. Su un dispositivo gestito, usa il percorso diagnostico dell’amministratore, perché le sovrascritture locali possono essere ripristinate da un criterio al controllo successivo.

Annota la previsione accanto alla risposta osservata nello stesso ticket. Un test senza previsione non può fallire, e un test che non può fallire non insegna nulla.

Testa il percorso che usa l’applicazione, non un server che hai scelto tu

Un comando che nomina esplicitamente un resolver testa quel resolver e nient’altro. Ti dice se il server interno risponde, il che è utile, e non ti dice se un’applicazione invia lì il nome. Testa prima tramite il percorso normale: risolvi il nome interno come farebbe un’applicazione, poi risolvi il nome pubblico allo stesso modo. Solo dopo interroga server specifici per trovare dove il comportamento diverge.

I browser complicano il quadro, perché le impostazioni di DNS sicuro possono aggirare del tutto il resolver di sistema. Un browser configurato con il proprio resolver cifrato non vede mai la divisione, e il guasto sembra un profilo VPN rotto. Controlla quell’impostazione prima di cambiare il tunnel.

Ripeti la ricerca dopo la riconnessione se la questione è il ripristino. Una risposta in cache da prima della riconnessione può far sembrare una divisione ripristinata correttamente migliore o peggiore di com’è.

Registra la categoria della risposta, non solo successo o fallimento

Annota quale delle quattro cose è successa: un indirizzo interno, un indirizzo pubblico, una risposta negativa o un timeout. Ognuna ha un significato diverso. Un indirizzo interno per il nome interno è il successo atteso; un indirizzo pubblico per un nome interno suggerisce che la query ha lasciato il tunnel; una risposta negativa dal server autoritativo indica un record mancante anziché un errore di routing; e un timeout indica un problema di raggiungibilità o un resolver che non ha mai ricevuto la query. Successo e fallimento sono troppo grossolani per agire.

Tieni conto della cache prima di interpretare una query nuova assente, perché una risposta negativa in cache sembra identica a un nome che non esiste. Cattura la risposta prima di cancellare qualsiasi cosa con controlli supportati, perché la prima risposta è la prova.

Interpreta i due rami senza indovinare

Se il nome interno si risolve correttamente e l’applicazione continua a fallire, il resolver ha fatto il suo lavoro e i successivi sospetti sono le route e i permessi sulla risorsa stessa. Se il nome privato ha raggiunto un resolver pubblico, la regola di divisione non viene applicata a quella ricerca, quindi rivedi l’elenco dei domini e qualsiasi criterio del browser con il proprietario dello spazio dei nomi. Questi due rami hanno proprietari diversi, ed è per questo che annotare quale hai visto conta più di annotare che qualcosa si è rotto.

Censura i dati sensibili dell’output condiviso mantenendo la struttura: quale spazio dei nomi, quale regola, quale categoria di risposta. Una risposta del resolver può contenere indirizzi interni e nomi host, e un ticket è una casa duratura per entrambi.

Poi consegna il risultato al proprietario dello spazio dei nomi con le due categorie osservate e i nomi rimossi. È una conversazione di cinque minuti invece di una settimana di speculazioni.