nslookup diras, ke la servilo estas nekonata: temas nur pri etikedo

Konektu la VPN, rulu nslookup, kaj la kapo montras la adreson de la solvilo kun la nomkampo plenigita per Unknown. Tiu vorto staras super la respondo, kaj plej multaj homoj ĉesas legi antaŭ la grava parto. La etikedo priskribas, ĉu la solvilo havas propran inversan nomon; ĝi ankoraŭ diras nenion pri tio, ĉu la gastignomo, kiun vi demandis, estis solvita. Frua fermo de tiu fenestro estas la tuta lerto ĉi tie.

Du malsamaj demandoj povas produkti tiun montraĵon, kaj nur unu el ili temas pri via problemo. Apartigi ilin kostas unu plian komandon kaj ŝparas posttagmezon da redaktado de DNS-agordoj, kiuj neniam estis malĝustaj.

Kion la ilo faras antaŭ ol respondi al vi

nslookup povas provi trovi nomon por la servila adreso, kiun ĝi baldaŭ uzos, kio estas inversa serĉo en la domajno in-addr.arpa aŭ ip6.arpa. Se tiu PTR-rikmdo mankas, estas filtrita de politiko aŭ simple ne publikigita, la ilo presas Unknown kaj daŭrigas. La antaŭa solvado ne estas tuŝita de tiu malsukceso, ĉar temas pri alia demando sendita al la sama servilo.

Tial privata solvilo povas korekte respondi ĉiun firman nomon kaj tamen aperi anonima en la kapo de la ilo. La adreso estas konata; la nomo malantaŭ ĝi ne, kaj la ilo estas honesta pri tio, kvankam iom teatrema pri la vorto, kiun ĝi elektas.

Rulu la du demandojn intence

Demandu pri gastiganto, kiu gravas al vi, poste demandu pri la propra adreso de la solvilo. La unua peto portas la nomon, kiun vi bezonas; la dua demandas la servilon, ĉu ĝi povas nomi sin. Skribe ili aspektas tiel: nslookup app.corp.example 10.77.0.53 por la gastiganto, kaj nslookup 10.77.0.53 10.77.0.53 por la inversa nomo de la solvilo.

Ambaŭ ekzemploj estas ilustraj, do anstataŭigu ilin per viaj propraj nomoj kaj adresoj. La punkto ne estas la preciza sintakso, sed la apartigo: la du komandoj starigas malsamajn demandojn kaj rajtas produkti malsamajn rezultojn, sen ke iu ajn estas paneo.

Tri rezultoj, kiuj aspektas similaj kaj ne estas

Tempo-limigo signifas, ke neniu respondo alvenis entute, kio indikas atingeblon, filtradon aŭ la malĝustan servilan adreson. Negativa respondo signifas, ke la servilo respondis kaj diris, ke la nomo ne ekzistas, kio indikas la zonon aŭ la sufikson. Mankanta inversa nomo signifas, ke la servilo respondis la duan demandon per nenio utila, kaj la antaŭa respondo eble tamen estis perfekta. Tri rezultoj, tri posedantoj, kaj nur unu el ili temas pri la gastignomo, kiun vi bezonis.

Nur la unuaj du priskribas DNS-vojon, kiu malsukcesas por via aplikaĵo. La tria priskribas rikmdon, kiu neniam estis publikigita, kaj trakti ĝin kiel paneon kondukas al ŝanĝoj, kiuj ne povas ripari ĝin, kiel reverki la serĉan sufikson ĝis la kapo aspektos pli afable.

Legu la sekciojn, ne la kapon

Sub la kapo la ilo presas la respondon, la aŭtoritaton kaj eventualajn pliajn rikmdojn. Ĝusta adreso en la responda sekcio estas la rezulto, kiun vi volis, eĉ kiam la nomo en la kapo estas Unknown. Malplena respondo kun aŭtoritata rifuzo estas alia rezulto kaj meritas propran esploron.

Tenu ambaŭ objektojn eksplicitaj en ĉio, kion vi sendas al subteno: kiun nomon oni demandis, kaj kiun servilon oni demandis. Raportoj, kiuj mencias nur ke DNS estas rompita tra la VPN, devigas la sekvan personon rekonstrui teston, kiun vi jam faris.

Kiam inversa nomo vere gravas

Iuj servoj ja zorgas pri PTR-rikmdoj: protokolado, kiu solvas klientajn adresojn, kontroloj de retpoŝta reputacio, aŭ administraj iloj, kiuj montras nomojn. Se unu el ili malsukcesas, publikigu la rikmdon aŭ riparu la zonon, kiu devus teni ĝin. Tiu laboro estas legitima kaj aparta de la demando, ĉu la VPN plusendas demandojn korekte.

La mallarĝa punkto restas: unu mankanta solvila etikedo ne pruvas, ke la antaŭa solvado tra la tunelo estas rompita, kaj unu funkcianta antaŭa serĉo ne pruvas, ke ĉiu nomo en la zono solviĝas. Testu la nomon, kiun vi efektive bezonas, kaj poste decidu, kiom valoras la vorto en la kapo.