የDNS TTLን ምን ያህል አስቀድሜ መቀነስ አለብኝ?

ቢያንስ የአሁኑን TTL ያህል አስቀድመው፣ በተሻለ ሁኔታ ደግሞ ከማዛወሩ አንድ ወይም ሁለት ቀን በፊት። መዝገቡ የ86400 ሴኮንድ TTL ካለው፣ resolvers የድሮውን መልስ ሙሉ ቀን ሊይዙት ይችላሉ፣ ስለዚህ ከመቀየሩ አንድ ሰዓት በፊት መቀነስ ምንም አይጠቅምም።

በእውነት ምንም መቋረጥ ሳይኖር ማዛወር ይቻላል?

ሁኔታ ለሌላቸው አገልግሎቶች አዎ፦ ሁለቱንም አገልጋዮች ያሂዱ፣ DNSን ይቀይሩ፣ ትራፊኩም እንዲሸጋገር ይተዉት። ጽሑፍ ለሚቀበል የውሂብ ጎታ ደግሞ፣ በመጨረሻው ማመሳሰል ወቅት አጭር የጽሑፍ ማቆምን ይቀበላሉ፣ ወይም አዲሱ አገልጋይ ሁልጊዜ ወቅታዊ እንዲሆን replication ያዘጋጃሉ።

DNSን ከመቀየሬ በፊት አዲሱን አገልጋይ እንዴት እፈትሻለሁ?

የእርስዎን ማሽን ብቻ ወደ እሱ ያመላክቱ። ለእውነተኛ ዶሜይንዎ ጥያቄን ወደ አዲሱ IP ለመላክ curlን ከ--resolve ጋር ይጠቀሙ፣ ወይም በhosts ፋይልዎ ጊዜያዊ መስመር ያክሉ። ሌሎቹ ሁሉ የድሮውን አገልጋይ መጠቀማቸውን ይቀጥላሉ።

የድሮውን አገልጋይ መቼ ማጥፋት እችላለሁ?

የድሮው TTL ካለቀ በኋላ ቢያንስ ለአንድ ቀን መዝገቦቹ እውነተኛ ትራፊክ ካላሳዩ። አንዳንድ resolvers እና ደንበኞች TTLን ችላ ይላሉ፣ ስለዚህ ከቻሉ የድሮውን አገልጋይ ሳይቀይሩ ለጥቂት ተጨማሪ ቀናት እንዲሠራ ይተዉት።

ከማዛወር በኋላ በብዛት የሚበላሸው ምንድን ነው?

የተረሱ በመርሐ ግብር የሚሠሩ ሥራዎች፣ በውቅረቶች እና በአጋሮች allowlist ውስጥ በቀጥታ የተጻፉ የIP አድራሻዎች፣ ከቅጂ በኋላ የፋይል ባለቤትነት፣ የፋየርዎል ደንቦች፣ እና ኢሜይል፦ አሁንም ወደ ድሮው አድራሻ የሚያመለክቱ reverse DNS እና የSPF መዝገቦች።

VPSን ያለ መቋረጥ ማዛወር፦ ማረጋገጫ ዝርዝር

ስለ ማዛወር የሚነገር እያንዳንዱ አስፈሪ ታሪክ ተመሳሳይ መሃል አለው፦ አንድ ሰው መጀመሪያ DNSን ቀይሮ ከዚያ መቅዳት ጀመረ። በማዛወር ወቅት የሚፈጠር መቋረጥ መቅዳቱ ቀርፋፋ በመሆኑ ብዙም አይፈጠርም። የሚፈጠረው እርምጃዎቹ በተሳሳተ ቅደም ተከተል ሲወሰዱ ነው።

ከሌላ አቅራቢ እየለቀቁም ይሁን በሁለቱ ዕቅዶቻችን መካከል እየተሸጋገሩ፣ የሚሠራው ቅደም ተከተል ይህ ነው።

1. ከሁለት ቀን በፊት፦ TTLን ይቀንሱ

የሚቀይሯቸውን የDNS መዝገቦች ያግኙ (ብዙውን ጊዜ A፣ AAAA እና ወደ እነሱ የሚያመለክቱ CNAMEዎች) እና TTLቸውን ወደ 300 ሴኮንድ ይቀንሱ። ከዚያ ቢያንስ የድሮውን TTL ያህል ይጠብቁ። የአንድ ቀን TTL ያለው መዝገብ ማለት አንዳንድ resolvers ከለውጡ በኋላ ለአንድ ቀን የድሮውን አድራሻ መስጠታቸውን ይቀጥላሉ ማለት ነው፣ በአገልጋዩ ላይ የሚያደርጉት ምንም ነገር ይህን አያፋጥነውም።

ሰዎች የሚዘሉት እርምጃ ይህ ነው፣ የአምስት ደቂቃ ለውጥን ግማሹ ተጠቃሚ የድሮውን አገልጋይ የሚያይበት ቀን የሚያደርገውም እሱ ነው።

