DNS-ը TLS-ի վրայով և VPN. որ մասն է պաշտպանված

DNS-ը TLS-ի վրայով գաղտնագրում է հաճախորդի և նրա ընտրած resolver-ի միջև փոխանակումը, և resolver-ը դեռ կարդում է անունը։ Այս նախադասությունը լուծում է DoT-ի և VPN-ի շուրջ եղած շփոթության մեծ մասը։ Թունելը որոշում է, թե գաղտնագրված հարցումն ինչ ճանապարհով է գնում, մինչդեռ resolver-ը դեռ իմանում է, թե ինչ է հարցվել։ Ոչ մի մեխանիզմ չի փոխարինում մյուսին, և ոչ մեկը մյուսին ավելորդ չի դարձնում։

Չորս ստուգում են որոշում՝ արդյոք ձեր ունեցած դասավորությունը այն է, ինչ դուք կարծում եք, թե ունեք։

Ստուգում 1. ինչ է ծածկում գաղտնագրումը

DoT-ը DNS փոխանակումը փաթաթում է TLS-ի մեջ, այնպես որ ուղու վրա գտնվող դիտորդը տեսնում է կապ հասցեի և պորտի հետ, այլ ոչ թե անուն հարցման մեջ։ Resolver-ն ինքն է ապակոդավորում և պատասխանում։ Համեմատեք HTTPS-ի վրայով DNS-ի հետ. երկուսն էլ գաղտնագրում են, և նրանք օգտագործում են տարբեր տրանսպորտներ, ուստի ցանցը, որը թույլատրում է վեբ երթևեկություն, ինքնաբերաբար չի թույլատրում DoT կապ։

Այս տարբերությունը կարևոր է, երբ գերեվարման պորտալը կամ զտող միջանկյալ բլոկը թույլատրում է 443-ը և արգելափակում 853-ը։ Այնտեղ աշխատած գործիքը ապացույց չէ, որ մյուսը կաշխատի։

Ստուգում 2. ինչ ուղիով է գնում հարցումը

Ուղին հաճախորդի քաղաքականության հարց է։ DoT resolver-ին կարելի է հասնել թունելի միջով, դրանից դուրս, կամ ցանցի հետ փոփոխվող ճանապարհով։ Որը տեղի կունենա, կախված է ուղիներից և նրանից՝ արդյոք հաճախորդը պաշտպանում է իր DNS սոկետը։ Ամբողջ երթևեկությունը որսացող թունելը սովորաբար հարցումը տանում է իր հետ, ինչ էլ ասի resolver-ի հասցեն։

Թեստում երրորդ կողմի resolver-ի հասցե տեսնելը չի ապացուցում շրջանցում, և գաղտնագրում տեսնելը չի ապացուցում նախատեսված ստացողին։ Կարդացեք resolver-ը և ուղին առանձին, ապա որոշեք՝ արդյոք զույգը ձեր նախագծածն է։

Ստուգում 3. ներքին անուններ

Ներքին անուններ հրապարակող կազմակերպությանը պետք է resolver, որը պահում է այդ գրառումները։ Հանրային DoT ծառայությունը չի ճանաչում ձեր մասնավոր անվանատարածքը, և հաճախորդին դրան ուղղելը երաշխավորում է, որ այդ անունները կձախողվեն։ Սա ամենատարածված գործնական անկումն է, երբ ինչ-որ մեկը միացնում է գաղտնագրված DNS-ը կառավարվող սարքում։

Պահեք ներքին resolver-ը ներքին վերջավորությունների համար և գաղտնագրեք այդ թռիչքը, եթե քաղաքականությունը պահանջում է, փոխարենը այն հանրային մատակարարով փոխարինելու։

Ստուգում 4. ձախողման վարքը

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

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

Վստահեք վկայագրին, ոչ պատասխանին

Օգտագործեք ծառայության համար փաստաթղթավորված մատակարարի հոսթի անունը և ստուգաչափման կարգավորումը։ TLS ստուգումներն անջատելը, որպեսզի անծանոթ resolver-ը պատասխանի, ձեզ տալիս է գաղտնագրված ալիք դեպի չստուգված վերջնակետ, ինչը մի կոնկրետ առումով ավելի վատ է, քան փոխարինված սովորական հարցումը. այն անվտանգ է թվում։ DNS-ը TLS-ի վրայով բնութագիրը ներկայացնում է այդ ստուգման հետևում եղած նույնականացման ակնկալիքը։

Resolver-ից ստացված պատասխանը, որը չեք կարող նույնականացնել, պնդում է, ոչ արդյունք։

Ինչ է սա թողնում չբացատրված

DoT-ը անունը չի թաքցնում resolver-ից, կապի նպատակակետ հասցեն չի թաքցնում ցանցից, և չի որոշում՝ արդյոք հարցումն անցել է թունելով։ Դրանք երեք առանձին հարցեր են՝ երեք առանձին պատասխաններով։

Գրեք resolver-ի ինքնությունը, տրանզիտ ուղին և ներքին անունների քաղաքականությունը որպես երեք տող։ Հաջորդ DNS հարցը, որ կստանաք, դրանցից մեկը կլինի։