Մի օր ես կանգնած էի իմ հաճախորդներից մեկին իրավունք տալ խմբագրելու իրեն հատկացված /28 ենթացանցի PTR գրառումները: Ես չունեմ BIND կարգավորումները արտաքինից խմբագրելու ավտոմատացում: Հետևաբար, ես որոշեցի այլ երթուղի անցնել՝ պատվիրատուին պատվիրակել /24 ենթացանցի PTR գոտու մի մասը:
Թվում է, թե ինչ կարող է լինել ավելի պարզ: Մենք պարզապես գրանցում ենք ենթացանցը, ինչպես պահանջվում է և ուղղում այն ցանկալի NS-ին, ինչպես դա արվում է ենթադոմեյնի դեպքում: Բայց ոչ. Դա այնքան էլ պարզ չէ (չնայած իրականում դա ընդհանուր առմամբ պարզունակ է, բայց ինտուիցիան չի օգնի), դրա համար ես գրում եմ այս հոդվածը:
Յուրաքանչյուր ոք, ով ցանկանում է ինքնուրույն պարզել, կարող է կարդալ
Ով ուզում է պատրաստի լուծում, համեցեք կատու:
Քոփի-փեյսթ մեթոդը հավանողներին չուշացնելու համար նախ կտեղադրեմ գործնական մասը, հետո տեսականը։
1. Պրակտիկա. Պատվիրակման գոտի /28
Ենթադրենք, որ ունենք ենթացանց 7.8.9.0/24. Մենք պետք է պատվիրակենք ենթացանցը 7.8.9.240/28 dns հաճախորդին 7.8.7.8 (ns1.client.domain).
Պրովայդերի DNS-ում դուք պետք է գտնեք ֆայլ, որը նկարագրում է այս ենթացանցի հակառակ գոտին: Թող այդպես լինի; թող դա լինի 9.8.7.- addr.arpa- ում.
Մենք մեկնաբանում ենք 240-ից 255 գրառումները, եթե այդպիսիք կան: Իսկ ֆայլի վերջում գրում ենք հետևյալը.
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240մի մոռացեք մեծացնել սերիական գոտին և անել
rndc reloadՍա ավարտում է մատակարարի մասը: Եկեք անցնենք հաճախորդի dns-ին:
Նախ, եկեք ստեղծենք ֆայլ /etc/bind/master/255-240.9.8.7.in-addr.arpa հետևյալ բովանդակությունը.
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
@ IN NS ns1.client.domain.
@ IN NS ns2.client.domain.
241 IN PTR test.client.domain.
242 IN PTR test2.client.domain.
245 IN PTR test5.client.domain.
Իսկ ներսում անունով ավելացնել մեր նոր ֆայլի նկարագրությունը.
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B վերսկսել կապելու գործընթացը:
/etc/init.d/named restartԲոլորը. Այժմ դուք կարող եք ստուգել:
#> host 7.8.9.245
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.Խնդրում ենք նկատի ունենալ, որ տրված է ոչ միայն PTR գրառումը, այլև CNAME-ը: Այդպես էլ պետք է լինի։ Եթե դուք մտածում եք, թե ինչու, ապա բարի գալուստ հաջորդ գլուխ:
2. Տեսություն. Ինչպես է դա աշխատում.
Դժվար է կարգավորել և կարգաբերել սև արկղը: Շատ ավելի հեշտ է, եթե հասկանում ես, թե ինչ է կատարվում ներսում:
Երբ մենք պատվիրակում ենք ենթադոմեյն տիրույթում դոմեյն, ապա գրում ենք այսպես.
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Մենք ասում ենք բոլորին, ովքեր հարցնում են, որ մենք պատասխանատու չենք այս կայքի համար և ասում ենք, թե ով է պատասխանատու: Եվ բոլոր խնդրանքները client.domain վերահղում դեպի 7.8.7.8: Ստուգելիս մենք տեսնում ենք հետևյալ նկարը (մենք բաց կթողնենք այն, ինչ հաճախորդն ունի այնտեղ։ Կարևոր չէ).
# host test.client.domain
test.client.domain has address 7.8.9.241Նրանք. մեզ տեղեկացրին, որ կա այսպիսի A գրառում և դրա ip-ն 7.8.9.241 է։ Ոչ մի ավելորդ տեղեկատվություն:
Ինչպե՞ս կարելի է նույն բանն անել ենթացանցով:
Որովհետեւ մեր DNS սերվերը գրանցված է RIPE-ում, այնուհետև մեր ցանցից PTR IP հասցե խնդրելու դեպքում առաջին հարցումը դեռևս կլինի մեզ համար: Տրամաբանությունը նույնն է, ինչ տիրույթների դեպքում։ Բայց ինչպե՞ս եք մուտքագրում ենթացանցը գոտու ֆայլի մեջ:
Փորձենք մուտքագրել այն այսպես.
255-240 IN NS 7.8.7.8Եվ... հրաշքը չեղավ. Մենք որևէ հարցում չենք ստանում վերահղում: Բանն այն է, որ bind-ը նույնիսկ չգիտի, որ հակադարձ գոտու ֆայլի այս գրառումները IP հասցեներ են, և առավել եւս չի հասկանում միջակայքի մուտքագրումը: Նրա համար սա ընդամենը ինչ-որ խորհրդանշական ենթադոմեյն է։ Նրանք. կապելու համար տարբերություն չի լինի»255-240"Եւ"մեր սուպերհաճախորդը«. Եվ որպեսզի հարցումը գնա այնտեղ, որտեղ պետք է գնա, հարցումի հասցեն պետք է նման լինի. 241.255-240.9.8.7.in-addr.arpa. Կամ այսպես, եթե օգտագործենք նիշերի ենթադոմեյն. 241.oursuperclient.9.8.7.in-addr.arpa. Սա տարբերվում է սովորականից. 241.9.8.7.- addr.arpa- ում.
Ձեռքով նման հարցում կատարելը դժվար կլինի։ Եվ նույնիսկ եթե այն աշխատում է, դեռևս պարզ չէ, թե ինչպես կիրառել այն իրական կյանքում: Ի վերջո, ըստ պահանջի 7.8.9.241 Պրովայդերի DNS-ը դեռ պատասխանում է մեզ, ոչ թե հաճախորդի:
Եվ ահա, որտեղ նրանք հայտնվում են խաղի մեջ CNAME- ը.
Պրովայդերի կողմից դուք պետք է ենթացանցի բոլոր IP հասցեների համար փոխանուն կազմեք այնպիսի ձևաչափով, որը հարցումը կուղարկի հաճախորդի DNS-ին:
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Սա աշխատասերների համար է =):
Իսկ ծույլերի համար ավելի հարմար է ստորև ներկայացված դիզայնը.
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Այժմ պահանջեք տեղեկատվություն այստեղ 7.8.9.241 - ից 241.9.8.7.- addr.arpa- ում մատակարարի DNS սերվերի վրա կվերածվի 241.255-240.9.8.7.in-addr.arpa և գնում է դեպի dns հաճախորդ:
Հաճախորդի կողմը պետք է կարգավորի նման հարցումները: Ըստ այդմ, մենք ստեղծում ենք գոտի 255-240.9.8.7.in-addr.arpa. Դրանում մենք, սկզբունքորեն, կարող ենք հակադարձ գրառումներ տեղադրել ամբողջ /24 ենթացանցի ցանկացած ip-ի համար, բայց նրանք մեզ կհարցնեն միայն նրանց մասին, որոնք մատակարարը ուղարկում է մեզ, այնպես որ մենք չենք կարողանա խաղալ շուրջը =):
Պատկերացնելու համար ես ևս մեկ անգամ կտամ հաճախորդի կողմից հակադարձ գոտու ֆայլի բովանդակության օրինակ.
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
@ IN NS ns1.client.domain.
@ IN NS ns2.client.domain.
241 IN PTR test.client.domain.
242 IN PTR test2.client.domain.
245 IN PTR test5.client.domain.
Դա պայմանավորված է նրանով, որ մենք օգտագործում ենք CNAME մատակարարի կողմից, և ի պատասխան IP հասցեով տվյալների տրամադրման հարցման, մենք ստանում ենք երկու գրառում, ոչ թե մեկը:
#> host 7.8.9.245
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.
Եվ մի մոռացեք ճիշտ կարգավորել ACL-ը: Որովհետև անիմաստ է ձեզ համար PTR գոտի վերցնել և դրսից որևէ մեկին չպատասխանել =):
Source: www.habr.com