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

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

કેશીંગ અસરકારક છે? થોડા વર્ષો પહેલા, મારા નાના સંશોધન દર્શાવે છે કે તે સંપૂર્ણ નથી. ચાલો વર્તમાન સ્થિતિ પર એક નજર કરીએ.

માહિતી એકત્રિત કરવા માટે મેં પેચ કર્યું એન્ક્રિપ્ટેડ DNS સર્વર પ્રતિભાવ માટે TTL મૂલ્ય સાચવવા માટે. તે દરેક આવનારી વિનંતી માટે તેના રેકોર્ડ્સના ન્યૂનતમ TTL તરીકે વ્યાખ્યાયિત થયેલ છે. આ વાસ્તવિક ટ્રાફિકના TTL વિતરણની સારી ઝાંખી આપે છે, અને વ્યક્તિગત વિનંતીઓની લોકપ્રિયતાને પણ ધ્યાનમાં લે છે. સર્વરનું પેચ કરેલ સંસ્કરણ ઘણા કલાકો સુધી કામ કરતું હતું.

પરિણામી ડેટા સેટમાં 1 રેકોર્ડ્સ (નામ, qtype, TTL, ટાઇમસ્ટેમ્પ)નો સમાવેશ થાય છે. અહીં એકંદર TTL વિતરણ છે (X-axis સેકન્ડમાં TTL છે):

86 (મોટેભાગે SOA રેકોર્ડ માટે) ના નાના બમ્પ સિવાય, તે એકદમ સ્પષ્ટ છે કે TTL નીચી રેન્જમાં છે. ચાલો નજીકથી નજર કરીએ:

ઠીક છે, 1 કલાકથી વધુ TTL આંકડાકીય રીતે નોંધપાત્ર નથી. પછી ચાલો 0-3600 શ્રેણી પર ધ્યાન કેન્દ્રિત કરીએ:

મોટાભાગના TTL 0 થી 15 મિનિટના છે:

વિશાળ બહુમતી 0 થી 5 મિનિટ સુધી છે:

તે બહુ સારું નથી.

સંચિત વિતરણ સમસ્યાને વધુ સ્પષ્ટ બનાવે છે:

અડધા DNS પ્રતિસાદોમાં 1 મિનિટ અથવા તેનાથી ઓછા સમયનો TTL હોય છે, અને ત્રણ-ચતુર્થાંશમાં 5 મિનિટ કે તેથી ઓછાનો TTL હોય છે.

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

તેથી ક્લાયન્ટ નવી વિનંતી મોકલતા પહેલા, સરેરાશ, અડધા મૂળ TTL માટે દરેક એન્ટ્રીનો વાસ્તવમાં ઉપયોગ કરી શકે છે.

કદાચ આ ખૂબ જ ઓછી ટીટીએલ ફક્ત અસામાન્ય વિનંતીઓ પર લાગુ થાય છે અને લોકપ્રિય વેબસાઇટ્સ અને API ને નહીં? ચાલો એક નજર કરીએ:

X અક્ષ TTL છે, Y અક્ષ ક્વેરી લોકપ્રિયતા છે.

કમનસીબે, સૌથી વધુ લોકપ્રિય ક્વેરી પણ કેશ કરવા માટે સૌથી ખરાબ છે.

ચાલો ઝૂમ ઇન કરીએ:

ચુકાદો: તે ખરેખર ખરાબ છે. તે પહેલાથી જ ખરાબ હતું, પરંતુ તે વધુ ખરાબ થયું. DNS કેશીંગ વર્ચ્યુઅલ રીતે નકામું બની ગયું છે. જેમ જેમ ઓછા લોકો તેમના ISP ના DNS રિઝોલ્વરનો ઉપયોગ કરે છે (સારા કારણોસર), લેટન્સીમાં વધારો વધુ ધ્યાનપાત્ર બને છે.

DNS કેશીંગ માત્ર એવી સામગ્રી માટે જ ઉપયોગી બન્યું છે જેની કોઈ મુલાકાત લેતું નથી.

કૃપા કરીને એ પણ નોંધો કે સોફ્ટવેર શકે છે અલગ રીતે નીચા TTL નું અર્થઘટન કરો.

શા માટે?

શા માટે DNS રેકોર્ડ્સ આટલા ઓછા TTL પર સેટ કરવામાં આવે છે?

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

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

વધુમાં, એક-મિનિટના TTLનો અર્થ એ છે કે જો અધિકૃત DNS સર્વર્સ 1 મિનિટથી વધુ સમય માટે અવરોધિત છે, તો અન્ય કોઈ વ્યક્તિ આશ્રિત સેવાઓને ઍક્સેસ કરી શકશે નહીં. અને જો કારણ રૂપરેખાંકન ભૂલ અથવા હેક હોય તો નિરર્થકતા મદદ કરશે નહીં. બીજી બાજુ, વાજબી TTL સાથે, ઘણા ક્લાયન્ટ્સ અગાઉના રૂપરેખાંકનનો ઉપયોગ કરવાનું ચાલુ રાખશે અને ક્યારેય કંઈપણ નોંધશે નહીં.

