NXDOMAIN tra VPN ne signifas tunelan interrompon

Estas tentante legi unu malsukcesan serĉon kiel pruvon, ke la tunelo kolapsis, precipe kiam la nomo funkciis antaŭ dek minutoj. La respondo diras alie. NXDOMAIN estas finita DNS-transakcio, en kiu solvilo deklaris, ke la demandita nomo ne ekzistas; rompita tunelo kutime produktas silenton, tempolimon aŭ provon de solvado kontraŭ la malĝusta servilo. La versio de la argumento sen wireshark estas unu demando, unu respondanto kaj unu respondkodo, kaj tiu triopo indas esti registrita antaŭ ajnaj agordaj ŝanĝoj.

Kion la respondo fakte pruvas

DNS apartigas rezultojn, kiujn klientoj ofte kunfandas en unu fiaskon. Nomo, kiu ne ekzistas, produktas negativan respondon kun la kodo NXDOMAIN, dum nomo, kiu ekzistas sed havas neniun rikordon de la demandita tipo, produktas sukcesan respondon kun malplena responda sekcio. Ambaŭ aspektas por aplikaĵo kiel nenio utila, kaj nur unu el ili signifas, ke la nomo estas malĝusta.

Tiu diferenco decidas, kie la riparo apartenas. Mankanta rikordo AAAA ĉe gastiganto, kiu havas rikordon A, ne estas mankanta gastiganto, kaj reeldoni atestilon aŭ rekonstrui tunelon por postkuri ĝin malŝparas la solan disponeblan indicon. La distingo ankaŭ difinas la formon de la daŭrigo: nomiga problemo ripariĝas en la zono, kaj tipa problemo ripariĝas per petado de la ĝusta rikordo aŭ per akcepto, ke la adresa familio simple forestas.

La mito: mankanta privata nomo signifas, ke la tunelo fiaskis

La mito pluvivas ĉar la du okazaĵoj tiel ofte alvenas kune. Kliento konektiĝas al la VPN, la operaciumo konservas solvilon, kiun ĝi jam fidis, kaj la interna nomo, kiun ĝi nun bezonas, estas demandata al servilo, kiu neniam aŭdis pri la privata zono. Tiu servilo respondas honeste kaj negative. La tunelo portas la pakaĵon; la respondo simple temas pri nomspaco, kiun la respondanto ne servas.

Split-horizon-aranĝoj igas tion rutina: la sama zona nomo ekzistas publike kaj interne kun malsamaj enhavoj, kaj nur la interna solvilo konas la privatajn rikordojn. Akiri negative aspektan aŭtoritatan respondon estas do pruvo pri tio, kiu solvilo respondis, ne pruvo pri la stato de la interfaco.

Du agordaj detaloj decidas la rezulton. La tunelo devas puŝi aŭ elekti la internan solvilon, kaj la kliento devas apliki tiun elekton al la nomo serĉata. Regulo por unu domajno, kiu nomas sufikson iomete malsaman de la rikordo, kiun vi tajpis, sendos la demandon laŭ la publika vojo, kaj la respondo estos ĝusta kaj senutila.

Demandu la ĝustan solvilon per la ĝusta nomo

Registru la respondanton antaŭ ol registri la verdikton. Serĉo, kiu ne montras, kiu servilo respondis, ne povas distingi politikan problemon de nomspaca problemo, kaj la du havas nerilatajn riparojn.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

La unuaj du linioj montras, kion decidis la loka solvilo kaj kiun ĝi demandus. La serĉo +search reproduktas tion, kion aplikaĵo faras kiam ĝi aldonas serĉan sufikson, kio ofte estas la vera demando anstataŭ tiu tajpita en diagnozan ilon. La lasta linio demandas la internan servilon rekte, preterpasante la klientan politikon; se tio sukcesas dum la ordinara serĉo malsukcesas, la zono estas en ordo kaj la enkursigado de demandoj ne.

Negativa kaŝmemorado klarigas la prokraston post riparo

Negativaj respondoj estas kaŝmemorataj laŭ deziro, kaj RFC 2308 priskribas, kiel la vivdaŭro de la negativa kaŝmemoro deriviĝas de la aŭtoritata rikordo de la zono. Korekti rikordon aŭ solvilan regulon do ne garantias tujan ŝanĝon ĉe la kliento, kaj ripeti serĉon, kiu daŭre redonas la kaŝmemoritan respondon, pruvas nenion novan. Nur alia respondanto, alia nomo aŭ malplenigita kaŝmemoro produktas freŝajn pruvojn.

Malplenigu la lokan kaŝmemoron, poste ripetu la saman demandon al la sama respondanto. Sur sistemoj uzantaj la lokan solvilan servon tio estas unu komando; sur aliaj ĝi estas restarigo de servo aŭ platforma ilo, kaj la konkreta ilo malpli gravas ol ripeti poste identan teston.

Apartigu la nomon de la vojo

Post kiam la nomo solviĝas al la atendata privata adreso, DNS finiĝis kiel temo kaj la aplikaĵa vojo fariĝas la sekva demando. Gastiganto, kiu respondas serĉojn sed rifuzas konekton, havas alian problemon, kaj daŭrigi ĝustigi solvilojn post ĝusta respondo estas kiel okazaĵo akiras tri nerilatajn ŝanĝojn. Komparu la solvitan adreson kun tiu, sur kiu la servo efektive aŭskultas, antaŭ ol supozi, ke la du kongruas.

Konservu la protokolon: la demando, la respondanto, la kodo kaj la solvita adreso. Tiu registro ankaŭ estas tio, kio igas postan raporton kontrolenda, kaj ĝi estas la diferenco inter diagnozo kaj rakonto pri tunelo, kiu ŝajnis malrapida.