dnsmasq kastar ett privat DNS-svar: är det rebinding-skyddet?

Företagets DNS-server returnerar den förväntade privata adressen, och ändå misslyckas en fråga via den lokala vidarebefordrande resolvern. Svaret finns, vilket utesluter zonen uppströms och själva posten. Kvar är steget där resolvern avgör om den ska lämna tillbaka svaret till klienten. Är den resolvern dnsmasq finns avslaget förmodligen redan i loggen.

Att ta emot ett svar och att välja att lämna tillbaka det är två olika steg.

Jämför samma namn på båda resolvrarna

Anteckna vilken resolver programmet faktiskt använder och det exakta värdnamn det frågar efter. Jämför sedan uppströmsresultatet med den vidarebefordrande resolverns händelse för samma namn. Ett saknat uppströmssvar, ett cachat negativt svar och ett loggat avslag kräver tre olika åtgärder.

En adress som syns i en direkt diagnostisk fråga bevisar inte att programmet fick den via sin vanliga väg. De två frågorna kan utgå från olika resolvrar, eller från samma resolver under olika policyer. Skriv ned båda resultaten innan du teoretiserar, för det är här man byter ut det ena mot det andra. Jämförelsen är hela diagnosen.

Läs avslaget i stället för symptomet

dnsmasqs stop-dns-rebind-alternativ avvisar kvalificerande svar med privata adresser som kommer uppifrån och loggar dem när det gör det. Skyddet finns av goda skäl: ett publikt namn som plötsligt pekar på en privat adress är den klassiska rebinding-attacken. Det krockar också med en avsiktligt privat tjänst, vilket är ditt fall.

Sök i loggen efter avslaget innan du ändrar något, för meddelandet namnger mekanismen.

Om det varken finns avslag eller uppströmssvar är rebinding-skyddet inte ditt problem, och att stänga av det vore en ändring som inte rättar något och samtidigt ökar exponeringen. Det är värre än det ursprungliga felet, eftersom det tar bort en kontroll och lämnar felet kvar. Bekräfta först den specifika loggrader. Bestäm sedan.

Begränsa undantaget till en enda domän

För en verifierad domän erbjuder dnsmasqs manual ett domänbegränsat undantag i stället för en global brytare.

rebind-domain-ok=corp.example

Domänen ovan är bara ett exempel. Använd den administrativa domän du faktiskt driver och förstå alternativets matchningsomfång innan du tillämpar det, för en suffixregel täcker mer än den enda värd du testade. En routers konfigurationsgenerator kan exponera samma inställning via sin egen kontroll i stället för en rå direktiv. Båda vägarna går bra så länge omfånget blir det avsedda.

Ett undantag från rebinding-detektering gör exakt en sak: det släpper igenom den domänens svar.

Det konfigurerar ingen split-DNS-vidarebefordrare, gör inte en onåbar uppström nåbar och skapar ingen rutt till den returnerade adressen. Vart och ett av dessa är ett separat krav med sin egen felsignatur, och varje fel yttrar sig olika i klienten.

Verifiera utan att ta bort gränsen

Fråga värdnamnet igen via vidarebefordringsvägen och anslut sedan till tjänsten med dess vanliga identitetskontroller. Ett DNS-undantag är inte skäl att acceptera ett oväntat certifikat, och de två felen är lätta att blanda ihop när båda visar sig som ett webbläsarfel. Testa namnet och tjänsten var för sig. Bara en av dem var någonsin ett DNS-problem.

Spara skälet till undantaget bredvid konfigurationen, med datum och ansvarig.

Kontrollera det igen när den privata tjänsten flyttar eller domänen ändras. Att stänga av skyddet globalt skulle ändra hur orelaterade svar behandlas och skulle ändå lämna felet i rutt eller tjänst kvar om rebinding aldrig var orsaken.