ક્રોમિયમની એક વિશેષતા રૂટ DNS સર્વર્સ પર ભારે ભાર બનાવે છે

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

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

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

આ સર્વર્સ એ સર્વોચ્ચ સત્તા છે જેનો તમારે .com, .net, વગેરેને ઉકેલવા માટે સંપર્ક કરવો જોઈએ જેથી તેઓ તમને કહેશે કે frglxrtmpuf એ ઉચ્ચ-સ્તરનું ડોમેન (TLD) નથી.

DNS, અથવા ડોમેન નેમ સિસ્ટમ, એક એવી સિસ્ટમ છે જેના દ્વારા કમ્પ્યુટર્સ arstechnica.com જેવા યાદગાર ડોમેન નામોને 3.128.236.93 જેવા ઓછા વપરાશકર્તા-મૈત્રીપૂર્ણ IP સરનામાઓમાં ઉકેલી શકે છે. DNS વિના, ઈન્ટરનેટ એ રીતે અસ્તિત્વમાં ન હોત કે જે માનવો ઉપયોગ કરી શકે, એટલે કે ઉપલા-સ્તરના ઈન્ફ્રાસ્ટ્રક્ચર પર બિનજરૂરી ભાર એ વાસ્તવિક સમસ્યા છે.

એક આધુનિક વેબ પેજ લોડ કરવા માટે અકલ્પનીય સંખ્યામાં DNS લુકઅપની જરૂર પડી શકે છે. ઉદાહરણ તરીકે, જ્યારે અમે ESPN ના હોમપેજનું વિશ્લેષણ કર્યું, ત્યારે અમે a.espncdn.com થી z.motads.com સુધીના 93 અલગ ડોમેન નામોની ગણતરી કરી. પૃષ્ઠને સંપૂર્ણપણે લોડ કરવા માટે તે બધા જરૂરી છે!

સમગ્ર વિશ્વને સેવા આપવા માટે જરૂરી સર્ચ એન્જિન માટે આ પ્રકારના વર્કલોડને સમાવવા માટે, DNS ને બહુ-સ્તરીય વંશવેલો તરીકે ડિઝાઇન કરવામાં આવ્યું છે. આ પિરામિડની ટોચ પર રુટ સર્વર્સ છે - દરેક ટોપ-લેવલ ડોમેન, જેમ કે .com, પાસે સર્વર્સનું પોતાનું કુટુંબ છે જે તેમની નીચેના દરેક ડોમેન માટે સર્વોચ્ચ સત્તા છે. એક પગલું ઉપર આ સર્વરો પોતે રૂટ સર્વર છે, થી a.root-servers.net માટે m.root-servers.net.

આ કેટલી વાર થાય છે?

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

જો સ્થાનિક પ્રદાતાના DNS સર્વર કે તેના રૂપરેખાંકનમાં ઉલ્લેખિત "ફોરવર્ડિંગ સર્વર્સ" બંને પાસે કેશ્ડ પ્રતિસાદ નથી, તો વિનંતી સીધી અધિકૃત ડોમેન સર્વર પર ઉઠાવવામાં આવે છે. ઉચ્ચ જેને તમે કન્વર્ટ કરવાનો પ્રયાસ કરી રહ્યા છો. ક્યારે домен.com આનો અર્થ એ થશે કે વિનંતી ડોમેનના જ અધિકૃત સર્વરને મોકલવામાં આવે છે comપર સ્થિત છે gtld-servers.net.

સિસ્ટમ gtld-servers, જેના માટે વિનંતી કરવામાં આવી હતી, તે ડોમેન domain.com માટે અધિકૃત નામ સર્વરની સૂચિ સાથે તેમજ આવા એક નામ સર્વરનું IP સરનામું ધરાવતા ઓછામાં ઓછા એક લિંક રેકોર્ડ સાથે પ્રતિસાદ આપે છે. આગળ, પ્રતિભાવો સાંકળની નીચે જાય છે - દરેક ફોરવર્ડર આ પ્રતિસાદોને વિનંતી કરેલ સર્વર પર પસાર કરે છે, જ્યાં સુધી પ્રતિસાદ આખરે સ્થાનિક પ્રદાતાના સર્વર અને વપરાશકર્તાના કમ્પ્યુટર સુધી પહોંચે નહીં. તે બધા આ પ્રતિભાવને કેશ કરે છે જેથી ઉચ્ચ-સ્તરની સિસ્ટમોને બિનજરૂરી રીતે ખલેલ પહોંચાડે નહીં.

