VPN માં DNS ખોટું? એક સત્તાવાર સર્વર જૂનું હોઈ શકે

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

લક્ષણ રિઝોલ્વર સાથે બદલાય છે

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

તેથી જ એક જ નામ એક ઓફિસમાં કામ કરી શકે અને હોટેલથી નિષ્ફળ જાય, અને તેથી જ સ્થાનિક કેશ સાફ કરવાથી ફક્ત ક્યારેક મદદ મળે. કેશ સાફ કરવાથી પ્રશ્ન ફરી એ જ સત્તા પર જાય છે.

અલગ પાડતી કસોટી દરેક પ્રકાશિત સર્વરને સીધી ક્વેરી છે.

દરેક સત્તાને સીધું પૂછો

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

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

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

તે ક્વેરી નિષ્ફળ જતા નેટવર્કથી ચલાવો, ફક્ત તમારા ડેસ્કથી નહીં.

ઇચ્છિત દૃશ્યોને તૂટેલા દૃશ્યોથી અલગ કરો

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

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

SERVFAIL જવાબ આપતું સર્વર આત્મવિશ્વાસથી ખોટો જવાબ આપતા સર્વર કરતાં નિદાન કરવું સરળ છે.

સ્થળાંતર કેશે શું છુપાવ્યું તે ઉઘાડું કરે છે

પ્રદાતા બદલતી વખતે બે સત્તાવાર સ્થળો બદલાય છે: પેરન્ટ ડેલિગેશન અને ઝોનના પોતાના NS રેકોર્ડ. બંને અપડેટ કરવા પડે છે, અને બંને તેમના TTL માટે કેશ થાય છે. જૂનું સર્વર ચાલુ રહે અને અગાઉનું ઝોન પીરસવાનું ચાલુ રાખે, તો જેમના રિઝોલ્વર તેને પૂછે છે તે ક્લાયન્ટને સ્થળાંતર પૂર્ણ દેખાયાના ઘણા સમય પછી પણ જૂનો જવાબ મળતો રહેશે.

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

લેપટોપ પર રિઝોલ્વર બદલવાથી તે લેપટોપ સુધરે છે અને બીજું કંઈ નહીં.

ઝોન સુધારો, રિઝોલ્વર નહીં

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

પછી બંને નેટવર્કથી સીધી ક્વેરી ફરી ચલાવો અને તમે બદલેલા રેકોર્ડનું TTL પૂરું થાય ત્યાં સુધી રાહ જુઓ.

દરેક સત્તાથી જવાબ સ્થિર છે તેની ખાતરી કરો, અને ઇચ્છિત દૃશ્ય ઝોન દસ્તાવેજીકરણમાં લખો જેથી આગલો તફાવત સરળતાથી વર્ગીકૃત થાય.