CDN સેવાઓ અને લોડ બેલેન્સર્સ મોટાભાગે નીચા TTL માટે જવાબદાર છે, ખાસ કરીને જ્યારે તેઓ CNAME ને ઓછા TTL અને રેકોર્ડને સમાન રીતે ઓછા (પરંતુ સ્વતંત્ર) TTL સાથે જોડે છે:

$ drill raw.githubusercontent.com
raw.githubusercontent.com.	9	IN	CNAME	github.map.fastly.net.
github.map.fastly.net.	20	IN	A	151.101.128.133
github.map.fastly.net.	20	IN	A	151.101.192.133
github.map.fastly.net.	20	IN	A	151.101.0.133
github.map.fastly.net.	20	IN	A	151.101.64.133

જ્યારે પણ CNAME અથવા A રેકોર્ડની સમયસીમા સમાપ્ત થાય છે, ત્યારે નવી વિનંતી મોકલવી આવશ્યક છે. બંને પાસે 30 સેકન્ડ TTL છે, પરંતુ તે સમાન નથી. વાસ્તવિક સરેરાશ TTL 15 સેકન્ડ હશે.

પરંતુ રાહ જુઓ! તે વધુ ખરાબ છે. કેટલાક નિરાકરણકર્તાઓ આ પરિસ્થિતિમાં બે સંકળાયેલ નીચા TTL સાથે ખૂબ જ ખરાબ રીતે વર્તે છે:

$ ડ્રિલ raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 માં CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133

લેવલ3 રિઝોલ્વર કદાચ BIND પર ચાલે છે. જો તમે આ વિનંતિ મોકલવાનું ચાલુ રાખો છો, તો હંમેશા 1 નો TTL પરત કરવામાં આવશે. આવશ્યકપણે, raw.githubusercontent.com ક્યારેય કેશ્ડ નથી.

અહીં ખૂબ જ લોકપ્રિય ડોમેન સાથે આવી પરિસ્થિતિનું બીજું ઉદાહરણ છે:

$ drill detectportal.firefox.com @1.1.1.1
detectportal.firefox.com.	25	IN	CNAME	detectportal.prod.mozaws.net.
detectportal.prod.mozaws.net.	26	IN	CNAME	detectportal.firefox.com-v2.edgesuite.net.
detectportal.firefox.com-v2.edgesuite.net.	10668	IN	CNAME	a1089.dscd.akamai.net.
a1089.dscd.akamai.net.	10	IN	A	104.123.50.106
a1089.dscd.akamai.net.	10	IN	A	104.123.50.88

ઓછામાં ઓછા ત્રણ CNAME રેકોર્ડ. એય. એક પાસે યોગ્ય TTL છે, પરંતુ તે સંપૂર્ણપણે નકામું છે. અન્ય CNAME માં 60 સેકન્ડનો પ્રારંભિક TTL હોય છે, પરંતુ ડોમેન્સ માટે akamai.net મહત્તમ TTL 20 સેકન્ડ છે અને તેમાંથી કોઈ પણ તબક્કામાં નથી.

એપલ ઉપકરણોનું સતત મતદાન કરતા ડોમેન્સ વિશે શું?

$ drill 1-courier.push.apple.com @4.2.2.2
1-courier.push.apple.com.	1253	IN	CNAME	1.courier-push-apple.com.akadns.net.
1.courier-push-apple.com.akadns.net.	1	IN	CNAME	gb-courier-4.push-apple.com.akadns.net.
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.84
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.85

Firefox અને TTL જેવી જ સમસ્યા લેવલ1 રિઝોલ્વરનો ઉપયોગ કરતી વખતે મોટાભાગે 3 સેકન્ડે અટકી જશે.

ડ્રૉપબૉક્સ?

$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 CNAME client.dropbox-dns.com માં. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ ડ્રિલ client.dropbox.com @4.2.2.2 client.dropbox.com. 1 CNAME client.dropbox-dns.com માં. client.dropbox-dns.com. 1 IN A 162.125.64.3

રેકોર્ડિંગ પર safebrowsing.googleapis.com TTL મૂલ્ય 60 સેકન્ડ છે, જેમ કે Facebook ડોમેન્સ. અને, ફરીથી, ક્લાયંટના દૃષ્ટિકોણથી, આ મૂલ્યો અડધા થઈ ગયા છે.

ન્યૂનતમ TTL સેટ કરવા વિશે કેવી રીતે?

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

હાલના રેકોર્ડની સમયસીમા સમાપ્ત થયા પછી 47,4% વિનંતીઓ કરવામાં આવી હતી. આ ગેરવાજબી રીતે વધારે છે.

