dnsmasq scarta una risposta DNS privata: è la protezione anti-rebinding?
Una risposta privata può attivare la protezione anti-rebinding di dnsmasq. Individua prima il rifiuto registrato, poi limita l'eccezione a un solo dominio invece di disattivarla.
Il server DNS aziendale restituisce l'indirizzo privato atteso eppure una query attraverso il resolver di inoltro locale fallisce ancora. La risposta esiste, il che esclude la zona a monte e il record stesso. Resta il passaggio in cui il resolver decide se restituire quella risposta al client. Se quel resolver è dnsmasq, il rifiuto è probabilmente già nel log.
Ricevere una risposta e scegliere di restituirla sono due passaggi diversi.
Confronta lo stesso nome su entrambi i resolver
Annota quale resolver usa davvero l'applicazione e l'esatto nome host che interroga. Poi confronta il risultato a monte con l'evento del resolver di inoltro per lo stesso nome. Una risposta a monte mancante, una risposta negativa in cache e un rifiuto registrato richiedono tre correzioni diverse.
Un indirizzo visibile in una query diagnostica diretta non dimostra che l'applicazione lo abbia ricevuto attraverso il suo percorso abituale. Le due query possono partire da resolver diversi, o dallo stesso resolver con politiche diverse. Annota entrambi i risultati prima di teorizzare, perché è qui che si sostituisce l'uno con l'altro. Il confronto è l'intera diagnosi.
Leggi il rifiuto invece del sintomo
L'opzione stop-dns-rebind di dnsmasq rifiuta le risposte con indirizzo privato idonee ricevute dall'esterno e le registra quando lo fa. Quella protezione esiste per un buon motivo: un nome pubblico che all'improvviso risolve verso un indirizzo privato è il classico attacco di rebinding. Si interseca però anche con un servizio volutamente privato, che è il tuo caso.
Cerca il rifiuto nel log prima di cambiare qualsiasi cosa, perché il messaggio nomina il meccanismo.
Se non c'è rifiuto e nessuna risposta a monte, la protezione anti-rebinding non è il tuo problema, e disattivarla sarebbe una modifica che non risolve nulla e amplia l'esposizione. È peggio del guasto originale, perché toglie un controllo e lascia il difetto. Conferma prima la riga di log specifica. Poi decidi.
Limita l'eccezione a un solo dominio
Per un dominio verificato, il manuale di dnsmasq offre un'eccezione limitata al dominio invece di un interruttore globale.
rebind-domain-ok=corp.example
Il dominio qui sopra è solo illustrativo. Usa il dominio amministrativo che gestisci davvero e comprendi l'ambito di corrispondenza dell'opzione prima di applicarla, perché una regola di suffisso copre più dell'unico host provato. Il generatore di configurazione di un router può esporre la stessa impostazione tramite il proprio controllo invece che con una direttiva grezza. Entrambe le strade vanno bene purché l'ambito risultante sia quello voluto.
Un'eccezione al rilevamento di rebinding fa esattamente una cosa: lascia passare le risposte di quel dominio.
Non configura un forwarder split-DNS, né rende raggiungibile un monte irraggiungibile, né crea una rotta verso l'indirizzo restituito. Ognuno di questi è un requisito separato con la propria firma di guasto, e ognuno fallisce in modo diverso nel client.
Verifica senza rimuovere il confine
Interroga di nuovo il nome host attraverso il percorso di inoltro, poi connettiti al servizio con i suoi normali controlli di identità. Un'eccezione DNS non è un motivo per accettare un certificato inatteso, e i due guasti sono facili da confondere quando entrambi si presentano come errore del browser. Prova il nome e il servizio separatamente. Solo uno dei due è mai stato un problema DNS.
Conserva il motivo dell'eccezione accanto alla configurazione, con una data e un responsabile.
Ricontrollala quando il servizio privato si sposta o il dominio cambia. Disattivare la protezione a livello globale cambierebbe il trattamento delle risposte non correlate e lascerebbe comunque in piedi il guasto di rotta o di servizio se il rebinding non è mai stato la causa.