બે સાઇટ, એક ખાનગી DNS ઝોન: રેકોર્ડ કોના છે?

તમે લીલી સાઇટ પર એક હોસ્ટ ઉમેરો છો, તે લીલા વપરાશકર્તાઓ માટે ઉકેલાય છે, અને પીળી ઓફિસ હજી પણ NXDOMAIN મેળવે છે. આ VPN ની નિષ્ફળતા નથી અને તૂટેલું રિઝોલ્વર પણ નથી; આ ખાનગી ઝોનમાં માલિકીની ખાલી જગ્યા છે. બે સ્વતંત્ર રીતે સંપાદિત રેકોર્ડ યાદીઓ ફક્ત એટલા માટે એક ઝોન બનતી નથી કે સાઇટ્સ એકબીજા સુધી પહોંચી શકે છે. ઉકેલ પ્રકાશન યોજના છે, બીજો ફાયરવોલ નિયમ નહીં.

લક્ષણ ગુમ થયેલા માલિકનું નામ આપે છે

સંભવતઃ દરેક સાઇટમાં સ્થાનિક ઓવરરાઇડ, Pi-hole એન્ટ્રી અથવા dnsmasq લાઇન છે જે કોઈએ નામની જરૂર પડી ત્યારે ઉમેરી હતી. લીલો રેકોર્ડ ફક્ત લીલા રિઝોલ્વર પર જ છે, તેથી પીળી સાઇટનો ક્લાયન્ટ પોતાના રિઝોલ્વરને પૂછે છે અને સાચો "એવું કોઈ નામ નથી" જવાબ મેળવે છે. જૂનો જવાબ અલગ દેખાય છે: હોસ્ટ ખસી ગયું, એક સાઇટે પોતાની નકલ અપડેટ કરી, અને બીજી હજી પણ જૂનું સરનામું પરત કરે છે.

કેશ ફ્લશ કરીને બંનેમાંથી કોઈ પેટર્ન લાંબા સમય માટે સુધરતું નથી. ફોરવર્ડિંગ રિઝોલ્વરનો કેશ એક વાર મળેલા જવાબની નકલ છે, નવાં નામ પ્રકાશિત કરતી સત્તા નથી, તેથી આજે કામ કરતો કેશ આવતીકાલના હોસ્ટ વિશે કંઈ કહેતું નથી. BIND નું દસ્તાવેજીકરણ પ્રાથમિક, ગૌણ, પુનરાવર્તી અને ફોરવર્ડિંગ ભૂમિકાઓને બરાબર આ કારણે અલગ રીતે વર્ણવે છે.

તેથી ડિઝાઇન પ્રશ્ન સાંકડો અને જવાબપાત્ર છે: કોણ રેકોર્ડ બનાવી શકે, અને તે રેકોર્ડ દરેક એવા રિઝોલ્વર સુધી કેવી રીતે પહોંચે જેણે તેના માટે જવાબ આપવો પડે?

વિકલ્પ A: ગૌણ સાથે એક સત્તાવાળો ઝોન

internal.example.com માટે પ્રાથમિક ચલાવો અને સમર્થિત ગૌણને દરેક સાઇટ પર ઝોન મેળવવા દો. દરેક સાઇટનું પુનરાવર્તી રિઝોલ્વર પોતાના સ્થાનિક ગૌણને પૂછે છે, તેથી જવાબો કેશમાંથી નહીં પણ સત્તાવાળા સ્રોતમાંથી આવે છે, અને એક વાર કરેલો ફેરફાર ફરી ટાઇપ કરવાને બદલે સ્થાનાંતરિત થાય છે.

આ ગોઠવણને સ્પષ્ટ નિર્ણયોની જરૂર છે જે મુલતવી રાખવા સરળ છે અને છોડી દેવા ખર્ચાળ છે. ઝોન કોણ સંપાદિત કરી શકે? કયા સર્વરોને તેને સ્થાનાંતરિત કરવાની મંજૂરી છે, અને કયા સરનામાં પરથી? સાઇટ્સ વચ્ચેની ટનલ બંધ હોય ત્યારે ક્લાયન્ટને શું દેખાવું જોઈએ? ગૌણ પોતાની છેલ્લી નકલમાંથી જવાબ આપવાનું ચાલુ રાખે છે, જે સામાન્ય રીતે તમે ઇચ્છો છો તે વર્તન છે, પણ તે જાહેર કરેલી પસંદગી હોવી જોઈએ, વિક્ષેપ દરમિયાન આશ્ચર્ય નહીં.