જો ન્યૂનતમ TTL સેટ કરવામાં આવે તો કેશીંગ પર શું અસર થશે?

X અક્ષ એ ન્યૂનતમ TTL મૂલ્યો છે. આ મૂલ્યથી ઉપરના સ્ત્રોત TTL સાથેના રેકોર્ડ્સ પ્રભાવિત થતા નથી.

Y અક્ષ એ ક્લાયન્ટની વિનંતીઓની ટકાવારી છે કે જેની પાસે પહેલેથી જ કેશ્ડ એન્ટ્રી છે, પરંતુ તે સમાપ્ત થઈ ગઈ છે અને નવી વિનંતી કરી રહી છે.

ફક્ત ન્યૂનતમ TTL ને 47 મિનિટ પર સેટ કરીને "વધારાની" વિનંતીઓનો હિસ્સો 36% થી ઘટાડીને 5% કરવામાં આવે છે. ન્યૂનતમ TTL ને 15 મિનિટ પર સેટ કરીને, આ વિનંતીઓની સંખ્યા ઘટીને 29% થઈ જાય છે. 1 કલાકનું ન્યૂનતમ TTL તેમને 17% સુધી ઘટાડે છે. નોંધપાત્ર તફાવત!

સર્વર બાજુ પર કંઈપણ બદલવું નહીં, પરંતુ તેના બદલે ક્લાયંટ DNS કેશ (રાઉટર્સ, સ્થાનિક રિઝોલ્વર્સ) માં ન્યૂનતમ TTL સેટ કરવા વિશે કેવી રીતે?

જરૂરી વિનંતીઓની સંખ્યા 47 મિનિટના ન્યૂનતમ TTL સાથે 34% થી ઘટીને 5%, ઓછામાં ઓછી 25 મિનિટ સાથે 15% અને ઓછામાં ઓછા 13 કલાક સાથે 1% થઈ જાય છે. કદાચ 40 મિનિટ શ્રેષ્ઠ છે.

આ નાના ફેરફારની અસર પ્રચંડ છે.

પરિણામો શું છે?

અલબત્ત, સેવાને નવા ક્લાઉડ પ્રદાતા, નવા સર્વર, નવા નેટવર્ક પર ખસેડી શકાય છે, જેમાં ગ્રાહકોને નવીનતમ DNS રેકોર્ડ્સનો ઉપયોગ કરવાની જરૂર છે. અને એકદમ નાનું ટીટીએલ આવા સંક્રમણને સરળ અને અસ્પષ્ટ રીતે કરવામાં મદદ કરે છે. પરંતુ નવા ઈન્ફ્રાસ્ટ્રક્ચરમાં સંક્રમણ સાથે, કોઈ પણ ક્લાયન્ટ 1 મિનિટ, 5 મિનિટ અથવા 15 મિનિટની અંદર નવા DNS રેકોર્ડ્સ પર સ્થાનાંતરિત થવાની અપેક્ષા રાખતું નથી. લઘુત્તમ TTL ને 40 મિનિટને બદલે 5 મિનિટ પર સેટ કરવાથી વપરાશકર્તાઓને સેવા ઍક્સેસ કરવાથી અટકાવવામાં આવશે નહીં.

જો કે, આ લેટન્સીમાં નોંધપાત્ર ઘટાડો કરશે અને બિનજરૂરી વિનંતીઓને ટાળીને ગોપનીયતા અને વિશ્વસનીયતામાં સુધારો કરશે.

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

જો તમે અધિકૃત DNS સર્વર્સ સાથે કામ કરી રહ્યા છો, તો કૃપા કરીને તમારા TTL તપાસો. શું તમને ખરેખર આવા હાસ્યાસ્પદ નીચા મૂલ્યોની જરૂર છે?

અલબત્ત, DNS રેકોર્ડ્સ માટે નાના TTL સેટ કરવાના સારા કારણો છે. પરંતુ DNS ટ્રાફિકના 75% માટે નહીં જે વર્ચ્યુઅલ રીતે યથાવત રહે છે.

અને જો કોઈ કારણોસર તમારે ખરેખર DNS માટે ઓછા TTL નો ઉપયોગ કરવાની જરૂર હોય, તો તે જ સમયે ખાતરી કરો કે તમારી સાઇટ પર કેશીંગ સક્ષમ નથી. એ જ કારણોસર.

જો તમારી પાસે સ્થાનિક DNS કેશ ચાલી રહ્યું હોય, જેમ કે dnscrypt-પ્રોક્સીજે તમને ન્યૂનતમ TTL સેટ કરવાની પરવાનગી આપે છે, આ ફંક્શનનો ઉપયોગ કરો. આ સારું છે. કંઈ ખરાબ થશે નહીં. ન્યૂનતમ TTL ને આશરે 40 મિનિટ (2400 સેકન્ડ) અને 1 કલાક પર સેટ કરો. તદ્દન વાજબી શ્રેણી.

સોર્સ: www.habr.com