મોટા ભાગના કિસ્સાઓમાં, નામ સર્વર રેકોર્ડ કરે છે domain.com આમાંના એક ફોરવર્ડર પર પહેલેથી જ કેશ કરવામાં આવશે, તેથી રૂટ સર્વર્સને ખલેલ પહોંચાડવામાં આવશે નહીં. જો કે, હમણાં માટે અમે URL ના પ્રકાર વિશે વાત કરી રહ્યા છીએ જેનાથી આપણે પરિચિત છીએ - એક જે નિયમિત વેબસાઇટમાં રૂપાંતરિત થાય છે. Chrome વિનંતીઓ સ્તર પર છે ઉચ્ચ આ, ક્લસ્ટરો પોતાને પગથિયા પર root-servers.net.

ક્રોમિયમ અને NXDomain ચોરીની તપાસ

Chromium તપાસે છે "શું આ DNS સર્વર મને મૂર્ખ બનાવી રહ્યું છે?" વેરિસાઇનના રૂટ DNS સર્વર્સના ક્લસ્ટર સુધી પહોંચતા લગભગ અડધા ટ્રાફિકનો હિસ્સો છે.

ક્રોમિયમ બ્રાઉઝર, ગૂગલ ક્રોમનો પેરેન્ટ પ્રોજેક્ટ, નવું માઈક્રોસોફ્ટ એજ, અને અસંખ્ય ઓછા જાણીતા બ્રાઉઝર્સ, વપરાશકર્તાઓને એક બોક્સમાં શોધવાની સરળતા પ્રદાન કરવા માંગે છે, જેને ક્યારેક "ઓમ્નિબૉક્સ" કહેવાય છે. બીજા શબ્દોમાં કહીએ તો, વપરાશકર્તા બ્રાઉઝર વિન્ડોની ટોચ પર સમાન ટેક્સ્ટ ફીલ્ડમાં વાસ્તવિક URL અને શોધ એન્જિન ક્વેરી બંને દાખલ કરે છે. સરળીકરણ તરફ બીજું પગલું ભરતા, તે વપરાશકર્તાને URL નો ભાગ દાખલ કરવા માટે દબાણ કરતું નથી http:// અથવા https://.

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

જો કોઈ વપરાશકર્તા તેમની કંપનીના ઈન્ટ્રાનેટ પર "માર્કેટિંગ" પ્રકારનો પ્રકાર કરે છે અને કંપનીના ઈન્ટ્રાનેટમાં સમાન નામની આંતરિક વેબસાઈટ છે, તો પછી ક્રોમિયમ એક માહિતી બોક્સ પ્રદર્શિત કરે છે જે વપરાશકર્તાને પૂછે છે કે શું તેઓ "માર્કેટિંગ" માટે શોધ કરવા માગે છે અથવા https://marketing. આ કેસ ન હોઈ શકે, પરંતુ ઘણા ISPs અને જાહેર Wi-Fi પ્રદાતાઓ દરેક ખોટી જોડણીવાળા URLને "હાઇજેક" કરે છે, વપરાશકર્તાને કેટલાક બેનરથી ભરેલા પૃષ્ઠ પર રીડાયરેક્ટ કરે છે.

રેન્ડમ પેઢી

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

કમનસીબે, નેટવર્ક્સમાં કે નથી DNS ક્વેરીઝના પરિણામોની ચોરી કરો, આ ત્રણ ઑપરેશન્સ સામાન્ય રીતે ખૂબ જ ટોચ પર જાય છે, બધી રીતે રુટ નેમ સર્વર્સ સુધી પહોંચે છે: સ્થાનિક સર્વરને કેવી રીતે ઉકેલવું તે ખબર નથી. qwajuixk, તેથી આ વિનંતીને તેના ફોરવર્ડરને ફોરવર્ડ કરે છે, જે તે જ કરે છે, છેલ્લે સુધી a.root-servers.net અથવા તેના "ભાઈઓ"માંથી કોઈને "માફ કરશો, પરંતુ આ ડોમેન નથી" કહેવાની ફરજ પાડવામાં આવશે નહીં.

