dnsmasq forĵetas privatan DNS-respondon: ĉu temas pri rebinding-protekto?

La DNS-servilo de la firmao redonas la atendatan privatan adreson, kaj tamen la peto tra la loka plusendanta solvilo ankoraŭ malsukcesas. La respondo ekzistas, kio ekskludas la superan zonon kaj la rikordon mem. Restas la paŝo, en kiu la solvilo decidas, ĉu redoni tiun respondon al la kliento. Se tiu solvilo estas dnsmasq, la rifuzo probable jam estas en la protokolo.

Ricevi respondon kaj elekti redoni ĝin estas du malsamaj paŝoj.

Komparu la saman nomon en ambaŭ solviloj

Notu, kiun solvilon la aplikaĵo efektive uzas kaj la precizan salutnomon, kiun ĝi demandas. Poste komparu la rezulton de supre kun la okazaĵo de la plusendanta solvilo por la sama nomo. Mankanta respondo de supre, kaŝmemorita nea respondo kaj registrita rifuzo postulas tri malsamajn riparojn.

Adreso videbla en rekta diagnoza peto ne pruvas, ke la aplikaĵo ricevis ĝin laŭ sia kutima vojo. La du petoj povas eliri el malsamaj solviloj, aŭ el la sama solvilo laŭ malsamaj regularoj. Notu ambaŭ rezultojn antaŭ ol teoriigi, ĉar ĝuste en ĉi tiu paŝo oni anstataŭigas unu per la alia. La komparo estas la tuta diagnozo.

Legu la rifuzon, ne la simptomon

La opcio stop-dns-rebind de dnsmasq rifuzas taŭgajn respondojn kun privata adreso venantajn de supre, kaj registras ilin kiam ĝi tion faras. Tiu protekto ekzistas pro bona kialo: publika nomo, kiu subite solviĝas al privata adreso, estas la klasika rebinding-atako. Sed ĝi ankaŭ kruciĝas kun intence privata servo, kaj tio estas via kazo.

Serĉu la rifuzon en la protokolo antaŭ ol ŝanĝi ion ajn, ĉar la mesaĝo nomas la mekanismon.

Se mankas nek rifuzo nek respondo de supre, la rebinding-protekto ne estas via problemo, kaj malŝalti ĝin estus ŝanĝo, kiu riparas nenion kaj plilarĝigas la elmetiĝon. Tio estas pli malbona ol la origina paneo, ĉar ĝi forigas kontrolon kaj lasas la difekton. Unue konfirmu la koncernan protokollinion. Poste decidu.

Limigu la escepton al unu domajno

Por konfirmita domajno, la manlibro de dnsmasq proponas domajn-liman escepton anstataŭ tutmonda ŝaltilo.

rebind-domain-ok=corp.example

La supra domajno estas nur ekzemplo. Uzu la administran domajnon, kiun vi efektive administras, kaj komprenu la kongruan amplekson de la opcio antaŭ ol apliki ĝin, ĉar sufiksa regulo kovras pli ol la unu provizitan gastiganton. La agorda generilo de enkursigilo povas montri la saman agordon per propra regilo anstataŭ per kruda direktivo. Ambaŭ vojoj taŭgas, se la rezulta amplekso estas la intencita.

Escepto al rebinding-detekto faras precize unu aferon: ĝi lasas la respondojn de tiu domajno pasi.

Ĝi ne agordas split-DNS-plusendilon, ne igas atingebla neatingeblan fonton de supre, kaj ne kreas itineron al la redonita adreso. Ĉiu el tiuj estas aparta postulo kun propra panea signo, kaj ĉiu malsukcesas alimaniere en la kliento.

Kontrolu sen forigi la limon

Demandu la salutnomon denove laŭ la plusenda vojo, poste konektiĝu al la servo kun ĝiaj kutimaj identec-kontroloj. DNS-escepto ne estas kialo akcepti neatenditan atestilon, kaj la du paneoj facile konfuziĝas kiam ambaŭ aperas kiel retumila eraro. Testu la nomon kaj la servon aparte. Nur unu el ili iam ajn estis DNS-problemo.

Konservu la kialon de la escepto apud la agordo, kun dato kaj respondeculo.

Rekontrolu ĝin, kiam la privata servo translokiĝas aŭ la domajno ŝanĝiĝas. Tutmonda malŝalto de la protekto ŝanĝus la traktadon de nerilataj respondoj kaj lasus la paneon de itinero aŭ servo surloke, se rebinding neniam estis la kaŭzo.