Ինչու մասնավոր Route 53 գոտին հանրային անունների համար վերադարձնում է NXDOMAIN

Մասնավոր Route 53 գոտիները փոխարինում են անվան պատասխանը՝ հանրային գրառումի հետ միաձուլվելու փոխարեն, և դա մարդկանց անակնկալի է բերում ամենավատ պահին։ Ավելացրեք մեկ ներքին գրառում api.example.net անվան համար մասնավոր գոտում՝ example.net համար, կապեք այն VPC-ի հետ, և այդ ծնողի տակ գտնվող բոլոր մյուս անուններն այժմ պատասխանվում են միայն մասնավոր գոտուց։ Այն հաճախորդը, որը երեկ կարող էր հասնել www.example.net հասցեին, այսօր ստանում է բացասական պատասխան։ Ստորև տրված ուղեցույցը սկսվում է այդ ձախողված հարցումից և դուրս է գնում դեպի այն գոտին, որը պատասխանեց դրան։

Սկսեք հարցումից, ոչ թե կոնսոլից

Վերարտադրեք խափանումը այն հաճախորդի մոտ, որը հայտնել է այն, և գրանցեք ճշգրիտ անունը և գրառման տեսակը։ Անունը, որը ձախողվում է A տեսակի համար, դեռ կարող է լուծվել AAAA տեսակի համար, և քեշավորված անունը կրկին փորձող զննարկիչը թաքցնում է, թե որն է կոտրվել։ Կատարեք հարցումը երկու անգամ՝ մեկ անգամ այն լուծիչի միջոցով, որն իրականում օգտագործում է հաճախորդը, և մեկ անգամ՝ այն շրջանցող հետագծմամբ։

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

Երկրորդ հրամանն է կարևորը։ Նրա կարգավիճակի տողը և authority բաժինը նշում են այն գոտին, որը ստեղծել է պատասխանը, այնպես որ կարող եք տարբերել մասնավոր գոտուց եկած բացասական պատասխանը ժամանակի սպառումից, արգելափակված պորտից կամ լուծիչից, որը երբեք չի ստացել հարցումը։ resolvectl ցույց է տալիս, թե որ վերին սերվերին է հարցվել, և հաճախ դա այն լուծիչը չէ, որը դուք ենթադրել էիք, թե VPN-ն է ուղարկել։

Եթե հետագծված հարցումը վերադարձնում է հանրային հասցեն, իսկ սովորականը՝ ոչ, ապա հանրային գրառումը անվթար է, և պատասխանում է մասնավոր տեսքը։ Այդ մեկ համեմատությունն է որոշում, թե այս էջի մնացած մասի որ կեսն է ձեզ վերաբերում։

Կարդացեք, թե որ գոտին պատասխանեց

Պատասխանը, որը կրում է NXDOMAIN և authority բաժնում ունի մասնավոր գոտու SOA, այդ գոտու վերջնական պատասխանն է, ոչ թե ձախողված որոնում։ Route 53 Resolver-ը ընտրեց մասնավոր հոսթավորված գոտին, որովհետև անունը համընկավ, ապա չգտավ պահանջված տեսակի գրառում, և փաստաթղթավորված վարքը բացասական պատասխանը վերադարձնելն է՝ հարցը հանրային DNS ուղարկելու փոխարեն։

Ընտրությունը հետևում է յուրահատկությանը։ Երբ մի քանի մասնավոր անվանատարածքներ համընկնում են, հաղթում է առավել յուրահատուկ համընկնող գոտին, և ավելի լայն մասնավոր ծնողը երկրորդ հնարավորություն չի ստանում այն անվան համար, որը ընտրված դուստր գոտին չունի։ Փոխանցման կանոնները ավելացնում են ևս մեկ շերտ, քանի որ տիրույթին հատուկ Resolver կանոնը կարող է հաղթել մասնավոր հոսթավորված գոտու կապակցմանը։ Թվարկեք կապակցումներն ու կանոնները, նախքան եզրակացնելը, որ գոտին դատարկ է։

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Երկու հրամաններն էլ պահանջում են գոտուն տիրապետող հաշվի հավատարմագրեր, իսկ երկրորդին անհրաժեշտ է գոտու ID-ն առաջինից։ Փոխարինեք այն ձեր սեփական ID-ով․ վերևի տեղապահը դիտավորյալ իրական չէ։