લગભગ 1,67*10^21 સંભવિત નકલી ડોમેન નામો સાતથી પંદર અક્ષરોની લંબાઈ ધરાવતા હોવાથી, સૌથી સામાન્ય દરેક "પ્રમાણિક" નેટવર્ક પર કરવામાં આવેલા આ પરીક્ષણોમાંથી, તે રૂટ સર્વર પર પહોંચે છે. આ રકમ જેટલી થાય છે અડધા રુટ DNS પરના કુલ ભારમાંથી, ક્લસ્ટરોના તે ભાગના આંકડા અનુસાર root-servers.net, જે Verisign ની માલિકીની છે.

ઈતિહાસ પુનરાવર્તિત થાય છે

આ પ્રથમ વખત નથી કે શ્રેષ્ઠ ઇરાદા સાથે પ્રોજેક્ટ બનાવવામાં આવ્યો હોય નિષ્ફળ અથવા લગભગ બિનજરૂરી ટ્રાફિક સાથે જાહેર સંસાધનમાં પૂર આવ્યું - આનાથી તરત જ 2000 ના દાયકાના મધ્યમાં ડી-લિંક અને પૌલ-હેનિંગ કેમ્પના NTP (નેટવર્ક ટાઇમ પ્રોટોકોલ) સર્વરના લાંબા અને દુઃખદ ઇતિહાસની યાદ અપાવી.

2005માં, ફ્રીબીએસડી ડેવલપર પૌલ-હેનિંગ, જેઓ ડેનમાર્કના એકમાત્ર સ્ટ્રેટમ 1 નેટવર્ક ટાઈમ પ્રોટોકોલ સર્વરની માલિકી ધરાવતા હતા, તેમને ટ્રાન્સમિટેડ ટ્રાફિક માટે અણધારી અને મોટું બિલ મળ્યું. ટૂંકમાં, કારણ એ હતું કે D-Link ડેવલપર્સે સ્ટ્રેટમ 1 NTP સર્વરના સરનામાં લખ્યા હતા, જેમાં કેમ્પા સર્વરનો સમાવેશ થાય છે, કંપનીના સ્વીચો, રાઉટર્સ અને એક્સેસ પોઈન્ટની લાઇનના ફર્મવેરમાં. આનાથી તરત જ કેમ્પાના સર્વર ટ્રાફિકમાં નવ ગણો વધારો થયો, જેના કારણે ડેનિશ ઈન્ટરનેટ એક્સચેન્જ (ડેનમાર્કનો ઈન્ટરનેટ એક્સચેન્જ પોઈન્ટ) તેના ટેરિફને "ફ્રી" થી બદલીને "દર વર્ષે $9" કરે છે.

સમસ્યા એ નથી કે ત્યાં ઘણા બધા ડી-લિંક રાઉટર્સ હતા, પરંતુ તે "લાઇનની બહાર" હતા. DNS ની જેમ, NTP એ અધિક્રમિક સ્વરૂપમાં કાર્ય કરવું જોઈએ - સ્ટ્રેટમ 0 સર્વર્સ સ્ટ્રેટમ 1 સર્વર્સને માહિતી આપે છે, જે સ્ટ્રેટમ 2 સર્વર્સને માહિતી આપે છે, અને તેથી વધુ વંશવેલો નીચે. એક સામાન્ય હોમ રાઉટર, સ્વીચ અથવા એક્સેસ પોઈન્ટ જેમ કે ડી-લિંક NTP સર્વર સરનામાંઓ સાથે પ્રોગ્રામ કરેલું હોય તે સ્ટ્રેટમ 2 અથવા સ્ટ્રેટમ 3 સર્વરને વિનંતીઓ મોકલશે.

ક્રોમિયમ પ્રોજેક્ટ, સંભવતઃ શ્રેષ્ઠ હેતુઓ સાથે, DNS સમસ્યામાં NTP સમસ્યાની નકલ કરી, ઇન્ટરનેટના રૂટ સર્વરને એવી વિનંતીઓ સાથે લોડ કરી રહી છે જે તેઓ ક્યારેય હેન્ડલ કરવા માટે ન હતી.

ઝડપી ઉકેલની આશા છે

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

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

જાહેરાતના અધિકારો પર

એપિક સર્વર્સ છે વિન્ડોઝ પર VPS અથવા શક્તિશાળી AMD EPYC ફેમિલી પ્રોસેસર્સ અને ખૂબ જ ઝડપી Intel NVMe ડ્રાઇવ્સ સાથે Linux. ઓર્ડર કરવા માટે ઉતાવળ કરો!

સોર્સ: www.habr.com