રિકર્ઝન ઉપલબ્ધ નથી: DNS નીતિ, તૂટેલી ટનલ નહીં

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

નકાર અને ટાઇમઆઉટ અલગ જવાબો છે

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

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

પહેલા સ્થિતિ કોડ વાંચો, પછી નક્કી કરો કે આ ક્વેરી માટે ચેતવણી મહત્વની છે કે નહીં. ઝોનનું નામ આપતો સત્તાવાર જવાબ રિકર્ઝિવ બિટ નકારાય તો પણ વાપરી શકાય છે. જવાબ વગરનો નકાર નીતિનું પરિણામ છે, તૂટેલો પેકેટ માર્ગ નહીં.

રિઝોલ્વરે તમારા સ્રોત તરીકે શું નોંધ્યું

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

એ જ નામ ક્લાયન્ટથી અને સર્વર જેના પર પહેલેથી ભરોસો કરે છે એવા હોસ્ટથી ક્વેરી કરો. બે જવાબો વચ્ચેનો તફાવત સ્રોતની સ્થિતિ છે, અને તે કોઈ એક જવાબ કરતાં વધુ ઉપયોગી છે.

dig +short host.corp.example
dig +short example.com

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

વિભાજિત DNS ડિઝાઇન છે, ખામી નહીં

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

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

બે ક્વેરી સાથે નીતિ ચકાસો

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

resolvectl query host.corp.example
resolvectl query example.com

જો ખાનગી નામ કામ કરે છે અને જાહેર નામ નકારાય છે, તો નીતિ જે કહે છે તે કરે છે. જો ખાનગી નામ પણ નિષ્ફળ જાય, તો સમસ્યા ઝોન, રૂટ કે સ્રોત અધિકૃતિમાં છે, અને રિકર્ઝન ધ્યાન ભટકાવવું છે. બંને પરિણામો ઉપયોગી છે, અને દરેક બાકીની અડધી પૂર્વધારણાઓ દૂર કરે છે.

નકારને પુરાવા તરીકે વાંચો

નકાર એ જવાબ છે. તેનો અર્થ છે કે સર્વરને ક્વેરી મળી અને તેણે માંગેલું કામ કરવાનો નકાર કર્યો, જે કદી ન આવેલા પેકેટથી અલગ છે. એ ભેદ આખું નિદાન છે. તેને જવાબ તરીકે નોંધો, કનેક્ટિવિટી નિષ્ફળતા તરીકે નહીં.

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

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