2. የድሮውን አገልጋይ ዝርዝር ያዘጋጁ

ይህን ማሽን በሌላ ቦታ እንደገና ሊገነቡት ነው፣ ስለዚህ በእውነት የሚሠራውን ይጻፉ። የሚያስታውሱትን ሳይሆን። የሚሠራውን፦

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

በዝርዝሩ ላይ ይጨምሩ፦ የTLS ሰርተፊኬቶችንና እንዴት እንደሚታደሱ፣ ሚስጥር የያዙ የአካባቢ ፋይሎችን፣ የፋየርዎል ደንቦችን፣ ተጠቃሚዎችንና የSSH ቁልፎቻቸውን፣ የውሂብ ጎታውንና መጠኑን፣ እና አገልጋዩን በIP አድራሻ የሚያነጋግር ማንኛውንም ነገር። የመጨረሻው ቡድን ተንኮለኛው ነው፦ የአጋር allowlist፣ የክፍያ አቅራቢ የwebhook ቅንብሮች፣ የክትትል ፍተሻ።

3. አዲሱን አገልጋይ ከአሮጌው ጎን ያቁሙ

አዲሱን አገልጋይ ያዝዙ፣ አሮጌውን አይንኩ። ከየVPS ዝርዝር የተሸጠልዎትን ሳይሆን በእውነት የሚጠቀሙትን ያህል ወይም የበለጠ ዲስክ ያለው ዕቅድ ይምረጡ። አሮጌው ማሽን ማንኛውንም ገቢ ትራፊክ (ድረ-ገጽ፣ webhooks፣ API) የሚቀበል ከሆነ፣ አዲሱ የራሱ IPv4 ያስፈልገዋል። የNAT ዕቅድ ገቢ ግንኙነቶችን የሚቀበለው በSSH portው ብቻ ነው፣ ይህ ለምን አስፈላጊ እንደሆነም አንድ የተዘዋወረ port ምን ማድረግ ይችላል፣ ምን አይችልም ያብራራል።

ይገናኙ፣ ተመሳሳይ ጥቅሎችን ይጫኑ፣ ተጠቃሚዎችንና ፋየርዎሉን እንደገና ይፍጠሩ። ቁልፎችና የመጀመሪያ መግቢያ በየግንኙነት መመሪያው ውስጥ ተገልጸዋል።

4. ፋይሎቹን ሁለት ጊዜ ያመሳስሉ

የመጀመሪያው ማመሳሰል የድሮው አገልጋይ መሥራቱን ሲቀጥል ሁሉንም ነገር ይቀዳል። ሰዓታት ሊወስድ ይችላል፤ ችግር የለውም።

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids የፋይል ባለቤትነትን በቁጥር ይጠብቃል፣ ይህም ሁለቱ ሥርዓቶች ተጠቃሚዎችን በተለያየ ቅደም ተከተል ሲፈጥሩ የሚያጋጥመውን የተለመደ «ሁሉም ነገር የተሳሳተ ተጠቃሚ ነው» አስገራሚ ነገር ያስቀራል። rsyncን በSSH በኩል ተጠቅመው የማያውቁ ከሆነ፣ ፋይሎችን ወደ VPS እንዴት ማስተላለፍ በደረጃ ያሳያል።

ሁለተኛው ማመሳሰል፣ ከመቀየሩ ልክ በፊት፣ ከመጀመሪያው በኋላ የተቀየረውን ብቻ ይቀዳል። ብዙውን ጊዜ ሴኮንዶች ብቻ ይወስዳል።

5. የውሂብ ጎታውን በጥንቃቄ ያዛውሩ

ፋይሎች ቀላል ናቸው። ጽሑፍ የሚቀበል የውሂብ ጎታ «ያለ መቋረጥ» ትንሽ ስምምነት ወይም ተጨማሪ ሥራ የሚጠይቅበት ብቸኛው ክፍል ነው።

ቀላሉ መንገድ፦ ለሙከራ አንድ ጊዜ dump አድርገው ይመልሱ፣ በመቀየሪያው ጊዜ ደግሞ ጽሑፍን ለአንድ ደቂቃ ያቁሙ (መተግበሪያውን በማንበብ-ብቻ ሁነታ ያድርጉ ወይም ያቁሙት)፣ አዲስ dump ይውሰዱ፣ በአዲሱ አገልጋይ ላይ ይመልሱት፣ መተግበሪያውንም እዚያ ያስጀምሩ። ለአብዛኞቹ ትናንሽ ፕሮጀክቶች ይህ አስቀድሞ የሚነገር የአንድ ወይም የሁለት ደቂቃ ማቆም ነው።

ያለ ማቆም መንገድ፦ ከድሮው የውሂብ ጎታ ወደ አዲሱ replication ያዘጋጁ፣ እንዲደርስ ይተዉት፣ በመቀየሪያው ጊዜም አዲሱን ዋና ያድርጉት። ተጨማሪ ዝግጅት አለው፣ የአንድ ደቂቃ የጠፋ ጽሑፍ እንኳ ተቀባይነት በሌለው ጊዜ ዋጋ አለው።

