CDN അതിന്റെ വിലാസങ്ങൾ മാറ്റുമ്പോൾ VPN ഡൊമെയ്ൻ നിയമം തകരുന്നു
ഒരു DNS ഉത്തരം ഒരു സ്നാപ്ഷോട്ടാണ്, ഇൻവെന്ററിയല്ല. പേരിനെ അടിസ്ഥാനമാക്കിയ നിയമമോ വ്യക്തമായ പ്രിഫിക്സോ CDN പിന്തുണയുള്ള സേവനത്തിന് അനുയോജ്യമാണോ എന്ന് മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു.
ഒരു ലുക്കപ്പിൽ നിന്നുള്ള വിലാസം നിങ്ങളുടെ റൂട്ടിംഗ് നിയമത്തിലേക്ക് പകർത്തുന്നു, സൈറ്റ് പ്രവർത്തിക്കുന്നു, ഒരാഴ്ച കഴിഞ്ഞ് പ്രവർത്തിക്കുന്നില്ല. നിയമത്തിൽ ഒന്നും മാറിയില്ല. സേവനം മറ്റൊരു എഡ്ജ് വിലാസത്തിലേക്ക് മാറി, ക്ലയന്റ് മറ്റൊരു ഹോസ്റ്റ്നാമം പരിഹരിച്ചു, അല്ലെങ്കിൽ സെഷൻ IPv6-ലേക്ക് മാറി. നിങ്ങളുടെ മുന്നിലുള്ള തീരുമാനം പേരിനെ അടിസ്ഥാനമാക്കിയ നിയമമോ വ്യക്തമായ ശ്രേണിയോ ഈ സേവനത്തിന് ശരിയായ ഉപകരണമാണോ എന്നാണ്, മൂന്ന് വ്യവസ്ഥകൾ അത് തീരുമാനിക്കുന്നു. തുടർന്നുള്ളത് പേരിനെ വിലാസത്തിൽ നിന്ന് വേർതിരിക്കുന്നു, കാരണം അവയിൽ ഒന്ന് മാത്രമാണ് സ്ഥിരമായത്.
ഒരു ലുക്കപ്പ് ഇൻവെന്ററി ആകാത്തത് എന്തുകൊണ്ട്
ഒരു ഉള്ളടക്ക വിതരണ ശൃംഖല റിസോൾവറിനും പ്രദേശത്തിനും നിമിഷത്തിനും തിരഞ്ഞെടുത്ത വിലാസത്തോടെ ഉത്തരം നൽകുന്നു. വ്യത്യസ്ത നെറ്റ്വർക്കുകളിൽ നിന്ന് രണ്ടുതവണ ചോദിക്കുക, വ്യത്യസ്ത ഉത്തരങ്ങൾ ലഭിച്ചേക്കാം. ഒരിക്കൽ ചോദിച്ച് ഉത്തരത്തെ സേവനത്തിന്റെ വിലാസ പട്ടികയായി കണക്കാക്കുക, എന്നാൽ നിങ്ങൾ എഴുതുന്ന നിയമം നിയമമല്ല, ഒരു സ്നാപ്ഷോട്ടാണ്. DNS ഉത്തരത്തെ കോൺഫിഗറേഷനായി കാണുന്നതിന്റെ മുഴുവൻ പ്രശ്നവും അതാണ്.
രണ്ടാമതൊരു വിടവുണ്ട്. ഒരു ദൃശ്യമായ ഹോസ്റ്റ്നാമം മുഴുവൻ അപ്ലിക്കേഷനെയും അപൂർവ്വമായി ഉൾക്കൊള്ളുന്നു, കാരണം ലോഗിൻ, മീഡിയ, API ട്രാഫിക് എന്നിവ പലപ്പോഴും വെവ്വേറെ പേരുകൾ ഉപയോഗിക്കുന്നു. അഡ്രസ് ബാറിലെ ഹോസ്റ്റ്നാമിൽ നിന്ന് നിർമ്മിച്ച നിയമം പേജ് ഉൾക്കൊള്ളുകയും വീഡിയോ നഷ്ടപ്പെടുകയും ചെയ്യാം, ഇത് റൂട്ടിംഗ് പിശകല്ല, ഭാഗിക പരാജയമായി വായിക്കപ്പെടുന്നു.
മൂന്നാമത്തെ വിടവ് വിലാസ കുടുംബമാണ്. v4-ന് മാത്രമുള്ള നിയമം ക്ലയന്റ് ഇഷ്ടപ്പെടാവുന്ന AAAA റെക്കോർഡിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
ഡൊമെയ്ൻ നിയമമോ ശ്രേണികളോ തീരുമാനിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ
ഒന്നാമതായി, നിങ്ങൾക്ക് ഉടമസ്ഥതയും രേഖപ്പെടുത്തലും ചെയ്യാവുന്ന സ്ഥിരമായ പ്രിഫിക്സുകളുടെ ഒരു കൂട്ടം സേവനം പ്രസിദ്ധീകരിക്കുന്നുണ്ടോ? ഉണ്ടെങ്കിൽ, വ്യക്തമായ ശ്രേണികൾ സത്യസന്ധവും വിലകുറഞ്ഞതുമാണ്. ഇല്ലെങ്കിൽ, ഡൊമെയ്ൻ നിയമം മാത്രമാണ് സേവനത്തെ പിന്തുടരാൻ കഴിയുന്ന സംവിധാനം.
രണ്ടാമതായി, നിങ്ങളുടെ ക്ലയന്റിന്റെ ഡൊമെയ്ൻ സംവിധാനം പുതുക്കപ്പെടുന്നുണ്ടോ? കണക്ട് ചെയ്യുമ്പോൾ ഒരിക്കൽ പരിഹരിച്ച് പിന്നീട് ഒരിക്കലും പുതുക്കാത്ത നിയമം മികച്ച ബ്രാൻഡിംഗുള്ള ഒരു സ്നാപ്ഷോട്ടാണ്. മൂന്നാമതായി, സംവിധാനം സബ്ഡൊമെയ്നുകളും രണ്ട് വിലാസ കുടുംബങ്ങളും ഉൾക്കൊള്ളുന്നുണ്ടോ, അതോ നിങ്ങൾ ടൈപ്പ് ചെയ്ത പേരുകൾ മാത്രമോ?
ഈ മൂന്നിനും ഉത്തരം നൽകുക, തിരഞ്ഞെടുപ്പ് സാധാരണയായി വ്യക്തമാണ്. ഊഹിക്കൽ പരീക്ഷണത്തിൽ പ്രവർത്തിക്കുകയും ഉൽപാദനത്തിൽ പരാജയപ്പെടുകയും ചെയ്യുന്ന നിയമം സൃഷ്ടിക്കുന്നു.
ഒരു സെഷൻ പരീക്ഷിക്കുക, ഒരു പേജല്ല
പേജ് ലോഡ് ചെയ്യുക, തുടർന്ന് പ്രധാന പ്രവർത്തനം നടത്തുക: സൈൻ ഇൻ ചെയ്യുക, പ്ലേബാക്ക് ആരംഭിക്കുക, ഒരു ഫയൽ അപ്ലോഡ് ചെയ്യുക. അവയിൽ ഓരോന്നും വ്യത്യസ്ത ഹോസ്റ്റിൽ എത്താം, പരാജയപ്പെടുന്നത് നിങ്ങളുടെ നിയമം വിട്ടുപോയതാണ്.
പേജ് കാണിക്കുന്നതല്ല, സെഷൻ യഥാർത്ഥത്തിൽ എന്തുമായി ബന്ധപ്പെടുന്നു എന്ന് പട്ടികപ്പെടുത്തുക:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5താരതമ്യത്തിനിടയിൽ റിസോൾവർ ദൃശ്യമായി സൂക്ഷിക്കുക, കാരണം ഒരു റിസോൾവറിൽ നിന്ന് പ്രവർത്തിക്കുകയും മറ്റൊന്നിൽ നിന്ന് പരാജയപ്പെടുകയും ചെയ്യുന്ന നിയമം നിങ്ങളോട് CDN-ന്റെ ഉത്തരത്തെക്കുറിച്ചാണ് പറയുന്നത്, ടണലിനെക്കുറിച്ചല്ല. ചെറിയ TTL എന്നത് നിങ്ങൾ രേഖപ്പെടുത്തിയ ഉത്തരത്തിന് ഒരു കാലാവധിയുണ്ടെന്നും അർത്ഥമാക്കുന്നു.
ഓരോ സംവിധാനവും യഥാർത്ഥത്തിൽ എന്ത് ഉൾക്കൊള്ളുന്നു
രണ്ട് സംവിധാനങ്ങളും സെറ്റിംഗ്സ് പേജിൽ പരസ്പരം മാറ്റാവുന്നതായി തോന്നുന്നു, ഉള്ളിൽ വ്യത്യസ്തമായി പെരുമാറുന്നു.
| Mechanism | What it matches | How it fails |
|---|---|---|
| Domain rule | Names the client resolves, then their addresses | Misses subdomains, or goes stale when refresh is off |
| Address route | A prefix you wrote down | Keeps matching an address the service has left |
കേർണൽ വിലാസ റൂട്ട് പ്രിഫിക്സുകൾ പൊരുത്തപ്പെടുത്തുന്നു. ഹോസ്റ്റ്നാമം എന്താണെന്ന് അതിന് അറിയില്ല, അതിനാൽ വിലാസങ്ങൾ മാറ്റുന്ന സേവനത്തെ പിന്തുടരാൻ കഴിയില്ല. ഡൊമെയ്ൻ നിയമം പേരുകൾ പരിഹരിച്ച് ഫലം റൂട്ട് ചെയ്യുന്നു; അത് സേവനത്തെ പിന്തുടരുന്നു, പക്ഷേ റിസോൾവർ, പുതുക്കൽ സ്വഭാവം, സബ്ഡൊമെയ്നുകളോടുള്ള ക്ലയന്റിന്റെ സമീപനം എന്നിവയെ ആശ്രയിക്കുന്നു, അതിനാൽ പേരുകളെ പിന്തുടരുന്ന നിയമം ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന റിസോൾവറുമായി പരീക്ഷിക്കണം.
ഒന്നും മറ്റൊന്നിന്റെ സൂപ്പർസെറ്റല്ല, അതിനാൽ കുറിപ്പില്ലാതെ അവ മിശ്രണം ചെയ്യുന്നത് പിന്നീട് ആശയക്കുഴപ്പം സൃഷ്ടിക്കുന്നു.
സേവനം മാറിയതിന് ശേഷം വീണ്ടും പരിശോധിക്കുക
ക്ലയന്റ് അപ്ഡേറ്റിനോ സേവന മാറ്റത്തിനോ ശേഷം അതേ സെഷൻ പരീക്ഷണം വീണ്ടും പ്രവർത്തിപ്പിക്കുക. മുമ്പ് പ്രവർത്തിച്ച വിലാസ പട്ടിക ആ കാലയളവിന്റെ തെളിവാണ്, സേവനത്തിന്റെ അടിസ്ഥാന സൗകര്യത്തിന്റെ സ്ഥിരമായ ഇൻവെന്ററിയല്ല.
ഏത് സംവിധാനം ഏത് ഹോസ്റ്റ്നാമം ഉൾക്കൊള്ളുന്നു, അവസാന പരിശോധനയുടെ തീയതി എന്നിവ എഴുതിവയ്ക്കുക.
ആ കുറിപ്പാണ് നിങ്ങൾക്ക് പ്രതിരോധിക്കാവുന്ന നിയമവും ആരും തൊടാൻ ധൈര്യപ്പെടാത്ത നിയമവും തമ്മിലുള്ള വ്യത്യാസം. സേവനം സ്വന്തം പ്രിഫിക്സ് പട്ടിക പ്രസിദ്ധീകരിക്കുന്നുവെങ്കിൽ അത് ഉപയോഗിക്കുകയും തീയതി പരാമർശിക്കുകയും ചെയ്യുക. ഇല്ലെങ്കിൽ അത് പറയുക, ഡൊമെയ്ൻ നിയമം അതിന്റെ പുതുക്കൽ സ്വഭാവത്തോടെ അരികിൽ എഴുതിവയ്ക്കുക.