A VPN-en át érkező NXDOMAIN nem azt jelenti, hogy kiesett az alagút

Csábító egyetlen sikertelen lekérdezést az alagút összeomlásának bizonyítékaként olvasni, különösen ha a név tíz perccel korábban még működött. A válasz mást mond. A NXDOMAIN egy lezárt DNS-tranzakció, amelyben egy feloldó kijelentette, hogy a kérdezett név nem létezik; a törött alagút általában csendet, időtúllépést vagy a rossz kiszolgáló elleni feloldási kísérletet eredményez. Az érv wireshark nélküli változata egy lekérdezés, egy válaszadó és egy válaszkód, és ezt a hármast érdemes rögzíteni minden konfigurációmódosítás előtt.

Mit is bizonyít valójában a válasz

A DNS szétválasztja azokat az eredményeket, amelyeket az ügyfelek gyakran egyetlen hibába mosnak össze. A nem létező név az NXDOMAIN kóddal ad negatív választ, míg a létező, de a kért típusú rekorddal nem rendelkező név sikeres választ ad üres válaszszakasszal. Mindkettő haszontalannak tűnik egy alkalmazás számára, és csak az egyikük jelenti azt, hogy a név hibás.

Ez a különbség dönti el, hová tartozik a javítás. Ha egy gazdagépen van A rekord, a hiányzó AAAA rekord nem hiányzó gazdagépet jelent, és a tanúsítvány újrakibocsátása vagy az alagút újjáépítése, hogy ezt üldözze, az egyetlen rendelkezésre álló nyom elvesztegetése. A különbségtétel a folytatás formáját is meghatározza: a névkezelési problémát a zónában javítják, a típusproblémát pedig a megfelelő rekord kérésével vagy annak elfogadásával, hogy a címcsalád egyszerűen hiányzik.

A mítosz: a hiányzó privát név azt jelenti, hogy az alagút meghibásodott

A mítosz azért él tovább, mert ez a két esemény olyan gyakran érkezik együtt. Az ügyfél csatlakozik a VPN-hez, az operációs rendszer megtart egy feloldót, amelyben már megbízott, és az immár szükséges belső nevet olyan kiszolgálótól kérdezi, amely soha nem hallott a privát zónáról. Az a kiszolgáló őszintén és tagadóan válaszol. Az alagút szállítja a csomagot; a válasz csupán egy olyan névtérről szól, amelyet a válaszadó nem szolgál ki.

A split-horizon elrendezések mindennapossá teszik ezt: ugyanaz a zónanév nyilvánosan és belsőleg is létezik, eltérő tartalommal, és a privát rekordokat csak a belső feloldó ismeri. Ezért a hitelesnek látszó negatív válasz megszerzése arról tanúskodik, melyik feloldó válaszolt, nem pedig az interfész állapotáról.

Két konfigurációs részlet dönti el az eredményt. Az alagútnak át kell tolnia vagy ki kell választania a belső feloldót, és az ügyfélnek ezt a választást a keresett névre kell alkalmaznia. Egy tartományonkénti szabály, amely a beírt rekordtól kissé eltérő utótagot nevez meg, a nyilvános útra küldi a lekérdezést, és a válasz helyes és haszontalan lesz.

A megfelelő feloldót kérdezze a megfelelő névvel

Rögzítse a válaszadót, mielőtt rögzíti az ítéletet. Az a lekérdezés, amely nem mutatja meg, melyik kiszolgáló válaszolt, nem tud különbséget tenni szabályzatprobléma és névtérprobléma között, és a kettő javítása nem függ össze.

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

Az első két sor megmutatja, mit döntött a helyi feloldó, és kit kérdezne. A +search lekérdezés azt utánozza, amit egy alkalmazás tesz, amikor keresési utótagot fűz hozzá, ami gyakran a valódi lekérdezés, nem pedig a diagnosztikai eszközbe beírt. Az utolsó sor közvetlenül a belső kiszolgálót kérdezi, megkerülve az ügyfélszabályzatot; ha ez sikerül, miközben a sima lekérdezés meghiúsul, a zóna rendben van, a lekérdezések útvonalválasztása viszont nem.

A negatív gyorsítótárazás magyarázza a javítás utáni késleltetést

A negatív válaszokat tervezés szerint gyorsítótárazzák, és a RFC 2308 leírja, hogyan származik a negatív gyorsítótár élettartama a zóna hitelesítő rekordjából. Ezért egy rekord vagy egy feloldószabály javítása nem garantál azonnali változást az ügyfélen, és egy olyan lekérdezés megismétlése, amely továbbra is a gyorsítótárazott választ adja vissza, semmi újat nem bizonyít. Csak egy másik válaszadó, egy másik név vagy egy kiürített gyorsítótár ad friss bizonyítékot.

Ürítse ki a helyi gyorsítótárat, majd ismételje meg ugyanazt a lekérdezést ugyanazon válaszadó felé. A helyi feloldószolgáltatást használó rendszereken ez egyetlen parancs; másokon szolgáltatás-újraindítás vagy platformsegédprogram, és a konkrét eszköz kevésbé számít, mint hogy utána megismételjék ugyanazt a tesztet.

Válassza külön a nevet az útvonaltól

Amint a név a várt privát címre oldódik fel, a DNS mint téma véget ér, és a következő kérdés az alkalmazás útvonala lesz. Egy olyan gazdagépnek, amely válaszol a lekérdezésekre, de elutasítja a kapcsolatot, más a problémája, és a feloldók további hangolása egy helyes válasz után az az út, ahogy egy incidens három összefüggőtlen változást szerez. Hasonlítsa össze a feloldott címet azzal, amelyen a szolgáltatás valójában figyel, mielőtt feltételezi, hogy a kettő megegyezik.

Őrizze meg az átiratot: a lekérdezést, a válaszadót, a kódot és a feloldott címet. Ez a feljegyzés az is, ami egy későbbi jelentést ellenőrizhetővé tesz, és ez a különbség a diagnózis és egy lassúnak tűnő alagútról szóló történet között.