ઝોન સ્થાનાંતરણને સરનામા દ્વારા જાણીતા ગૌણ સુધી મર્યાદિત કરો અને જ્યાં અમલીકરણ સમર્થન આપે ત્યાં વ્યવહાર હસ્તાક્ષરનો ઉપયોગ કરો. ખુલ્લું સ્થાનાંતરણ એ પોર્ટ સુધી પહોંચી શકે તેવા કોઈપણ માટે તમારી આંતરિક નામ જગ્યાની નકલ છે.

કિંમત સંકલન છે: એક સંપાદન માર્ગ, એક ફેરફાર સમીક્ષા, અને રેકોર્ડ ખોટો હોય ત્યારે કોણ ફરજ પર છે તેની સહિયારી સમજ.

વિકલ્પ B: દરેક સાઇટ માટે સબડોમેન

લીલી સાઇટને green.internal.example.com અને પીળી સાઇટને yellow.internal.example.com પ્રતિનિધિત્વ કરો. દરેક સાઇટ પોતાનાં નામો માટે સત્તાવાળી બને છે, અને મૂળ ઝોન ફક્ત પ્રતિનિધિત્વ રેકોર્ડ ધરાવે છે. એક ફાઇલ પરની હરીફાઈ અદૃશ્ય થાય છે, અને સ્થાનિક ટીમ કેન્દ્રીય ફેરફારની રાહ જોયા વિના હોસ્ટ ઉમેરી શકે છે.

પ્રતિનિધિત્વ મૂળ ઝોનમાં હોવું જોઈએ, સાઇટના સત્તાવાળા સર્વરો તરફ નિર્દેશ કરતા NS રેકોર્ડ સાથે. જ્યારે સંપૂર્ણ પ્રતિનિધિત્વ અવ્યવહારુ હોય ત્યારે સબડોમેન માટે શરતી ફોરવર્ડ માન્ય વિકલ્પ છે, પણ તે રિઝોલ્વર સેટિંગ છે, પ્રકાશિત હકીકત નહીં, તેથી દરેક રિઝોલ્વરને એક જ નિયમની જરૂર છે.

ખર્ચ અદૃશ્ય થવાને બદલે ખસે છે: મૂળ ઝોનને હજી પણ માલિકની જરૂર છે, અને નવી સાઇટ બનાવવી હવે એક જગ્યાને બદલે બે જગ્યાએ ફેરફાર છે.

દરેક રિઝોલ્વરને પસંદગી અનુસરવા દો

ક્લાયન્ટને મંજૂર રિઝોલ્વર અને શોધ ડોમેન તેમની સમર્થિત ગોઠવણી દ્વારા આપો, અને ખાતરી કરો કે રિઝોલ્વર પાસે કોઈપણ દૂરસ્થ DNS સર્વર સુધીનો મંજૂર VPN માર્ગ છે જેને તેણે પૂછવું પડે. એપ્લિકેશનને પણ તે ખાનગી સરનામાં સુધીના માર્ગની જરૂર છે જે આ જવાબો પરત કરે છે, કારણ કે માર્ગ વિનાનું સાચું નામ પણ તૂટેલું જોડાણ છે.

જો 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 જવાબ તમને કહે છે કે પીળું રિઝોલ્વર પોતાને સત્તાવાળું માને છે, ગૌણને પૂછે છે, કે ફક્ત ફોરવર્ડ કરે છે. આ અલગ નિષ્ફળતા રીતો સાથેના અલગ ડિઝાઇન છે, અને જવાબ સામાન્ય રીતે ઓળખે છે કે તમે ખરેખર કયું લાગુ કર્યું.

ત્રણ સ્વીકૃતિ કેસ સાથે પૂર્ણ કરો: દરેક સાઇટમાંથી એક નામ, કલાકની અંદર બદલાયેલો એક રેકોર્ડ, અને સાઇટ્સ વચ્ચેની કડી ઉપલબ્ધ ન હોવી. જે ડિઝાઇન ફક્ત પ્રથમ પાસ કરે છે તેની પાસે કાગળ પર પ્રકાશન યોજના છે અને ઉત્પાદનમાં સ્થાનિક ઓવરરાઇડ છે.