dnsmasq viskab kõrvale privaatse DNS-vastuse: kas süüdi on rebinding-kaitse?

Ettevõtte DNS-server tagastab oodatud privaatse aadressi, ja siiski ebaõnnestub päring läbi kohaliku edastava resolveri. Vastus on olemas, mis välistab ülemise tsooni ja kirje enda. Järele jääb samm, kus resolver otsustab, kas vastus kliendile tagastada. Kui see resolver on dnsmasq, on tagasilükkamine tõenäoliselt juba logis.

Vastuse saamine ja selle tagastamise valimine on kaks eri sammu.

Võrrelge sama nime mõlemas resolveris

Kirjutage üles, millist resolverit rakendus tegelikult kasutab, ja täpne hostinimi, mida see küsib. Seejärel võrrelge ülemist tulemust edastava resolveri sündmusega sama nime kohta. Puuduv ülemine vastus, vahemällu salvestatud eitav vastus ja logitud tagasilükkamine nõuavad kolme erinevat parandust.

Otseses diagnostikapäringus nähtav aadress ei tõenda, et rakendus sai selle oma tavalisel teel. Kaks päringut võivad väljuda erinevatest resolveritest või samast resolverist erinevate reeglitega. Kirjutage mõlemad tulemused üles enne teooriate loomist, sest just selles sammus asendatakse üks teisega. Võrdlus on kogu diagnoos.

Lugege tagasilükkamist, mitte sümptomit

Valik stop-dns-rebind dnsmasqis lükkab tagasi sobilikud privaatse aadressiga vastused, mis tulevad ülevalt, ja logib need, kui seda teeb. Sellel kaitsel on hea põhjus: avalik nimi, mis äkki osutab privaatsele aadressile, on klassikaline rebinding-rünne. See ristub ka tahtlikult privaatse teenusega, ja see on teie juhtum.

Enne millegi muutmist otsige logist tagasilükkamist, sest teade nimetab mehhanismi.

Kui tagasilükkamist ega ülemist vastust ei ole, ei ole rebinding-kaitse teie probleem, ja selle väljalülitamine oleks muudatus, mis ei paranda midagi ning suurendab kokkupuudet. See on hullem kui algne rike, sest eemaldab kontrolli ja jätab defekti alles. Kõigepealt kinnitage konkreetne logirida. Seejärel otsustage.

Piirake erand ühe domeeniga

Kinnitatud domeeni jaoks pakub dnsmasqi käsiraamat domeeniga piiratud erandit, mitte üldist lülitit.

rebind-domain-ok=corp.example

Ülaltoodud domeen on vaid näide. Kasutage haldusdomeeni, mida te tegelikult haldate, ja enne valiku rakendamist mõistke selle sobivusulatust, sest sufiksi reegel katab rohkem kui ühe testitud hosti. Ruuteri konfiguratsioonigeneraator võib sama seade oma juhtseadme kaudu pakkuda, mitte toore direktiivina. Mõlemad teed on head, kui tulemuseks olev ulatus on kavandatu.

Erand rebinding-tuvastusest teeb täpselt ühte: laseb selle domeeni vastused läbi.

See ei seadista split-DNS-edastajat, ei tee kättesaamatut ülemist allikat kättesaadavaks ega loo marsruuti tagastatud aadressile. Iga neist nõuetest on eraldi, sellel on oma rikke tunnus, ja igaüks avaldub kliendis erinevalt.

Kontrollige piiri eemaldamata

Küsige hostinime uuesti edastusteel ja seejärel ühenduge teenusega selle tavapäraste identiteedikontrollidega. DNS-erand ei ole põhjus ootamatut sertifikaati aktsepteerida, ja neid kahte riket on lihtne segi ajada, kui mõlemad ilmnevad brauseriveana. Testige nime ja teenust eraldi. Ainult üks neist oli kunagi DNS-probleem.

Hoidke erandi põhjus konfiguratsiooni kõrval, kuupäeva ja vastutajaga.

Kontrollige seda uuesti, kui privaatne teenus kolib või domeen muutub. Kaitse üldine väljalülitamine muudaks seotud mitteolevate vastuste käsitlemist ja jätaks marsruudi või teenuse rikke ikkagi alles, kui rebinding ei olnud kunagi põhjus.