Արդյո՞ք VPN-ը շտկեց DNS-ը, թե՞ պարզապես օգտագործեց պահված պատասխանը։
Միջանցքի փոփոխությունից հետո բեռնվող էջը կարող է երբեք հարցում չկատարած լինել։ Համեմատեք պահված և թարմ պատասխանները նախքան ուղղումը վերագրելը։
Միջանցքը բարձրանալուց վայրկյաններ անց էջ բացելը ապացույց չէ, որ DNS-ն այժմ աշխատում է, թեև տոմսը սովորաբար այդպես է ասում։ Այդ դիտարկման մեջ ոչինչ հարցում չէր պահանջում. անունը կարող էր լուծվել փոփոխությունից առաջ և կրկին օգտագործվել այնպիսի քեշից, որին միջանցքը երբեք չի դիպել։ Երկու տարբեր թեստեր արտադրում են նույն էկրանը։
Նախքան փոփոխությանը վերագրելը համեմատեք, թե յուրաքանչյուր թեստ իրականում ինչ է վարժեցրել։
Էջ բեռնելը հարցում չէ
Հավելվածի և լուծիչի միջև յուրաքանչյուր շերտ իր կյանքի ընթացքում կարող է հիշել պատասխան։ Օպերացիոն համակարգը պահում է մեկը, զննարկիչը՝ իրենը, և երկարաժամկետ կապ ունեցող հավելվածը կարող է նիստի ընթացքում այլևս ոչինչ չլուծել։ Ուստի միջանցքի փոփոխությունից հետո հաջող բեռնումը կարող է հիշողության, այլ ոչ թե երթուղավորման ցուցադրություն լինել։ Ձախողման բացակայությունը հարցման առկայություն չէ։
Այդ տարբերությունը փոխում է, թե ինչ պետք է փորձարկեք հաջորդիվ։ Եթե նպատակը նոր լուծիչի պատասխանելը ցույց տալն է, ձեզ հարկավոր է հարցում, որը չի կարող սպասարկվել ձեր չմաքրած քեշից։
Պահված հաջողությունը որպես նախկինում անհասանելի սերվերի վերականգնման ապացույց կարդալը այս սխալի ամենաթանկ տարբերակն է, քանի որ այն փակում է միջադեպը կեղծ ենթադրության վրա։
Նախքան եզրակացնելը հաշվեք քեշերը
Չորսը արժե անվանել՝ հավելվածի սեփական լուծումը, օպերացիոն համակարգի հաճախորդային քեշը, զննարկիչի ներքին վիճակը և ցանկացած ռեկուրսիվ լուծիչ, որին հարցումը ի վերջո հասնում է։ Յուրաքանչյուրն ունի առանձին կյանք և մաքրման առանձին եղանակ։ Մեկը մաքրելը և մյուսը փորձարկելը այն ձևն է, որով մարդիկ եզրակացնում են, թե մաքրումը ոչինչ չարեց։ Մեկ մաքրող հրամանը երբեք չի լուծում հարցը։
Բացասական պատասխանները նույնպես պահվում են։ Բացակայող հայտարարված անունը կարող է բացակայող մնալ ցանցը շտկելուց հետո, ինչը կարդացվում է որպես կոտրված միջանցք, մինչդեռ դա TTL է, որը դեռ չի սպառվել։ DNS ճշգրտումը նկարագրում է, թե ինչպես պետք է պահել և կրկին օգտագործել այս տվյալները։
Գրանցեք իրադարձությունը, ոչ թե տպավորությունը
Գրեք, թե երեք բաներից որն է փոխվել՝ գրառումը, լուծիչի ճանապարհը կամ հաճախորդի կարգավորումը։ Գրառման խմբագրումը տարածվում է իր ժամանակացույցով, երթուղու փոփոխությունն ուժի մեջ է մտնում վերամիացման պահին, իսկ զննարկիչի կարգավորումը վերաբերում է միայն այդ զննարկիչին։ Դրանք մեկ առաջ-և-հետո վիճակի մեջ սեղմելը ստեղծում է ժամանակագրություն, որը ոչ ոք չի կարող ստուգել։
Նշեք ժամը, օգտագործված լուծիչը և ստացված պատասխանը, ներառյալ այն դեպքը, երբ պատասխանը բացասական է։ Դա փաստ է, որը ուրիշը կարող է ստուգել։
Համեմատությունը կատարեք երկու անգամ նույն ձևով
Մաքրեք այն քեշը, որը պատրաստվում եք փորձարկել, պահպանեք սկզբնական դիտարկումը, ապա հարցրեք այնպես, որ հնարավորինս շրջանցեք հիշողությունը։ Լուծիչին հստակ անվանելը ձեզ ասում է, թե այդ լուծիչն ինչ գիտի. այն չի ասում, թե որ լուծիչը հավելվածը կընտրեր։
resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example
Windows-ում հաճախորդային քեշի մաքրումը մաքրում է DNS հաճախորդային քեշը և ոչ այլ բան։ Այն չի նկարագրում զննարկիչի մասնավոր վիճակը և չի մաքրում վերին սերվերը, ուստի դրա վրա կառուցված թեստը կարելի է մեկնաբանել միայն նեղ։ Ամեն անգամ արդյունքը հայտնելիս ասեք, թե որ քեշն եք մաքրել։
Այնուհետև նորից փորձարկեք իրական հավելվածը թարմ հարցումով և նախատեսված լուծիչի քաղաքականությամբ ակտիվ վիճակում։ Այլ քաղաքականության ներքո ստացված արդյունքը չի փոխանցվում։