Երկու տեղամաս, մեկ մասնավոր DNS գոտի՝ ո՞ւմն են գրառումները։

Դուք հոսթ եք ավելացնում կանաչ տեղամասում, այն լուծվում է կանաչ օգտատերերի համար, իսկ դեղին գրասենյակը դեռ ստանում է NXDOMAIN։ Սա VPN-ի ձախողում չէ և կոտրված լուծիչ էլ չէ՝ սա սեփականության բաց է մասնավոր գոտում։ Երկու ինքնուրույն խմբագրվող գրառումների ցանկեր մեկ գոտի չեն դառնում միայն այն պատճառով, որ տեղամասերը կարող են հասնել միմյանց։ Լուծումը հրապարակման պլան է, ոչ թե ևս մեկ հրային պատի կանոն։

Ախտանիշը անվանում է բացակայող սեփականատիրոջը

Հավանաբար յուրաքանչյուր տեղամասում կա տեղական փոխարինում, Pi-hole գրառում կամ dnsmasq տող, որը ինչ-որ մեկը ավելացրել է, երբ անուն էր պետք։ Կանաչ գրառումը գոյություն ունի միայն կանաչ լուծիչում, ուստի դեղին տեղամասի հաճախորդը հարցնում է իր լուծիչին և ստանում ճշմարիտ «այդպիսի անուն չկա»։ Հնացած պատասխանն այլ տեսք ունի՝ հոսթը տեղափոխվել է, մի տեղամաս թարմացրել է իր պատճենը, իսկ մյուսը դեռ վերադարձնում է հին հասցեն։

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

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

Տարբերակ A՝ մեկ հեղինակավոր գոտի երկրորդայիններով

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

Այդ դասավորությունը պահանջում է հստակ որոշումներ, որոնք հեշտ է հետաձգել և թանկ է բաց թողնել։ Ո՞վ կարող է խմբագրել գոտին։ Ո՞ր սերվերներին է թույլատրվում փոխանցել այն, և ո՞ր հասցեներով։ Ի՞նչ պետք է տեսնեն հաճախորդները, մինչ տեղամասերի միջև թունելը անջատված է։ Երկրորդայինը շարունակում է պատասխանել իր վերջին պատճենից, ինչը սովորաբար ցանկալի վարք է, բայց դա պետք է լինի հայտարարված ընտրություն, ոչ թե անակնկալ ընդհատման ժամանակ։

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

Գինը համակարգումն է՝ մեկ խմբագրման ուղի, մեկ փոփոխության վերանայում և ընդհանուր ընկալում, թե ով է հերթապահում, երբ գրառումը սխալ է։

Տարբերակ B՝ ենթադոմեյն յուրաքանչյուր տեղամասի համար

Պատվիրակեք green.internal.example.com-ը կանաչ տեղամասին և yellow.internal.example.com-ը դեղինին։ Յուրաքանչյուր տեղամաս հեղինակավոր է դառնում իր անունների համար, իսկ մայր գոտին կրում է միայն պատվիրակման գրառումները։ Մեկ ֆայլի շուրջ մրցակցությունը անհետանում է, և տեղական թիմը կարող է հոսթ ավելացնել՝ չսպասելով կենտրոնական փոփոխության։

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

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

Թող յուրաքանչյուր լուծիչ հետևի ընտրությանը

Տվեք հաճախորդներին հաստատված լուծիչը և որոնման դոմեյնը նրանց աջակցվող կարգավորումների միջոցով, և համոզվեք, որ լուծիչն ունի թույլատրված VPN երթուղի դեպի ցանկացած հեռավոր DNS սերվեր, որը պետք է հարցնի. Հավելվածներին նույնպես պետք են երթուղիներ դեպի այն մասնավոր հասցեները, որոնք վերադարձնում են այդ պատասխանները, որովհետև առանց ուղու ճիշտ անունը դեռ կոտրված կապ է։

Եթե Pi-hole-ը տրամադրում է տեղական լուծում, գրեք, թե որ գրառումներն են նրան պատկանում և որ հարցումներն է փոխանցում։ Երկու ինքնուրույն խմբագրվող Pi-hole ցանկեր դեռ չեն կրկնօրինակվում։ Pi-hole v6-ում հատուկ dnsmasq տողերը սահմանվում են հոսթի կողմի ընտրանքներով, ինչպիսիք են TOML-ը, CLI-ն կամ միջավայրի փոփոխականները, և չեն բացահայտվում API-ի միջոցով՝ /etc/dnsmasq.d/ ֆայլերի բեռնումը առանձին ընտրանք է, որն անջատված է լռելյայն։

Ապա փորձարկեք երկու կողմից մի անունով, որը պետք է տեսանելի լինի ամենուր՝

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

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

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