VPN baten bidezko NXDOMAINak ez du tunelaren etetea esan nahi

Tentagarria da huts egindako bilaketa bat tunela erori denaren froga gisa irakurtzea, batez ere izenak hamar minutu lehenago funtzionatzen bazuen. Erantzunak beste zerbait dio. NXDOMAIN osatutako DNS transakzioa da, non resolutzaile batek esan zuen kontsultatutako izena ez dela existitzen; tunel hautsiek isiltasuna, denbora-muga edo zerbitzari okerraren aurkako ebazpen-saio bat sortzen dute normalean. Wireshark gabe argudioaren bertsioa kontsulta bat, erantzule bat eta erantzun-kode bat da, eta hirukote hori merezi du erregistratzea konfigurazioan edozein aldaketa egin aurretik.

Zer frogatzen duen erantzunak benetan

DNSak bezeroek sarritan porrot bakarrera biltzen dituzten emaitzak bereizten ditu. Existitzen ez den izen batek erantzun negatiboa ematen du NXDOMAIN kodearekin, eta existitzen den baina eskatutako motako erregistrorik ez duen izen batek erantzun arrakastatsua ematen du erantzun-atale huts batekin. Biak aplikazio batentzat ezertarako balio ez dutela dirudi, eta horietako batek soilik esan nahi du izena oker dagoela.

Diferentzia horrek erabakitzen du non dagokion konponketak. A erregistroa duen ostalari batean falta den AAAA erregistroa ez da ostalari falta, eta ziurtagiria berriro igortzeak edo tunela berreraikitzeak horren atzetik ibiltzeko eskuragarri zegoen arrasto bakarra alferrik galtzen du. Bereizketak jarraipenaren forma ere ezartzen du: izendapen arazo bat zonen konpontzen da, eta mota arazo bat erregistro egokia eskatuz edo helbide-familia besterik gabe falta dela onartuz konpontzen da.

Mitoa: izen pribatu bat falta bada, tunelak huts egin du

Mitoa bizirik dago bi gertaerak hain sarritan elkarrekin iristen direlako. Bezero bat VPNra konektatzen da, sistema eragileak jada konfiantza zuen resolutzaile bat mantentzen du, eta orain behar duen barneko izena inoiz zona pribatuaz entzun ez duen zerbitzari bati galdetzen zaio. Zerbitzari horrek zintzotasunez eta ezezkaz erantzuten du. Tunelak paketea darama; erantzunak erantzuleak zerbitzatzen ez duen izen-espazio bati buruzkoa besterik ez da.

Horizonte zatituaren ezarpenek errutina bihurtzen dute hau: zona izen bera publikoki eta barnean existitzen da edukiera ezberdinekin, eta barneko resolutzaileak soilik ezagutzen ditu erregistro pribatuak. Beraz, autoritarioa dirudien erantzun negatiboa lortzea zein resolutzailek erantzun zuen jakiteko froga da, ez interfazearen egoeraren froga.

Konfigurazio xehetasun bik erabakitzen dute emaitza. Tunelak barneko resolutzailea bultzatu edo hautatu behar du, eta bezeroak hautapen hori bilatzen ari den izenari aplikatu behar dio. Idatzi duzun erregistroarekiko apur bat desberdina den atzizki bat izendatzen duen domeinu bakoitzeko arauak kontsulta bide publikora bidaliko du, eta erantzuna zuzena eta alferrekoa izango da.

Galdetu resolutzaile egokiari izen egokiarekin

Erregistratu erantzulea epaia erregistratu aurretik. Zein zerbitzarik erantzun zuen erakusten ez duen bilaketak ezin ditu politika arazo bat eta izen-espazio arazo bat bereizi, eta bien konponketak elkarrekin zerikusirik ez dute.

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

Lehen bi lerroek tokiko resolutzaileak zer erabaki zuen eta nori galdetuko liokeen erakusten dute. +search bilaketak aplikazio batek bilaketa-atzizki bat gehitzean egiten duena erreproduzitzen du, eta hori sarritan benetako kontsulta da, tresna diagnostiko batean idatzitakoa ez bezala. Azken lerroak barneko zerbitzariari zuzenean galdetzen dio, bezeroaren politika saihestuz; horrek arrakasta badu kontsulta soilak huts egiten duen bitartean, zona ondo dago eta kontsulten bideratzea ez.

Cache negatiboak konponketa baten ondorengo atzerapena azaltzen du

Erantzun negatiboak diseinuz gordetzen dira cachean, eta RFC 2308 arauak azaltzen du nola cache negatiboaren iraupena zonaren autoritate-erregistrotik eratortzen den. Beraz, erregistro bat edo resolutzaile arau bat zuzentzeak ez du bezeroan berehalako aldaketarik bermatzen, eta cachean gordetako erantzuna itzultzen jarraitzen duen kontsulta errepikatzeak ez du ezer berririk frogatzen. Erantzule desberdin batek, izen desberdin batek edo hustutako cache batek soilik sortzen dute froga freskoa.

Hustu tokiko cachea, eta gero errepikatu kontsulta bera erantzule beraren aurka. Tokiko resolutzaile zerbitzua erabiltzen duten sistemetan komando bat da; besteetan zerbitzuaren berrabiaraztea edo plataformako tresna bat da, eta tresna zehatza garrantzi gutxiagokoa da ondoren proba berdin bat errepikatzea baino.

Bereizi izena bidetik

Izena espero den helbide pribatura ebazten denean, DNSa gai gisa amaituta dago eta aplikazioaren bidea da hurrengo galdera. Ostalari batek bilaketei erantzun baina konexio bat ukatzen badu, beste arazo bat du, eta erantzun zuzen baten ondoren resolutzaileak doitzen jarraitzea da gertaerak elkarrekin zerikusirik ez duten hiru aldaketa lortzeko modua. Alderatu ebatzitako helbidea zerbitzuak benetan entzuten duenarekin biak bat datozela suposatu aurretik.

Gorde transkripzioa: kontsulta, erantzulea, kodea eta ebatzitako helbidea. Erregistro horrek egiten du geroagoko txosten bat egiaztagarri, eta diagnostiko baten eta motela zirudien tunel bati buruzko istorio baten arteko aldea da.