Ինչու է հաղթում մասնավոր գոտին

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

Համընկնող անվանատարածքները շփոթության երկրորդ աղբյուրն են։ Մասնավոր գոտի example.net անվան համար և մասնավոր գոտի api.example.net անվան համար երկուսն էլ համընկնում են API հարցման հետ, և պատասխանում է առավել յուրահատուկը։ Դա օգտակար է, երբ ուզում եք նեղ ներքին անվանատարածք, և վտանգավոր, երբ նեղ գոտում բացակայում է գրառում, որն առկա է ավելի լայնում։ Մասնավոր հոսթավորված գոտիների մասին դիտարկումները Route 53 փաստաթղթում նկարագրում են և՛ ներքև անկման վարքը, և՛ կանոնների գերակայությունը, և արժե կարդալ դրանք երկրորդ համընկնող գոտի ավելացնելուց առաջ։

Սրանից ոչինչ չի փոխում հանրային գոտին։ Հանրային լուծիչները դեռ ճիշտ են պատասխանում հանրային գրառումներին, և դրա համար է, որ VPC-ից դուրս գտնվող բոլորի համար խափանումը հաճախորդի խնդիր է թվում։

Ընտրեք անվանատարածքը, նախքան գրառումներ ավելացնելը

Եթե մասնավոր անուններ պետք են միայն ներքին ծառայությունների նոր ընտանիքին, տվեք նրան նվիրված մասնավոր ենթադոմեն և հանգիստ թողեք հանրային ծնողին։ Այնպիսի անուն, ինչպիսին է internal.example.net չի կարող ստվերել www.example.net անվանը, և բացակայող գրառումի ազդեցության շառավիղը սահմանափակվում է այն անուններով, որոնք դուք հորինել եք այդ նպատակով։ Գինը այն է, որ գոյություն ունեցող URL-ները և վկայագրերը կարող են չհամապատասխանել նոր անվանը։

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

Նախքան հաճախորդների բազմությունը մասնավոր տեսք ուղղելը, գույքագրեք այն անունները, որոնք հավելվածն իրականում կանչում է։ Մուտքի հոսթերը, ստատիկ ռեսուրսների հոսթերը, վերահասցեավորման թիրախները և API վերջնակետերը առաջինն են կոտրվում, և դրանք սովորաբար ցրված են մի քանի թիմերի գրառումներում։

Հետևեք լուծիչի ուղուն, ապա՝ երթուղուն

Նոութբուքը մասնավոր տեսքը տեսնում է միայն այն դեպքում, երբ նրա հարցումները հասնում են այն լուծիչին, որն ունի կապակցումը։ VPN սերվերի վրա hosts ֆայլը խմբագրելը ոչինչ չի հրապարակում միացած հաճախորդներին, և հանրային լուծիչով կարգավորված հաճախորդը կշարունակի ստանալ հանրային պատասխաններ, քանի դեռ թունելը բարձրացված է։ Հաստատեք հաճախորդի ստացած լուծիչի հասցեն, ապա կրկնեք հարցումը հաճախորդից, ոչ թե սերվերից։

Երբ անունը լուծվում է, ստուգեք դեպի վերադարձված հասցեն տանող ուղին որպես առանձին քայլ, օրինակ՝ ip route get հրամանով՝ ընդդեմ հարցման վերադարձրած հասցեի։ Ճիշտ մասնավոր պատասխանը՝ առանց հասցեին տանող երթուղու, երթուղավորման խնդիր է, իսկ բացակայող գրառումի մասին պատասխանը՝ DNS տեսքի խնդիր․ դրանք որպես մեկ խնդիր դիտարկելը ստեղծում է ուղղումներ, որոնք չեն դիմանում։ Թողեք ծառայության TLS հոսթի անվան և վկայագրի ստուգումները անփոփոխ, քանի որ մասնավոր հասցեն փոխում է, թե ուր է գնում կապը, և ոչինչ այն մասին, թե որ վկայագիրն է վավեր։

Ավարտեք՝ փոփոխության գրառման մեջ գրանցելով գոտին, կապակցումը, լուծիչը և այն անունները, որոնք ստուգել եք։ Այնուհետև հաջորդ մարդը, որը գրառում կավելացնի, կիմանա, թե որ անվանատարածքն է հեղինակավոր տվյալ հաճախորդների բազմության համար։