എല്ലായ്പ്പോഴും ഡി. എൻ. എസ് ആണ്.

സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാരുടെ ഇടയില് ഒരു പ്രശസ്ത ഹൈക്കു ഉണ്ട്:

അത് ഡി. എൻ. എസ് അല്ല. അത് ഡി. എൻ. എസ് ആകാൻ വഴിയില്ല. അത് ഡി. എൻ. എസ് ആയിരുന്നു.

അത് സത്യമാണ് എന്നതുകൊണ്ട് തന്നെ അത് രസകരമാണ്. കഴിഞ്ഞ വർഷങ്ങളിലെ ഏറ്റവും വലിയ ചില തകരാറുകൾ, ക്ലൌഡ് പ്രൊവൈഡറുകളിലും വലിയ വെബ്സൈറ്റുകളിലും, ഡിഎൻഎസ് പ്രശ്നങ്ങളിലേക്ക് വന്നതാണ്. ദൈനംദിന ജോലിയിലും ആപ്പ് കണക്ട് ചെയ്യാൻ പറ്റുന്നില്ല എന്ന വലിയൊരു ഭാഗം രഹസ്യങ്ങൾ അവസാനിക്കുന്നത് ആരെങ്കിലും പറയും "ഓ, അത് പഴയ വിലാസത്തിലേക്ക് പരിഹരിക്കുന്നു"

ഡി. എൻ. എസിന് റെ പ്രശ്നം

ഡിഎൻഎസ് എന്തിനാണ് എല്ലായിടത്തും ഉള്ളത്?

മിക്കവാറും എല്ലാ നെറ്റ് വർക്ക് കണക്ഷനും തുടങ്ങുന്നത് ഒരു ഡി. എൻ. എസ്. തിരയലിലൂടെയാണ്. നിങ്ങളുടെ ബ്രൌസർ, നിങ്ങളുടെ ആപ്പ് അതിന്റെ ഡാറ്റാബേസിലേക്ക് കണക്ട് ചെയ്യുന്നു, മറ്റൊരു സേവനത്തെ വിളിക്കുന്ന ഒരു പാഡ്, ഒരു ഐ. സി. ജോലി ഒരു ചിത്രം എടുക്കുന്നു. ഡിഎൻഎസ് പതുക്കെയാണെങ്കിൽ, എല്ലാം പതുക്കെയാണ്. അത് തെറ്റാണെങ്കിൽ, എല്ലാം തെറ്റായ സ്ഥലത്തേക്കു പോകും. അത് ഓഫ് ആണെങ്കിൽ, ഒന്നും പ്രവർത്തിക്കില്ല, എല്ലാ സെർവറുകളും ആരോഗ്യകരമാണെങ്കിലും.

ഡിഎൻഎസ് പല തലങ്ങളിലും കാഷെ ചെയ്തിരിക്കുന്നു: ആപ്ലിക്കേഷനുകളിലും, ഓപ്പറേറ്റിങ് സിസ്റ്റങ്ങളിലും, ലോക്കൽ റെസലൂഷനുകളിലും നിങ്ങളുടെ ISP-യിലും. അതായത് പ്രശ്നങ്ങൾ അസ്ഥിരവും വൈകുന്നതും പുനർനിർമ്മിക്കാൻ വളരെ പ്രയാസമുള്ളതുമാണ്.

റെക്കോർഡുകളും ടിടിഎല്ലുകളും

നിങ്ങള് ഏറ്റവും കൂടുതല് ജോലി ചെയ്യുന്ന റെക്കോഡുകള്:

