DNS լուծիչի մատյանները և VPN կապի մատյանները՝ ինչ է պահում յուրաքանչյուրը
Լուծիչը գրանցում է այն անունները, որոնց պատասխանելու համար իրեն խնդրել են. VPN-ը գրանցում է թունելի իրադարձությունները սեփական իրականացումից։ Մեկ պահպանման քաղաքականությունը չի ծածկում մյուսը։
DNS լուծիչի մատյանը և VPN կապի մատյանը երկուսն էլ ցանցային գրանցումներ են, երկուսն էլ օգտակար և փոխարինելի չեն։ Լուծիչը ստանում է այն անունները, որոնց պատասխանելու համար իրեն խնդրել են։ VPN-ի վերջնակետը զբաղվում է թունելային կապերով և գրանցում է այն, ինչ իր իրականացումը որոշել է գրանցել դրանց մասին։ Նրանք կարող են լինել նույն շենքում, կառավարվել նույն թիմի կողմից և ընդգրկվել նույն գաղտնիության ծանուցմամբ, և այնուամենայնիվ նկարագրում են տարբեր իրադարձություններ տարբեր նույնացուցիչներով և տարբեր պահպանմամբ։ Մեկը մյուսի տեղը կարդալն այն ճանապարհն է, որով հետաքննությունները շեղվում են։
Երկու մատյան, երկու իրադարձություն
Լուծիչի գրառումը պատասխանում է անվանման մասին հարցին. այս հաճախորդը այս պահին խնդրել է այս անունը, և պատասխանը սա էր։ VPN-ի գրառումը պատասխանում է կապակցվածության մասին հարցին. այս գործընկերը ստեղծել կամ կորցրել է թունել, նրան տրվել է այս հասցեն, և նա փոխանցել է մոտավորապես այսքան տվյալ մինչև հեռանալը։ Նրանցից ոչ մեկը HTTPS սեսիայի ներսում օգտատիրոջ արածի գրառում չէ, և ոչ մեկը չի փոխարինում մյուսին։
Այս տարբերությունը գործնական հետևանք ունի խոստումների համար։ Այն պնդումը, որ VPN մատակարարը չի գրանցում թունելի ակտիվությունը, ոչինչ չի ասում այն լուծիչի մասին, որը նա տրամադրում է, իսկ լուծիչի պահպանման քաղաքականությունը ոչինչ չի ասում այն մասին, թե ով է միացել թունելին։ Յուրաքանչյուր պնդում պատկանում է իր օպերատորին և իր համակարգին։
Հետևեք հարցմանը նախքան մատյաններից որևէ մեկը կարդալը
Հարցումը հասնում է լուծիչին միայն այն դեպքում, երբ ուղին իսկապես հարցնում է նրան։ Հավելվածը կարող է օգտագործել օպերացիոն համակարգի լուծիչը, գործարկել իր սեփական գաղտնագրված DNS հաճախորդը, կամ կարդալ պահված պատասխան և երբեք ոչինչ չուղարկել։ Ուստի լուծիչի մատյանը, որը ոչինչ չի ցույց տալիս, ապացույց չէ, որ անունը երբեք չի օգտագործվել. դա ապացույց է, որ այս լուծիչին չեն հարցրել։
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerԱյդ վերջին հրամանը կարդում է տեղական լուծիչի սեփական մատյանը, ինչը նույնը չէ, ինչ վերին սերվերի մատյանը։ Եթե ձեր հարցումները դուրս են գալիս DNS over HTTPS-ով դեպի մատակարար, տեղական stub-ը կարող է ոչինչ չցուցադրել, մինչ մատակարարն ունի ամբողջական գրառումը, և մատակարարը այլ օպերատոր է այլ քաղաքականությամբ։
Ինչ կարող է և ինչ չի կարող ցույց տալ յուրաքանչյուր գրառում
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
Դրանց միացումն է իսկական աշխատանքը, և միացումը միշտ հնարավոր չէ։ Հաճախորդների հասցեները գրանցող լուծիչը կարելի է համեմատել VPN-ի հետ, որը հասցեներ է տրամադրում հայտնի լողավազանից, և այդ համեմատությունը հավանական կապ է ստեղծում հարցված անվան և թունելի միջև, որը մնում է կապ երկու գրառումների միջև, ոչ թե անձի գրառում։
Գաղտնագրված DNS-ը փոխում է տրանսպորտը, ոչ թե տեսանելիությունը վերջնակետում։ Լուծիչը դեռ ստանում է այն հարցը, որին պատասխանում է, ինչպես RFC 8484 է պարզաբանում, և այդ լուծիչում պահպանումը քաղաքականության որոշում է, ոչ թե արձանագրության հատկություն։
Որտեղ բաժանված DNS-ը և քեշերը շփոթում են պատմությունը
Մի քանի լուծիչ նորմալ է։ Բաժանված DNS-ի ձևավորումը ներքին անունները ուղարկում է ներքին սերվեր, իսկ մնացածը՝ հանրային, ուստի մեկ հետաքննություն կարող է ընդգրկել երկու մատյան, որոնք երբեք նախատեսված չեն եղել միավորելու, և երկու պահպանման կարգավորում, որոնք երբեք նախատեսված չեն եղել համեմատելու։ Երկուսում էլ հարցումներ տեսնելը ապացույց է, որ ձևավորումն աշխատում է, ոչ թե արտահոսքի ապացույց։
Քեշերը կտրում են հակառակ ուղղությամբ։ Հայտնի անվանը կարող են ժամերով պատասխանել քեշից, ուստի լուծիչի գրառումը ցույց է տալիս առաջին հարցումը և հետո ոչինչ, մինչ օգտատիրոջ հավելվածը ուրախ շարունակում է լուծել նույն անունը։ Որոշակի ժամանակից հետո գրառումների բացակայությունը չի նշանակում, որ այդ ժամանակից հետո ոչ ոք չի օգտագործել անունը։
Ֆոնային երթևեկությունը երրորդ աղավաղումն է։ Հեռախոսը, որը միանալիս լուծում է հեռաչափության անուն, դիտարկիչը, որը լուծում է որոնման առաջարկի տիրույթ, և թարմացնողը, որը կապվում է ամեն ժամ, բոլորը հայտնվում են լուծիչի մատյանում ձեզ իսկապես հետաքրքրող անվան կողքին։ Այդ մատյանի ծավալը ուշադրություն չէ, և հարցումները հաշվելը այցերը հաշվել չէ։ Լուծիչի մատյանը հարցերի գրառում է, և հարցեր ստեղծելը էժան է։
Պահպանման հարցերը տվեք առանձին
Յուրաքանչյուր համակարգի համար տվեք երեք հարց՝ ով է հավաքում, ինչ է հավաքվում, և որքան ժամանակ է այն պահվում։ Ապա հարցրեք, թե ով կարող է կարդալ այն և ինչ ընթացակարգով։ RFC 8484-ի քննարկումը DNS over HTTPS-ի մասին լավ հիշեցում է, որ գաղտնագրված տրանսպորտը չի վերացնում վերջնակետը, և օպերատորի սեփական փաստաթղթերը միակ վստահելի պնդումն են այն մասին, թե ինչ է պահում այդ վերջնակետը։
Երբ գաղտնիության մասին պնդում է արվում «VPN»-ի վերաբերյալ, նախքան այն ընդունելը բաժանեք բաղադրիչների՝ թունելի օպերատորը, թունելի տրամադրած լուծիչը, ցանկացած վերին լուծիչ, որին հասնում են այդ հարցումները, և սարքի հավելվածները։ Յուրաքանչյուրն ունի իր պատասխանը, և մեկի համար ճշգրիտ պնդումը սովորաբար կրկնվում է այնպես, կարծես ծածկում է բոլոր չորսին։
Անսարքությունների վերացման համար օգտագործեք նույն բաժանումը։ Հարցրեք, թե որ հավելվածն է կատարել հարցումը և որ լուծիչն է պատասխանել, ապա նայեք այն մատյանին, որն իսկապես պատկանում է այդ իրադարձությանը։ Մյուս մատյանից գուշակելը խնայում է մեկ րոպե և արժենում է մեկ կեսօր։