«DNS તૂટેલું છે» એ એક તારણ છે, અને તે એવું તારણ નથી જેના પર મદદનીશ કંઈ કરી શકે. રિપોર્ટનો ઉપયોગી ભાગ નિષ્ફળતાનો આકાર છે: કયું નામ, કયા રિઝોલ્વર દ્વારા, કયા પ્રતિસાદ સાથે. ત્રણ વિગતો ફરિયાદને ફરી ઉત્પન્ન કરી શકાય તેવી વસ્તુમાં ફેરવે છે, અને ખાનગી ભાગોનાં નામ બદલાયા પછી ત્રણેય વહેંચવા સુરક્ષિત છે. નીચે જે છે તે કોઈ મદદ કરી શકે તે પહેલાં VPN DNS રિપોર્ટને જરૂરી લઘુત્તમ છે.

નામની શ્રેણી, ચુકાદો નહીં

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

કહો કે નિષ્ફળતા માટે ટનલ ચાલુ હોવી જરૂરી છે કે તે ડિસ્કનેક્ટ થયા પછી થાય છે. જે નામ ફક્ત VPN સક્રિય હોય ત્યારે તૂટે છે તે પ્રતિ-લિંક રૂપરેખાંકન સૂચવે છે, જ્યારે ડિસ્કનેક્ટ પછી તૂટતું નામ બાકી રહેલી સ્થિતિ સૂચવે છે. રિપોર્ટ સામાન્ય રીતે આ છોડી દે છે અને પછી વિચારે છે કે પહેલું સૂચન કેમ મદદ કરતું નથી.

રિઝોલ્વર માર્ગ નોંધો

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

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

સ્ટેટસ આઉટપુટ પ્રતિ-લિંક સર્વરો અને રાઉટિંગ ડોમેનનાં નામ આપે છે, જે છે જ્યાં સ્પ્લિટ DNS નક્કી થાય છે. getent કૉલ એપ્લિકેશન જે માર્ગે જાય તે જ માર્ગ અનુસરે છે, nsswitch ક્રમ સહિત. સીધી ક્વેરી બંનેને ટાળે છે અને એક સર્વરને અલગથી ચકાસે છે. ત્રણમાંથી કયું નિષ્ફળ અને કયું સફળ થયું તે જણાવો, અને વાચકને હવે માર્ગ અનુમાન કરવાની જરૂર નથી.

નિયંત્રિત સરખામણી જણાવો

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

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

નામસ્પેસ છુપાવો, સંબંધો રાખો

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

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

સંબંધિત લેખો