6. ሌላ ሰው ከማየቱ በፊት አዲሱን አገልጋይ ይፈትሹ

DNS አሁንም ወደ ድሮው አገልጋይ ያመለክታል፣ ስለዚህ አዲሱን በግል መፈተሽ ይችላሉ። ለእውነተኛ ዶሜይንዎ ጥያቄን ወደ አዲሱ አድራሻ ይላኩ፦

curl --resolve example.com:443:203.0.113.10 https://example.com/health

ሰርተፊኬቱ ገና ከሌለ፣ በተመሳሳይ መንገድ በHTTP ይፈትሹ፣ ወይም በhosts ፋይልዎ ጊዜያዊ መስመር ያክሉና ድረ-ገጹን በአሳሽ ያስሱ። መግቢያን፣ ፋይል መጫንን፣ የጀርባ ሥራዎችን እና የሚወጣ ኢሜይልን ያረጋግጡ። የጎደለ የPHP ቅጥያን ለማግኘት በጣም ርካሹ ጊዜ ይህ ነው።

7. ይቀይሩ፣ የድሮውን አገልጋይም እንደበራ ይተዉት

የመጨረሻውን የፋይል ማመሳሰልና የውሂብ ጎታውን እርምጃ ያከናውኑ፣ ከዚያ የDNS መዝገቦቹን ይቀይሩ። በ300 ሴኮንድ TTL አብዛኛው ትራፊክ በደቂቃዎች ውስጥ ይሸጋገራል። የድሮውን አገልጋይ የመዳረሻ መዝገብ ይከታተሉ፦ TTLን ችላ ከሚሉ resolvers እና ደንበኞች አሁንም ጥቂት ጥያቄዎች ይመጣሉ። ሳይቀይሩት ለጥቂት ቀናት እንዲሠራ ይተዉት። ከዚያ ወደ ድሮው IP የሚያመለክተውን ሁሉ ያዘምኑ፦ የአጋሮች allowlist፣ የwebhook URLዎች፣ ለኢሜይል ደግሞ የአዲሱን አድራሻ reverse DNS (በተወሰነ IP ዕቅዶቻችን ላይ ራስዎ ያዘጋጁታል፣ reverse DNS ይመልከቱ) እና የSPF መዝገብዎን።

በብዛት የሚበላሹ ነገሮች

በምናየው ድግግሞሽ ቅደም ተከተል በግምት፦ ማንም ያልዘረዘረው የsystemd timer፣ የድሮው IP በቀጥታ የተጻፈበት የውቅረት ፋይል፣ የተሳሳተ ተጠቃሚ ንብረት የሆኑ ፋይሎች፣ የመተግበሪያውን የራሱን port የሚዘጋ ፋየርዎል፣ በድሮው አገልጋይ ላይ የሚታደስ በአዲሱ ላይ ግን የማይታደስ ሰርተፊኬት፣ እና አዲሱ አድራሻ ገና reverse DNS ስለሌለው ወደ spam የሚገባ ኢሜይል።

ይህ ማረጋገጫ ዝርዝር የማይስማማበት

ያለማቋረጥ የሚጻፍበትና ማቆምን ፈጽሞ የማይታገስ የተጨናነቀ የውሂብ ጎታ የብሎግ ማረጋገጫ ዝርዝር ሳይሆን እውነተኛ replication እና ልምምድ ያስፈልገዋል። የWindows አገልጋዮች የሚዛወሩት ከrsync በተለዩ መሣሪያዎች ነው። ማዛወሩ በእርግጥ ስለ መጠን ከሆነ ደግሞ፣ ይህን መጀመሪያ ያንብቡ፦ እዚህ ዕቅዶች በቦታው ያድጋሉ። ተመሳሳይ የአውታረ መረብ ዓይነት ወዳለው ትልቅ ዕቅድ መሸጋገር ምንም ማዛወር ሳያስፈልግ በአንድ ዳግም መነሣት vCPU፣ RAM እና ዲስክ ይጨምራል። አዲስ አገልጋይ የሚያስፈልገው ለማሳነስ ብቻ ነው። ማሽኑ በቂ መሆኑን እርግጠኛ ስላልሆኑ እየተዛወሩ ከሆነ፣ 64 GB RAM በእውነት የሚያስፈልግዎት መቼ ነው ጉዞውን ሊያስቀርልዎት ይችላል፣ VPS ትክክለኛው ቤት መሆኑን እርግጠኛ ካልሆኑ ደግሞ VPS፣ የጋራ hosting፣ የተወሰነ አገልጋይ ወይስ ክላውድ ይረዳዎታል።

VPSዎን ያለ መቋረጥ ወደ አዲስ አቅራቢ ማዛወር