VPN-ի դոմենի կանոնը կոտրվում է, երբ CDN-ը փոխում է իր հասցեները
DNS-ի մեկ պատասխանը պատկեր է պահի մասին, ոչ թե գույքագրում։ Երեք պայման որոշում են՝ արդյոք անվան վրա հիմնված կանոնը կամ հստակ նախածանցը հարմար է CDN-ով աշխատող ծառայությանը։
Դուք հասցեն մեկ հարցումից պատճենում եք ձեր երթուղային կանոնի մեջ, կայքը աշխատում է, և մեկ շաբաթ անց այլևս չի աշխատում։ Կանոնում ոչինչ չի փոխվել։ Ծառայությունը տեղափոխվել է այլ եզրային հասցե, հաճախորդը լուծել է այլ հոսթի անուն, կամ սեսիան անցել է IPv6-ի։ Ձեր առջև դրված որոշումն այն է՝ արդյո՞ք անվան վրա հիմնված կանոնը կամ հստակ միջակայքը ճիշտ գործիքն է այս ծառայության համար, և երեք պայման լուծում են դա։ Հետևյալը բաժանում է անունը հասցեից, որովհետև դրանցից միայն մեկն է կայուն։
Ինչու մեկ հարցումը գույքագրում չէ
Բովանդակության առաքման ցանցը պատասխանում է լուծիչի, տարածաշրջանի և պահի համար ընտրված հասցեով։ Հարցրեք երկու անգամ տարբեր ցանցերից, և կարող եք տարբեր պատասխաններ ստանալ։ Հարցրեք մեկ անգամ և վերաբերվեք պատասխանին որպես ծառայության հասցեների ցանկի, և ձեր գրած կանոնը պատկեր է, ոչ թե կանոն։ Սա է ամբողջ խնդիրը DNS-ի պատասխանը որպես կոնֆիգուրացիա դիտելու հետ։
Կա երկրորդ բացթողում։ Մեկ տեսանելի հոսթի անունը հազվադեպ է ծածկում ամբողջ հավելվածը, որովհետև մուտքը, մեդիան և API-ի երթևեկությունը հաճախ օգտագործում են առանձին անուններ։ Հասցեի տողի հոսթի անունից կառուցված կանոնը կարող է ծածկել էջը և բաց թողնել տեսանյութը, ինչը կարդացվում է որպես մասնակի ձախողում, ոչ թե երթուղային սխալ։
Երրորդ բացթողումը հասցեների ընտանիքն է։ Միայն v4-ի համար կանոնը ոչինչ չի ասում AAAA գրառման մասին, որը հաճախորդը կարող է նախընտրել։
Երեք պայման, որոնք որոշում են դոմենի կանոնը կամ միջակայքերը
Առաջին՝ արդյո՞ք ծառայությունը հրապարակում է նախածանցների կայուն հավաքածու, որը կարող եք ունենալ և փաստաթղթավորել։ Եթե այո, հստակ միջակայքերը ազնիվ են և էժան։ Եթե ոչ, դոմենի կանոնը միակ մեխանիզմն է, որը կարող է հետևել ծառայությանը։
Երկրորդ՝ արդյո՞ք ձեր հաճախորդի դոմենի մեխանիզմը թարմացվում է։ Կանոնը, որը լուծվում է մեկ անգամ միանալիս և այլևս երբեք, պատկեր է ավելի լավ բրենդինգով։ Երրորդ՝ արդյո՞ք մեխանիզմը ծածկում է ենթադոմենները և հասցեների երկու ընտանիքները, թե միայն ձեր մուտքագրած անունները։
Պատասխանեք այդ երեքին, և ընտրությունը սովորաբար ակնհայտ է։ Գուշակությունը ստեղծում է կանոն, որը աշխատում է փորձարկման ժամանակ և ձախողվում է արտադրությունում։
Փորձարկեք սեսիան, ոչ թե էջը
Բեռնեք էջը, ապա կատարեք այն գործողությունը, որը կարևոր է՝ մուտք գործեք, սկսեք նվագարկումը, վերբեռնեք ֆայլ։ Դրանցից յուրաքանչյուրը կարող է հասնել այլ հոսթի, և այն, ինչը ձախողվում է, այն է, ինչը ձեր կանոնը բաց թողեց։
Թվարկեք, թե սեսիան իրականում ինչի հետ է կապվում, այլ ոչ թե ինչ է ցուցադրում էջը:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5Տեսանելի պահեք լուծիչը համեմատության ընթացքում, որովհետև կանոնը, որը աշխատում է մեկ լուծիչից և ձախողվում է մյուսից, պատմում է CDN-ի պատասխանի մասին, ոչ թե թունելի։ Կարճ TTL-ը նաև նշանակում է, որ ձեր գրանցած պատասխանն ունի պահպանման ժամկետ։
Ինչ է իրականում ծածկում յուրաքանչյուր մեխանիզմ
Երկու մեխանիզմները կարգավորումների էջում փոխարինելի են թվում և ներսում տարբեր կերպ են վարվում։
| Mechanism | What it matches | How it fails |
|---|---|---|
| Domain rule | Names the client resolves, then their addresses | Misses subdomains, or goes stale when refresh is off |
| Address route | A prefix you wrote down | Keeps matching an address the service has left |
Միջուկի հասցեի երթուղին համապատասխանեցնում է նախածանցներ։ Այն պատկերացում չունի, թե ինչ է հոսթի անունը, ուստի չի կարող հետևել հասցեները փոխող ծառայությանը։ Դոմենի կանոնը լուծում է անունները և երթուղավորում արդյունքը՝ այն հետևում է ծառայությանը, բայց կախված է լուծիչից, թարմացման վարքից և հաճախորդի՝ ենթադոմենների հետ վարվելու ձևից, ուստի անուններին հետևող կանոնը պետք է փորձարկվի այն լուծիչով, որն իրականում օգտագործում է հաճախորդը։
Ոչ մեկը մյուսի գերբազմությունը չէ, դրա համար էլ դրանք առանց նշումի խառնելը հետագայում շփոթություն է ստեղծում։
Նորից ստուգեք ծառայության փոփոխությունից հետո
Հաճախորդի թարմացումից կամ ծառայության փոփոխությունից հետո նորից գործարկեք նույն սեսիայի թեստը։ Նախկինում աշխատած հասցեների ցանկը վկայություն է այդ ժամանակաշրջանի մասին, ոչ թե ծառայության ենթակառուցվածքի մշտական գույքագրում։
Գրեք, թե որ մեխանիզմն է ծածկում որ հոսթի անունը, և վերջին ստուգման ամսաթիվը։
Այդ նշումը տարբերությունն է այն կանոնի միջև, որը կարող եք պաշտպանել, և այն կանոնի, որին ոչ ոք չի համարձակվում դիպչել։ Եթե ծառայությունը հրապարակում է իր սեփական նախածանցների ցանկը, օգտագործեք այն և նշեք ամսաթիվը։ Եթե ոչ, ասեք դա, և պահեք դոմենի կանոնը՝ իր թարմացման վարքով կողքին գրված։