• എ / എഎഎഎ: ഐ. പി. വി. 4 / ഐ. പി . വി. 6 വിലാസത്തിന്റെ പേര്.
• സി. എൻ. എം.: മറ്റൊരു പേരിന് റെ അപരനാമം. (അത് സോൺ അപ്ക്സിൽ ഉപയോഗിക്കാൻ കഴിയില്ല example.com; സേവനദാതാക്കൾ അതിനായി ALIAS അല്ലെങ്കിൽ ANAME രേഖകൾ വാഗ്ദാനം ചെയ്യുന്നു.
• TXT: സ്വമേധയാ ഉള്ള വാചകം, ഡൊമെയ്ൻ പരിശോധനയ്ക്കായി ഉപയോഗിക്കുന്നു, SPF, DKIM, ACME വെല്ലുവിളികൾ.
• MXമെയിൽ സെര് വറുകള് .
• എസ്ആര്വി: തുറമുഖങ്ങളുമായി സേവന കണ്ടെത്തൽ.
• എൻ എസ് / എസ് ഒ എ: ഏത് സെർവറുകളാണ് ഒരു സോണിന് ആധികാരികതയുള്ളത്.

TTL (ജീവിതകാലം) ഒരു ഉത്തരം എത്രനേരം കാഷെ ചെയ്യണമെന്ന് റെസലൂഷന് മാരെ അറിയിക്കുന്നു. അത് നിങ്ങളുടെ ഏറ്റവും പ്രധാനപ്പെട്ട ലവലാണ്:

• കുറഞ്ഞ ടിടിഎൽ (60 മുതൽ 300 സെക്കൻഡ് വരെ): മാറ്റങ്ങൾ പെട്ടെന്ന് തന്നെ പ്രാബല്യത്തിലാകുന്നു. അടിയന്തര സാഹചര്യത്തില് മാറ്റേണ്ട റെക്കോർഡുകൾക്ക് നല്ലതാണ്, ഫയല് ഓവര് എന് ഡ്പോയിന്റ്സ് പോലെ.
• ഉയർന്ന ടിടിഎൽ (മണിക്കൂർ): ഡിഎൻഎസിന് കുറവ് ലോഡ്, നിങ്ങളുടെ ഡിഎൻഎസ് ദാതാവിന് പ്രശ്നമുണ്ടെങ്കിൽ കൂടുതൽ പ്രതിരോധശേഷി. സ്ഥിരതയുള്ള രേഖകൾക്കായി നല്ലതാണ്.

ഒരു ക്ലാസിക് തെറ്റ്: ഒരു മൈഗ്രേഷൻ പ്ലാനിംഗ്, റെക്കോർഡ് മാറ്റം, പഴയ ടിടിഎല് കണ്ടെത്തൽ 24 മണിക്കൂറായിരുന്നു. ഒന്നോ രണ്ടോ ദിവസം മുമ്പ് TTL കുറയ്ക്കുക. ഒരു ആസൂത്രിത മാറ്റം, പിന്നെ അത് പിന്നീട് വീണ്ടും ഉയർത്തുക.

ഡിഎൻഎസ് മാറ്റങ്ങൾ നിങ്ങൾ വരുമ്പോൾ സംഭവിക്കുന്നില്ല. ലോകത്തിലെ അവസാനത്തെ കാഷെ പഴയ ഉത്തരം മറന്നുപോയപ്പോൾ അവ സംഭവിക്കുന്നു.

കുബർനെറ്റിനു ഉള്ളിലെ DNS

കുബർനെറ്റിന് സ്വന്തമായി ഡിഎൻഎസ് ഉണ്ട്, സാധാരണയായി കോര് ഡ് എൻ എസ്. ഓരോ സേവനത്തിനും ഒരു പേര് കിട്ടും orders.shop.svc.cluster.local.

ചില കാര്യങ്ങൾ ആളുകളെ ഇടറുന്നു:

• ചെറിയ പേരുകൾ ഒരേ നാമമേഖലയില് മാത്രമേ പ്രവർത്തിക്കൂ. orders പ്രവര് ത്തനങ്ങള് shop നെയിംസ്പെയ്സ്; മറ്റെവിടെ നിന്നും, ഉപയോഗിക്കുക orders.shop അല്ലെങ്കിൽ മുഴുവൻ പേരും.
• സി. ndots:5 ക്രമീകരണം. സ്ഥിരസ്ഥിതിയായി, അഞ്ച് ഡോട്ടുകളിൽ കുറവുള്ള പേരുകൾ ബന്ധുക്കളായി കണക്കാക്കുകയും ആദ്യം നിരവധി തിരയൽ ഡൊമെയ്നുകൾ പരീക്ഷിക്കുകയും ചെയ്യുന്നു. ഒരു തിരച്ചിൽ api.example.com യഥാർത്ഥ അന്വേഷണത്തിനു മുമ്പ് പല പരാജയപ്പെട്ട അന്വേഷണങ്ങളും സൃഷ്ടിക്കാൻ കഴിയും. ബാഹ്യ നാമങ്ങളുടെ കാര്യത്തിൽ, ഒരു അവസാന പോയിന്റ് (api.example.com.) അല്ലെങ്കിൽ ട്യൂണിങ് ndots കപ്പലില് dnsConfig അത് കുറയ്ക്കുന്നു.
• കോര് ഡിഎന് എസ് ഒരു കുടുക്ക് തടസ്സമാകാം തിരക്കേറിയ കൂട്ടത്തില് . അത് അളക്കുക, പരിഗണിക്കുക NodeLocal DNSCache എന്നതിനായി, ഓരോ നോഡിലും ഒരു കാഷെ പ്രവർത്തിപ്പിക്കുന്നു.
• കരാറുകളും യുഡിപിയും ചില സെറ്റപ്പുകളിൽ ഇടയ്ക്കിടെയുള്ള വേഗത കുറഞ്ഞ തിരയലുകൾ (ക്ലാസിക് അഞ്ച് സെക്കൻഡ് കാലതാമസം) ഉണ്ടാക്കുന്നു. നോഡ് ലോക്കൽ ഡിഎൻഎസ്കാഷും ആ കാര്യത്തിലും സഹായിക്കുന്നു.

എക്സ്റ്റേണൽ ഡിഎൻഎസ്

ഓരോ സേവനത്തിനും പൊതു ഡിഎൻഎസ് റെക്കോർഡുകൾ കൈകൊണ്ട് കൈകാര്യം ചെയ്യുന്നത് പിശകുകൾക്ക് വിധേയമാണ്. എക്സ്റ്റേണൽ ഡിഎൻഎസ് കുബർനെറ്റസ് റിസോഴ്സുകൾ (സേവനങ്ങൾ, പ്രവേശനം, ഗേറ്റ്വേ API റൂട്ടുകൾ) നിരീക്ഷിക്കുകയും റൂട്ട് 53, ക്ലൌഡ് ഡിഎൻഎസ്, അസ്യൂർ ഡിഎൻഎസ്, ക്ലൌഡ്ഫ്ലെയർ എന്നിവയിലും മറ്റു പലതിലും സ്വപ്രേരിതമായി ഡിഎൻ എസ് റെക്കോർഡുകൾ സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
  namespace: shop
spec:
  parentRefs:
  - name: web
    namespace: infra
  hostnames: ["shop.example.com"]   # ExternalDNS creates this record
  rules:
  - backendRefs:
    - name: shop-api
      port: 8080

ഒരു TXT രജിസ്ട്രി അത് സ്വന്തമായിട്ടുള്ള രേഖകളിലേക്ക് മാത്രം സ്പർശിക്കുന്നു. ഡൊമെയ്ൻ ഫിൽട്ടർ അതുകൊണ്ട് അത് പാടില്ലാത്ത മേഖലകളെ മാറ്റാൻ കഴിയില്ല.

DNS അടിസ്ഥാനമാക്കിയുള്ള പരാജയമാറ്റം

ഡിഎൻഎസിന് ട്രാഫിക് പരാജയങ്ങളിൽ നിന്നും അകറ്റാൻ കഴിയും:

• ആരോഗ്യ പരിശോധനയിലൂടെയുള്ള പരാജയമാറ്റം രേഖകൾ (റൂട്ട് 53, ക്ലൌഡ്ഫ്ലെയർ, അസ്യൂർ ട്രാഫിക് മാനേജർ, മറ്റുള്ളവ): പ്രാഥമിക എൻഡ് പോയിന്റ് ആരോഗ്യ പരിശോധനകളിൽ പരാജയപ്പെട്ടാൽ, ഡിഎൻഎസ് ദ്വിതീയമായത് തിരികെ നൽകാൻ തുടങ്ങുന്നു.
• ലേറ്റൻസി അടിസ്ഥാനമാക്കിയുള്ള അല്ലെങ്കിൽ ജിയോ റൂട്ടിംഗ്: ഉപയോക്താക്കളെ അടുത്തുള്ള പ്രദേശത്തേക്ക് അയയ്ക്കുക.
• ഭാരമുള്ള രേഖകൾ: മൈഗ്രേഷന് സമയത്ത് പഴയതും പുതിയതുമായ പരിതസ്ഥിതികൾക്കിടയിലുള്ള ട്രാഫിക് ക്രമേണ മാറ്റുക.

TTL ഓർക്കുക: കേസ് ഓവർ ചെയ്യാനുള്ള വേഗത കാഷെ കാലാവധി തീരുന്നതനുസരിച്ചായിരിക്കും. ചില ക്ലയന്റുകൾ TTL പറയുന്നതിനേക്കാൾ വളരെ കൂടുതലായി DNS കാഷെ ചെയ്യുന്നു (പഴയ ജാവ പതിപ്പുകൾ ഇതിനു പ്രശസ്തമായിരുന്നു).

ഞാന് കണ്ടിട്ടുള്ള (നിങ്ങളും കാണും)

• കാലഹരണപ്പെട്ട ഡൊമെയ്ൻ അല്ലെങ്കിൽ രജിസ്ട്രാർ പേയ്മെന്റ് കാലഹരണപ്പെട്ടതായിരിക്കാം.
• മൈഗ്രേഷന് സമയത്ത് തെറ്റായ TTL: പഴയ സിസ്റ്റത്തിലെ പകുതി ഉപയോക്താക്കളും ഒരു ദിവസം.
• മായ്ക്കപ്പെട്ടതോ തിരുത്തിയെഴുതിയതോ ആയ റെക്കോർഡുകൾ അവയെ സ്വന്തമാക്കിയെന്ന് കരുതിയ ഒരു ഉപകരണമാണ്.
• ഇന്റീരിയർ റെസലൂഷനുകൾ അടച്ചു, എല്ലാ സേവനങ്ങളും ഒരേസമയം പരാജയപ്പെടും, സെര് വറുകള് തന്നെ ആരോഗ്യമുള്ള സമയത്ത്.
• വിഭജിത ദർശന ആശയക്കുഴപ്പം: നെറ്റ് വർക്കിനകത്തും പുറത്തും പേര് വ്യത്യസ്തമായി പരിഹരിക്കപ്പെടുന്നു, തെറ്റായ ഭാഗത്തുനിന്നുള്ള ഒരാളെ പരിശോധിക്കുന്നു.
• DNSSEC തെറ്റായ ക്രമീകരണം ഒരു ഡൊമെയ്നിനെ പരിഹരിക്കാനാവാത്തതാക്കുന്നു.

എന്റെ ഡീബഗ് റൂട്ടിൻ

dig shop.example.com +short                 # what does my resolver say?
dig @1.1.1.1 shop.example.com +short        # what does a public resolver say?
dig shop.example.com +trace                 # follow it from the root
dig shop.example.com NS                     # who is authoritative?
kubectl run -it --rm dnstest --image=busybox:1.36 -- nslookup orders.shop   # from inside the cluster

വ്യത്യസ്ത സ്ഥലങ്ങളിൽ നിന്നുള്ള ഉത്തരങ്ങൾ താരതമ്യം ചെയ്യുക. അവ തമ്മിൽ വ്യത്യാസമുണ്ടെങ്കിൽ അത് കാഷിംഗ് അല്ലെങ്കിൽ സ്പ്ലിറ്റ് ഹൊറിസോൺ ആണ്. ആധികാരികമായ ഉത്തരം തെറ്റാണെങ്കിൽ, അത് റെക്കോർഡ് തന്നെ.

എങ്ങനെയാണ് ഡിഎൻഎസ് കേടാകുന്നത് കുറയ്ക്കുന്നത്?

റെക്കോർഡുകൾ കോഡായി അല്ലെങ്കിൽ ExternalDNS ഉപയോഗിച്ച് നിയന്ത്രിക്കുക, TTL കൾ മനഃപൂർവ്വം ആസൂത്രണം ചെയ്യുക, നിങ്ങളുടെ ഡൊമെയ്നുകളും സർട്ടിഫിക്കറ്റുകളും നിരീക്ഷിക്കുക, വർക്ക് ലോഡുകൾക്ക് സമീപമുള്ള DNS കാഷെ ചെയ്യുക, ക്ലയന്റ് യഥാർത്ഥത്തിൽ എവിടെയാണെന്ന് എല്ലായ്പ്പോഴും പരിശോധിക്കുക.

എന്റെ അഭിപ്രായം: ഡിഎൻഎസ് ലളിതമാണ്, അത് അങ്ങനെ അല്ല. അതിനെ ഒരു നിർണായക അടിസ്ഥാന സൌകര്യമായി കണക്കാക്കുക, കാരണം എല്ലാ അഭ്യർത്ഥനകളും ആദ്യം തൊടുന്ന ഒന്നാണ് അത്.

ഡെസ്ലി