NXDOMAIN-ը VPN-ի վրայով չի նշանակում թունելի ընդհատում

Գայթակղիչ է մեկ անհաջող որոնումը կարդալ որպես թունելի փլուզման ապացույց, հատկապես երբ անունը աշխատում էր տասը րոպե առաջ։ Պատասխանն այլ բան է ասում։ NXDOMAIN-ը ավարտված DNS գործարք է, որում լուծիչը հայտարարել է, որ հարցված անունը գոյություն չունի; կոտրված թունելը սովորաբար առաջացնում է լռություն, ժամանակի սպառում կամ լուծման փորձ սխալ սերվերի դեմ։ Փաստարկի՝ wireshark-ից զուրկ տարբերակը մեկ հարցում է, մեկ պատասխանող և մեկ պատասխանի կոդ, և այդ եռյակը արժե արձանագրել ցանկացած կարգավորման փոփոխությունից առաջ։

Ինչ է իրականում ապացուցում պատասխանը

DNS-ը բաժանում է արդյունքները, որոնք հաճախորդները հաճախ միավորում են մեկ ձախողման մեջ։ Գոյություն չունեցող անունը տալիս է բացասական պատասխան NXDOMAIN կոդով, մինչդեռ գոյություն ունեցող, բայց պահանջված տիպի գրառում չունեցող անունը տալիս է հաջող պատասխան դատարկ պատասխանի բաժնով։ Երկուսն էլ հավելվածին թվում են անօգուտ, և դրանցից միայն մեկն է նշանակում, որ անունը սխալ է։

Այդ տարբերությունը որոշում է, թե որտեղ է պատկանում վերանորոգումը։ A գրառում ունեցող հոսթի վրա բացակայող AAAA գրառումը բացակայող հոսթ չէ, և վկայականը նորից թողարկելը կամ թունելը վերակառուցելը՝ դրա հետևից ընկնելու համար, վատնում է միակ հասանելի հուշումը։ Տարբերությունը նաև որոշում է շարունակության ձևը. անվանման խնդիրը ուղղվում է զոնայում, իսկ տիպի խնդիրը ուղղվում է ճիշտ գրառումը հարցնելով կամ ընդունելով, որ հասցեների ընտանիքը պարզապես բացակայում է։

Առասպելը. բացակայող մասնավոր անունը նշանակում է, որ թունելը ձախողվել է

Առասպելը ապրում է, որովհետև այդ երկու իրադարձությունները շատ հաճախ գալիս են միասին։ Հաճախորդը միանում է VPN-ին, օպերացիոն համակարգը պահում է լուծիչ, որին արդեն վստահում էր, և ներքին անունը, որն այժմ պետք է, հարցվում է սերվերից, որը երբեք չի լսել մասնավոր զոնայի մասին։ Այդ սերվերը պատասխանում է ազնվորեն և բացասաբար։ Թունելը կրում է փաթեթը. պատասխանը պարզապես անվանատարածքի մասին է, որը պատասխանողը չի սպասարկում։

Split-horizon կարգավորումները սա դարձնում են սովորական. նույն զոնայի անունը գոյություն ունի հրապարակայնորեն և ներքուստ տարբեր բովանդակությամբ, և միայն ներքին լուծիչը գիտի մասնավոր գրառումները։ Ուստի հեղինակավոր թվացող բացասական պատասխան ստանալը ապացույց է այն մասին, թե որ լուծիչը պատասխանեց, ոչ թե ինտերֆեյսի վիճակի ապացույց։

Երկու կարգավորման մանրամասնություն է որոշում արդյունքը։ Թունելը պետք է մղի կամ ընտրի ներքին լուծիչը, և հաճախորդը պետք է այդ ընտրությունը կիրառի փնտրվող անվան վրա։ Յուրաքանչյուր դոմենի կանոնը, որը նշում է ձեր մուտքագրած գրառումից փոքր-ինչ տարբերվող վերջածանց, հարցումը կուղարկի հրապարակային ուղի, և պատասխանը կլինի ճիշտ ու անօգուտ։

Հարցրեք ճիշտ լուծիչին ճիշտ անունով

Արձանագրեք պատասխանողին նախքան վճիռը արձանագրելը։ Որոնումը, որը չի ցույց տալիս, թե որ սերվերն է պատասխանել, չի կարող տարբերել քաղաքականության խնդիրը անվանատարածքի խնդրից, և երկուսի ուղղումները կապ չունեն։

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

Առաջին երկու տողերը ցույց են տալիս, թե տեղական լուծիչը ինչ որոշեց և ումից կհարցնի։ +search որոնումը վերարտադրում է այն, ինչ անում է հավելվածը, երբ ավելացնում է որոնման վերջածանց, ինչը հաճախ իրական հարցումն է, այլ ոչ թե ախտորոշիչ գործիքի մեջ մուտքագրվածը։ Վերջին տողը ուղղակիորեն հարցնում է ներքին սերվերին՝ շրջանցելով հաճախորդի քաղաքականությունը. եթե դա հաջողվում է, մինչ սովորական որոնումը ձախողվում է, զոնան կարգին է, իսկ հարցումների երթուղավորումը՝ ոչ։

Բացասական քեշավորումը բացատրում է ուղղումից հետո ուշացումը

Բացասական պատասխանները քեշավորվում են ըստ նախագծի, և RFC 2308-ը նկարագրում է, թե ինչպես է բացասական քեշի կյանքի տևողությունը ստացվում զոնայի հեղինակության գրառումից։ Ուստի գրառում կամ լուծիչի կանոն ուղղելը չի երաշխավորում անմիջական փոփոխություն հաճախորդի մոտ, և քեշավորված պատասխանը շարունակ վերադարձնող որոնումը կրկնելը ոչ մի նոր բան չի ապացուցում։ Միայն այլ պատասխանող, այլ անուն կամ մաքրված քեշ է տալիս թարմ ապացույց։

Մաքրեք տեղական քեշը, ապա կրկնեք նույն հարցումը նույն պատասխանողին ուղղված։ Տեղական լուծիչի ծառայություն օգտագործող համակարգերում դա մեկ հրաման է. մյուսներում դա ծառայության վերագործարկում է կամ հարթակի գործիք, և կոնկրետ գործիքը ավելի քիչ կարևոր է, քան դրանից հետո նույնական թեստի կրկնությունը։

Առանձնացրեք անունը ուղուց

Երբ անունը լուծվում է սպասված մասնավոր հասցեի, DNS-ը որպես թեմա ավարտված է, և հաջորդ հարցը դառնում է հավելվածի ուղին։ Այն հոսթը, որը պատասխանում է որոնումներին, բայց մերժում է միացումը, այլ խնդիր ունի, և ճիշտ պատասխանից հետո լուծիչները շարունակ կարգավորելը այն ձևն է, որով միջադեպը ձեռք է բերում երեք անկապ փոփոխություն։ Համեմատեք լուծված հասցեն այն հասցեի հետ, որի վրա ծառայությունը իրականում լսում է, նախքան ենթադրելը, որ երկուսը համընկնում են։

Պահեք արձանագրությունը՝ հարցումը, պատասխանողը, կոդը և լուծված հասցեն։ Այդ գրառումն է, որ ավելի ուշ զեկույցը դարձնում է ստուգելի, և դա է տարբերությունը ախտորոշման և դանդաղ թվացող թունելի մասին պատմության միջև։