1.1.1.1 કોણ ચલાવે છે? ભરોસો કરતા પહેલાં DNS સરનામાની તપાસ
VPN સાથે વપરાતું DNS સરનામું જરૂરી નથી કે એ જ VPN ચલાવે. રિઝોલ્વર ઓળખો, પછી માર્ગ અને ખાનગી નામોની નીતિ અલગથી તપાસો.
તમે 1.1.1.1 ને VPN ના DNS ક્ષેત્રમાં પેસ્ટ કર્યું, પૃષ્ઠ લોડ થયું, અને ટ્યુટોરિયલ હવે પુષ્ટ લાગે છે. એ અવલોકન લાગે તેના કરતાં સાંકડું છે: એપ્લિકેશને અલગ રીતે વર્તન કર્યું, અને ફેરફાર હજી કહેતું નથી કે પ્રશ્નનો જવાબ કોણે આપ્યો અથવા જૂની ગોઠવણ કેમ નિષ્ફળ ગઈ. નકલ કરેલું ટ્યુટોરિયલ ઘણી વાર જાણીતા જાહેર સરનામાને “VPN નું DNS” કહે છે, અને તે માલિકીનો દાવો છે, પહોંચનો નહીં. સરનામું શું રજૂ કરે છે તે તપાસવામાં પાંચ મિનિટ લાગે છે અને ખોટા કારણથી કરેલો કાયમી ફેરફાર અટકે છે.
કામ કરતું સેટિંગ ઓળખ નથી
સેટિંગ ક્ષેત્રનું સરનામું એક અંતિમ બિંદુ છે, અને અંતિમ બિંદુનો એક ઓપરેટર હોય છે. આ બે હકીકતો અલગ છે, અને બીજી એ છે જે લોકો છોડી દે છે. સૌથી વધુ નકલ થતી જોડી માટે જવાબ જાહેર છે: Cloudflare 1.1.1.1 અને 1.0.0.1 ને પોતાના રિઝોલ્વરનાં સરનામાં તરીકે પ્રકાશિત કરે છે અને તેમને પોતાના સત્તાવાર સરનામા સંદર્ભમાં સૂચિબદ્ધ કરે છે. તેથી ઓપરેટરનું નામ સરનામાની બાજુમાં હોય છે, અલગ ટ્યુટોરિયલમાં નહીં.
ટનલ ચાલુ હોય ત્યારે એ જોડી દાખલ કરવાથી VPN કંપની તેનો ઓપરેટર બનતી નથી, અને ટ્રાફિક અનામી બનતો નથી. પ્રશ્ન તમારા મશીનમાંથી સરનામા શ્રેણી પ્રકાશિત કરતી કંપની તરફ જાય છે, અને તે કંપની પ્રતિષ્ઠિત હોઈ શકે છે અને છતાં ટ્યુટોરિયલે સૂચવેલો પક્ષ ન હોઈ શકે. સૂચનાઓનું લેબલ અને વાસ્તવિક ઓપરેટર બે અલગ દાવા છે. બંનેમાંથી કોઈ કહેતું નથી કે વચ્ચેનો નેટવર્ક માર્ગ કોણ ચલાવે છે.
સરનામા જોડી અથવા એન્ક્રિપ્ટેડ અંતિમ બિંદુની પુષ્ટિ માટે રિઝોલ્વરના પોતાના પ્રકાશિત સંદર્ભનો ઉપયોગ કરો. બીજા સપ્લાયરની સિફારસ કાયદેસર હોઈ શકે છે, અને “દ્વારા સિફારસ કરેલ”, “માંથી પહોંચેલ” અને “દ્વારા સંચાલિત” હજી ત્રણ અલગ સંબંધો વર્ણવે છે.
રેકોર્ડને જે ત્રણ વસ્તુઓની જરૂર છે તેમની સરખામણી કરો
સમીક્ષા માટે તૈયાર રેકોર્ડ ત્રણ પ્રશ્નો અલગ કરે છે: પ્રશ્ન કોને મળવો જોઈએ, આદાનપ્રદાન સાદું છે કે એન્ક્રિપ્ટેડ, અને કયો માર્ગ તેને વહી જવો જોઈએ. સપ્લાયરનું નામ બીજું કે ત્રીજું ભરી શકતું નથી, અને દેશનું લેબલ તેમાંથી એક પણ ભરી શકતું નથી. ફેરફાર પહેલાં ત્રણેય નોંધ લખો અને પછી તેમની સરખામણી કરો. એ નોંધો અદલાબદલી કરી શકાય તેવી નથી, અને તેમને એક ગણવું એ જ રસ્તો છે જેમાં અનુમાન દસ્તાવેજ બને છે.
સરખામણી જ કામ કરતા સેટિંગને નોંધાયેલ નિર્ણયમાં ફેરવે છે. તેના વિના આગલી વ્યક્તિને કોઈ કારણ વિનાનું સરનામું વારસામાં મળે છે. પહેલાં નીચેના કોષ્ટકની ત્રીજી કોલમ વાંચો, કારણ કે ત્યાં જ મોટાભાગની આત્મવિશ્વાસપૂર્ણ સમજૂતીઓ ખરેખર અટકે છે.
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
કોષ્ટક જાણી જોઈને ટૂંકું છે. તેનો મુદ્દો એ છે કે દરેક નોંધ અલગ પ્રશ્નનો જવાબ આપે છે, અને કોઈ એક ક્ષેત્ર ત્રણેય ભરતું નથી.
સ્થાનિક ફોરવર્ડર સાચો સ્રોત છુપાવે છે
જે ઉપકરણ પોતાના રાઉટરને DNS તરીકે વાપરવા સેટ છે તે ફોરવર્ડર તરફ ઈશારો કરે છે. તે સરનામું પ્રશ્નના આગલા પ્રાપ્તકર્તાને ઓળખે છે, અંતે જવાબ આપતા રિઝોલ્વરને નહીં. સ્થાનિક સ્ટબ રિઝોલ્વર એ જ વધારાનું પગલું ઉમેરે છે, અને દરેક સ્થિતિ આઉટપુટમાં દેખાતું હોવાથી તેને સાચી વસ્તુ સાથે ભૂલવું સહેલું છે.
સ્ટબ એ સ્રોતો તરફ મોકલે છે જે એ જ આઉટપુટ પણ સૂચિબદ્ધ કરે છે, સામાન્ય રીતે વધુ નીચે. ઓપરેટર વિશે કંઈ પણ તારણ કાઢતા પહેલાં આખી સાંકળ વાંચો, કારણ કે પહેલી લાઇન આખો જવાબ નથી. નહીં તો તમે સ્વાગતને કંપની કહી રહ્યા છો.
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'બીજો આદેશ રિઝોલ્વરના પડઘા નામનો ઉપયોગ કરે છે, જ્યાં ઓપરેટર એક પ્રકાશિત કરે છે, તે જુએ છે તે સ્રોત સરનામું જણાવવા. ત્રીજો જવાબ આપનાર સર્વરનું નામ આપે છે, જે ઘણી વાર તમે રૂપરેખાંકિત કરેલું સરનામું નથી. ઓપરેટર લખતા પહેલાં ત્રણેય આઉટપુટની સરખામણી કરો.
એન્ક્રિપ્ટેડ DNS શું દેખાય છે તે બદલે છે, કોણ જુએ છે તે નહીં
DNS over HTTPS અને DNS over TLS ક્લાયન્ટ અને રિઝોલ્વર વચ્ચેના આદાનપ્રદાનનું રક્ષણ કરે છે. રિઝોલ્વર હજી પૂછાયેલા દરેક નામને વાંચે છે, કારણ કે જવાબ આપવો એ જ કામ છે. બદલાય છે તે એ કે આદાનપ્રદાન કોણ નિહાળી શકે: સ્થાનિક નેટવર્ક એક અંતિમ બિંદુ સાથેનું જોડાણ જુએ છે, સાદા ટેક્સ્ટ પ્રશ્નોનો પ્રવાહ નહીં.
બદલાતું નથી તે વિશ્વાસનો સંબંધ છે, જે હજી પણ તે અંતિમ બિંદુ ચલાવતી સંસ્થા તરફ ઈશારો કરે છે. પોતાની સુરક્ષિત DNS સેટિંગ ધરાવતું બ્રાઉઝર ઓપરેટિંગ સિસ્ટમના રિઝોલ્વરને સંપૂર્ણ બાયપાસ કરી શકે છે. તેમને બે વાર લાગુ કરેલી એક સેટિંગ તરીકે નહીં, પણ અસહમત થઈ શકે તેવી બે રૂપરેખા તરીકે જુઓ.
ખાનગી નામોને ફરી પોતાનો નિર્ણય જોઈએ. કામની ટનલ પસંદ કરેલા ડોમેનને સંસ્થાકીય રિઝોલ્વર તરફ મોકલી શકે છે, અને તેને જાહેર સેવાથી બદલવાથી આંતરિક શોધ તૂટી શકે છે અથવા આંતરિક નામો ખોટા પક્ષને ખુલ્લાં થઈ શકે છે. આખા એડાપ્ટરની સેટિંગ્સ બદલતા પહેલાં ડોમેન નીતિ તપાસો.
અવલોકન સાંકડું રાખો
સરખામણી કરતી વખતે જૂની રૂપરેખા સાચવો અને એક સમયે એક સેટિંગ બદલો. એપ્લિકેશન, ક્રિયા, રિઝોલ્વર નીતિ, અને ફરી જોડાયા પછી જાહેર તથા મંજૂર ખાનગી નામો હજી ઉકેલાય છે કે નહીં તે નોંધો. બે ફેરફારવાળી સરખામણી એક પણ સાબિત કરતી નથી. પરિણામ ત્યાં લખો જ્યાં આગલી વ્યક્તિને મળે, સેટિંગની બરાબર બાજુમાં.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comજો એપ્લિકેશન કામ કરવા લાગે, તો દાવો પુરાવા પરવાનગી આપે તેટલો નાનો રાખો. એ ફેરફારે એક પરીક્ષણમાં મદદ કરી, અને તે કહેતું નથી કે પાછલા રિઝોલ્વરે ખરાબ નિયતથી કામ કર્યું, ટનલ તૂટેલી હતી, કે બીજા ઉપકરણને એ જ બદલીની જરૂર છે. ટકાઉ પરિણામ એ રૂપરેખા છે જેનો ઓપરેટર અને હેતુ તમે સમજાવી શકો.