Ո՞վ է վարում 1.1.1.1-ը։ DNS հասցեի ստուգումը վստահելուց առաջ
VPN-ի հետ օգտագործվող DNS հասցեն պարտադիր չէ, որ կառավարվի այդ VPN-ի կողմից։ Բացահայտեք լուծիչը, ապա առանձին ստուգեք ուղին և մասնավոր անունների քաղաքականությունը։
Դուք տեղադրեցիք 1.1.1.1-ը VPN-ի DNS դաշտում, էջը բեռնվեց, և ձեռնարկը հիմա հաստատված է թվում։ Այդ դիտարկումն ավելի նեղ է, քան թվում է. հավելվածն այլ կերպ վարվեց, և փոփոխությունը դեռ ոչինչ չի ասում այն մասին, թե ով պատասխանեց հարցմանը կամ ինչու ձախողվեց հին կարգավորումը։ Արտագրած ձեռնարկը հաճախ հայտնի հանրային հասցեն անվանում է «VPN-ի DNS», և դա սեփականության մասին պնդում է, ոչ թե հասանելիության։ Ստուգելը, թե ինչ է ներկայացնում հասցեն, տևում է հինգ րոպե և կանխում է սխալ պատճառով արված մշտական փոփոխությունը։
Աշխատող կարգավորումը ինքնություն չէ
Կարգավորումների դաշտի հասցեն վերջնակետ է, և վերջնակետն ունի օպերատոր։ Այս երկու փաստերն առանձին են, և երկրորդն այն է, որ մարդիկ բաց թողնում են։ Ամենահաճախ արտագրվող զույգի համար պատասխանը հանրային է. Cloudflare-ը հրապարակում է 1.1.1.1 և 1.0.0.1 որպես իր լուծիչի հասցեներ և թվարկում դրանք իր պաշտոնական հասցեների տեղեկատուում։ Այդ պատճառով օպերատորի անունը տեղ ունի հասցեի կողքին, ոչ թե առանձին ձեռնարկում։
Այդ զույգը մուտքագրելը, երբ թունելը միացած է, VPN ընկերությանը չի դարձնում դրա օպերատորը և երթևեկությունը չի դարձնում անանուն։ Հարցումը թողնում է ձեր մեքենան՝ ուղղվելով ընկերությանը, որը հրապարակում է հասցեների տիրույթը, և այդ ընկերությունը կարող է հեղինակավոր լինել և այնուամենայնիվ չլինել այն կողմը, որին ակնարկում էր ձեռնարկը։ Հրահանգների պիտակը և իրական օպերատորը տարբեր պնդումներ են։ Ոչ մեկը չի ասում, թե ով է վարում միջանկյալ ցանցային ուղին։
Օգտագործեք լուծիչի սեփական հրապարակված տեղեկատուն՝ հասցեազույգը կամ գաղտնագրված վերջնակետը հաստատելու համար։ Այլ մատակարարի առաջարկությունը կարող է օրինական լինել, և «առաջարկված է», «հասանելի է միջոցով» ու «կառավարվում է» դեռ նկարագրում են երեք տարբեր հարաբերություն։
Համեմատեք երեք բաները, որոնք գրառմանը պետք են
Վերանայման պատրաստ գրառումը բաժանում է երեք հարց. ով պետք է ստանա հարցումը, արդյոք փոխանակումը բաց է, թե գաղտնագրված, և որ ուղին պետք է տանի այն։ Մատակարարի անունը չի կարող լրացնել երկրորդը կամ երրորդը, և երկրի պիտակը չի կարող լրացնել դրանցից ոչ մեկը։ Գրեք երեք գրառումները փոփոխությունից առաջ և համեմատեք դրանք հետո։ Այդ գրառումները փոխանակելի չեն, և դրանք որպես մեկը դիտարկելը այն ճանապարհն է, որով ենթադրությունը դառնում է փաստաթուղթ։
Համեմատությունն է, որ աշխատող կարգավորումը դարձնում է փաստաթղթավորված որոշում։ Առանց դրա հաջորդ մարդը ժառանգում է հասցե՝ առանց որևէ պատճառի։ Նախ կարդացեք ստորև բերված աղյուսակի երրորդ սյունակը, որովհետև հենց այնտեղ են իրականում կանգ առնում վստահ բացատրությունների մեծ մասը։
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
Աղյուսակը դիտավորյալ կարճ է։ Դրա իմաստն այն է, որ յուրաքանչյուր գրառում պատասխանում է տարբեր հարցի, և ոչ մի դաշտ միայնակ չի լրացնում բոլոր երեքը։
Տեղական փոխանցիչը թաքցնում է իրական աղբյուրը
Սարքը, որը կարգավորված է օգտագործել իր երթուղղիչը որպես DNS, մատնացույց է անում փոխանցիչին։ Այդ հասցեն նույնականացնում է հարցման հաջորդ ստացողին, ոչ այն լուծիչին, որը վերջում պատասխանում է դրան։ Տեղական stub լուծիչը ավելացնում է նույն լրացուցիչ քայլը, և հեշտ է այն շփոթել իրական բանի հետ, որովհետև այն երևում է յուրաքանչյուր կարգավիճակի արտածման մեջ։
Stub-ը փոխանցում է այն աղբյուրներին, որոնք նույն արտածումը նույնպես թվարկում է, սովորաբար ավելի ներքև։ Կարդացեք ամբողջ շղթան, նախքան օպերատորի մասին որևէ բան եզրակացնելը, որովհետև առաջին տողը ամբողջ պատասխանը չէ։ Հակառակ դեպքում դուք ընդունարանն անվանում եք ընկերություն։
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'Երկրորդ հրամանը օգտագործում է լուծիչի արձագանքային անունը, որտեղ օպերատորը հրապարակում է այն, որպեսզի հաղորդի իր տեսած աղբյուրի հասցեն։ Երրորդը նշում է պատասխանած սերվերը, որը հաճախ ձեր կարգավորած հասցեն չէ։ Համեմատեք բոլոր երեք արտածումները՝ նախքան օպերատոր գրելը։
Գաղտնագրված DNS-ը փոխում է այն, ինչ տեսանելի է, ոչ թե այն, թե ով է տեսնում
DNS over HTTPS-ը և DNS over TLS-ը պաշտպանում են հաճախորդի ու լուծիչի միջև փոխանակումը։ Լուծիչը դեռ կարդում է յուրաքանչյուր անուն, որի մասին հարցնում են, որովհետև պատասխանելը նրա աշխատանքն է։ Ինչ փոխվում է, այն է, թե ով կարող է հետևել փոխանակմանը. տեղական ցանցը տեսնում է կապ մեկ վերջնակետի հետ՝ բաց տեքստի հարցումների հոսքի փոխարեն։
Ինչ չի փոխվում, վստահության հարաբերությունն է, որը դեռ մատնացույց է անում այն կազմակերպությանը, որը վարում է այդ վերջնակետը։ Սեփական անվտանգ DNS կարգավորում ունեցող դիտարկիչը կարող է ամբողջությամբ շրջանցել օպերացիոն համակարգի լուծիչը։ Վերաբերվեք դրանց որպես երկու կոնֆիգուրացիաների, որոնք կարող են չհամընկնել, և ոչ որպես մեկ կարգավորում, որը կիրառվել է երկու անգամ։
Մասնավոր անունները կրկին իրենց որոշումն են պահանջում։ Աշխատանքային թունելը կարող է ընտրված դոմենները ուղղել կազմակերպության լուծիչներին, և դա հանրային ծառայությամբ փոխարինելը կարող է կոտրել ներքին որոնումները կամ ներքին անունները բացահայտել սխալ կողմին։ Ստուգեք դոմենների քաղաքականությունը՝ նախքան ամբողջ ադապտերի կարգավորումները փոխարինելը։
Պահեք դիտարկումը նեղ
Երբ համեմատում եք, պահպանեք հին կոնֆիգուրացիան և միաժամանակ մեկ կարգավորում փոխեք։ Գրանցեք հավելվածը, գործողությունը, լուծիչի քաղաքականությունը և այն, թե արդյոք հանրային և թույլատրված մասնավոր անունները դեռ լուծվում են վերամիացումից հետո։ Երկու փոփոխությամբ համեմատությունը ոչ մեկը չի ապացուցում։ Արդյունքը գրեք այնտեղ, որտեղ հաջորդ մարդը կգտնի այն՝ հենց կարգավորման կողքին։
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comԵթե հավելվածը սկսի աշխատել, պահեք պնդումը այնքան փոքր, որքան թույլ են տալիս ապացույցները։ Այդ փոփոխությունն օգնեց մեկ փորձարկման, և այն ոչինչ չի ասում այն մասին, թե արդյոք նախորդ լուծիչը գործել է վատ հավատով, թե թունելը կոտրված էր, թե մեկ այլ սարքի նույն փոխարինումն է պետք։ Կայուն արդյունքը կոնֆիգուրացիա է, որի օպերատորն ու նպատակը կարող եք բացատրել։