Webserver és DNS költöztetés két új névszerver esetén

Web, mail, IRC, IM, hálózatok

Sziasztok,

Abban szeretnék segítséget kérni hogy lenne egy webszerver költöztetés amit nem lehet egyszerre megoldani (200+ tárhely, plusz vannak akiknek a régi szerveren kell futniuk egy ideig kompatibilitási problémák miatt), tehát új névszerverek is játszanának a történetben (már csak azért is mert egy-két domainnél problémás a névszerver csere) és a dolog bonyolultsága miatt nem tudom hogy jól terveztem-e, írom ez elképzelésem:

A szerverek ns rekordjai glue rekorddal vannak onlinenic-nél az alábbiak szerint:
Régi szerver:
ns1.regiszerver.hu 1.1.1.1
ns2.regiszerver.hu 2.2.2.2

Új szerver:
ns1.ujszerver.hu 3.3.3.3
ns2.ujszerver.hu 4.4.4.4

Az összes domain névszervere:
ns1.regiszerver.hu
ns2.regiszerver.hu

  1. Akik mennek az új szerverre azoknál pár nappal a költöztetés előtt levenném a DNS-ükben a ns1.regiszerver.hu és ns2.regiszerver.hu valamint az A rekordok TLL értékék (itt sokan azt mondják hogy nem érdemes 20-30 percnél kisebbre állítani mert hogy más szerverek nem veszik figyelembe)
  2. Megtörténik a fájlok átmásolása
  3. Itt lenne az a rész normál esetben hogy átírásra kerülnek a domain névszerverei, mivel ez néhánynál nem lehet, azoknál a RÉGI szerveren a domainhez tartozó ns1 (1.1.1.1 > 3.3.3.3) és ns2 (2.2.2.2 > 4.4.4.4) illetve A (1.1.1.1 > 3.3.3.3) rekordot átírom az új szerverére (kérdés hogy a Let's encrypt tanúsítványok kiborulnak-e ettől?)
  4. Amikor megvan minden tárhely átmásolása (1-2 hónap) akkor a ns1.regiszerver.hu és ns2.regiszerver.hu IP-je átírásra kerül az új szerverére (3.3.3.3 és 4.4.4.4), és pár nap múlva lekapcsolásra kerül a régi szerver

Mi az amit rosszul gondolok?

Előre is köszönöm!

  • 292 megtekintés

( ggallo | 2024. 01. 30., k – 16:08 )

Szerkesztve: 2024. 01. 30., k – 16:11

Miért nem tartod meg a névszerverek nevét/tartományát? Akkor nem kellene a kezelt tartományokban semmit csinálnod, csak a régi névszerverek tartományában (és magukon a régi névszervereken) kellene a glue rekordot és az NS-ek A rekordját módosítani. Ezt meg egymás után is lehet (átrakod az NS2-t az új helyre, címre, rekord változtatás, majd ha átfutott és jól működik, akkor költözhet át az NS1 is ugyan így).

Az ügyfél tartományoknál nem elég a nálad üzemelő névszerveren módosítani a rekordokat NS név csere esetén, hanem a regisztrátornak is utána kell menni az NS rekordok cseréjével. Ezért érdemes a névszerver nevét megtartani.

Na persze ha muszáj szabadulni a névtől, akkor ez nem jó megoldás, de egy sima költöztetésnél a név maradhatna. Aztán persze lehet egyszerűbb lenne a régi néven költöztetni mindent az új helyre (a fenti bekezdésem alapján), aztán ha minden működik, akkor mellé tenni új néven új névszervereket, és elkezdeni egyesével átrakni a tartományokat (mert ahhoz ugye mindegyikhez a regisztrátorok, így az ügyfelek közreműködése is kelleni fog, sokáig fog tartani - főleg az ügyfelek érdektelensége miatt).

csak a régi névszerverek tartományában (és magukon a régi névszervereken) kellene a glue rekordot és az NS-ek A rekordját módosítani

Mondjuk erre nem is gondoltam (persze nem jó mert a régi névszervernek mindenképpen módosulni kell mivel az egy régi teszt nevű csak az előző kolléga úgy hagyta :S viszont egy másik problémám most oldottad meg egy másik szervernél, köszi :D )

 

Ezért érdemes a névszerver nevét megtartani.

Ezt így gondoltam ezért írnám csak át az IP cimeiket az újra az utolsó lépésnél amikor már a régi szerver lekapcsolásra kész

Ha a névszerveren nevet váltasz (ergo másik tartománybeli névszervereket használsz a jövőben; a felsorolásból nekem ez jön le), akkor az IP csere nem tudom hol és hogyan valósul meg, és miért szükséges/hasznos.

Az ügyfél tartományban annyi van most, hogy

@ IN NS ns1.regiszerver.hu.
@ IN NS ns1.regiszerver.hu.

Az ügyfél tartományban sehol sem szerepel ezen névszerverek IP címe, sőt, a regisztrátornál is csupán ennyi van, ott sem szerepel ezen névszerverek címe. Pont ez a DNS lényege, hogy egy authoratív helyről jöjjön a névhez tartozó cím, így könnyű legyen a név mögötti címet változtatni. Így ezen szerverek IP címének a frissítése kizárólag a regiszerver.hu tartományban történik meg. Ha ezt kidobod, akkor az össszes zóna ami ezeke hivatkozik, azonnal működésképtelen lesz.

Ha a regiszerver.hu tartomány megszűnik, mert helyette lesz az ujszerver.hu tartomány a benne lévő ns1 és ns2 kiszolgálókkal, akkor az ügyfél tartomány NS rekordjai nem létező NS-ekre mutatnak majd. A régi zónában a névszerverek IP cseréje után a TTL lejártával nem frissül a névszerverek _neve_ sehol, a regisztrátornál meg csak a regiszerver.hu tartományban tartozik IP cím az ns1.regiszerver.hu és ns2.regiszerver.hu kiszolgálókhoz (és persze ezen zónát kiszolgáló authoratív szervereken, de ugye azt tervezed átírni, a regisztrátornak meg szólni kell, Ő is írja át ugyan azt).

Viszont ha az ügyféltartományt úgy módosítod az új szerverre költözve, hogy abban a következő lesz:

@ IN NS ns1.ujszerver.hu.
@ IN NS ns2.ujszerver.hu.

Akkor nem lesz jó, mert az NS rekordok nem fognak egyezni a regisztrátor által bejegyzett NS rekordokkal, és a sima rekurzív névfeloldás a regisztrátor által bejegyzett rekordok szerint "kezdődik" (TLD szinten), majd ha az jó helyre mutat, akkor az ott jelzett authoratív szerveren folytatódik. Namost a regisztrátornál az ns1.regiszerver.hu és ns2.regiszerver.hu nevek szerepelnek az NS rekordokban továbbra is, amik így nem létező tartomány nem létező gépére fognak mutatni. Ezt csak a regisztrátor tudja változtatni, erre írtam, hogy ehhez meg kell az ügyfél közreműködése minden egyes ügyfél tartománynál, amin általában megakad a dolog.

Ezért írtam, hogy praktikus megtartani a jelenlegi névszerverek tartományát és nevét. A költözés lezongorázása után pedig nagy levegő, elszánás, stb. után el lehet kezdeni párhuzamosan felépíteni az új tartományt az új névszerverekkel, és átköltöztetni a zónákat egyesével, lezongorázva a szükséges változtatásokat tartományonként a regisztrátornál.

Bocsánat, én ennél: "IP cimeiket az újra", a glue record "A" recordjára értettem, mert persze ha a névszervereket csesztetném az elég kontraproduktív lenne ahogy fent részletezted.

Szóval hogy ne legyek félreérthető a régi névszervereknek maradniuk kell, csak az A rekordjuk módosulnának az újra (1.1.1.1 > 3.3.3.3 és 2.2.2.2 > 4.4.4.4) ez is csak a legvégén amikor már minden átment és lekapcsolható a régi szerver, na és ezután jönne az a rész amit írtál hogy átírni a névszervereket a regisztrátoroknál.

Az úgy teljesen jó. Ha marad az ns1.regiszerver.hu és ns2.regiszerver.hu név, akkor csak a regiszerver.hu zónában és a regisztrátornál a glue record-ban kell IP címet cserélni.

Erre javasoltam azt, hogy menjen egyszerre a két helyen mindkét ns szerver (a régi és az új címeken egyaránt), és elsőre az egyiknek kell a címét lecserélni mindenhol (régi és új szerverek mindegyikén, regisztrátor glue record), majd ha az átfutott mindenhol (akár egy hét az alábbiak alapján), utána a másiknak az IP változását átvezetni ugyan így. Ha mindkettő mindenhol az új NS címekre mutat, akkor már bátran lekapcsolhatod a régi helyen a két NS szervert.

( Zs | 2024. 01. 30., k – 16:09 )

Szerintem a cím megtévesztő: igazából nem azzal van a gondod, hogy a webszervert akarod költöztetni, hanem azzal, hogy a webszerverhez regisztrált minden egyes domain-t saját DNS-sel szolgáltatsz, ha jól sejtem, arról a gépről, amelyik a webszervert is adja és így nem elég a weboldalakat átvinni, hanem a DNS szolgáltatást is át kell vinni mindenenestől.

Egyfelől meggondolnám, hogy regisztráljak egy domain-t csak a DNS-nek valami általános néven, majd az összes többi zona névszerverének ezt adnám meg - így az előbbi problémát viszonylag könnyen lehetne orvosolni. (A DNS migrálást nem úsznád meg - de egy NS migrálása elég lenne...)

Másfelől a két feladatot egymástól függetlenül oldanám meg: attól, hogy az adott domaint már az új gépen futó webszrever szolgálja ki, attól még a DNS-e futhat a régin. Ennek megfelelően én a következő lépésekre bontanám a dolgot:

  • weboldal migráció
    • CNAME/A rekord TTL lecsökkent a minimumra (1-5 perc), legalább az eredeti TTL szerinti érvényességi idővel korábban (hogy legyen ideje a magas TTL-nek kifutni)
    • régi szerver leáll
    • A rekord módosul az új IP-re
    • web tartalom átmigrálása
    • új gépen webszerver indul, viszi a szolgáltatást
  • DNS migráció
    • az NS-hez tartozó A rekord TTL-t hasonló módon lecsökkenteném,
    • új DNS kialakít az új helyen
    • zóna átemel,
    • új helyen az NS-hez tartozó A rekord IP címe lejavít
    • regisztrátorral a módosítást leboxolja
    • átregisztrálás után régi gépen az átvitt zona szolgáltatása leáll

Megjegyzések:

  • a sorrend nem feltétlenül ez
  • a webszerver leáll sem feltétlenül jelenti azt, hogy az összes weboldal szolgáltatása leáll, inkább hogy konfig módosul, hogy a migrálódó oldalt nem szolgáltatja, restart a konfig érvényre juttatásához és annyi
  • a secondary DNS konfigba is bele kell nyúlin, hogy honnan húzza az eredeti zónát

Szerintem a cím megtévesztő

Igen, most hogy így felhívtad a figyelmem szépítettem rajta :)

Egyfelől...

De ez nem ugyanaz mint amit írtam hogy lenne a ns1.ujszerver.hu (3.3.3.3) és ns2.ujszerver.hu (4.4.4.4), lényegében ha átállítom a régieket (1.1.1.1 > 3.3.3.3 és 2.2.2.2 > 4.4.4.4) nem ugyanez az eredmény lesz?

Másfelől...

1-5 perc az okés? Az urbán legenda hogy vannak olyan szerverek amik nem veszik figyelembe az ilyen kis idővel rendelkező TTL-eket?

(na itt lett volna még egy csomó kérdésem erre látom hogy a megjegyzésekben pont ezeket teszed helyre :D )

De ez nem ugyanaz mint amit írtam hogy lenne a ns1.ujszerver.hu (3.3.3.3) és ns2.ujszerver.hu (4.4.4.4), lényegében ha átállítom a régieket (1.1.1.1 > 3.3.3.3 és 2.2.2.2 > 4.4.4.4) nem ugyanez az eredmény lesz?

Nem, mert a DNS-ben a névszerverekre _névvel_ hivatkozunk mindenhol, és ehhez a névhez csak az authoratív zónában (saját honos zónája) van IP cím rendelve.

1-5 perc az okés? Az urbán legenda hogy vannak olyan szerverek amik nem veszik figyelembe az ilyen kis idővel rendelkező TTL-eket?

Szolgáltatói névszerverek (amiket az előfizetők túlnyomó része használ...) van, hogy napos vagy hetes min-cache-TTL értékkel üzemelnek... Volt pont itt másik topicban, hogy a Digi névszerverein egy hét alatt futott át a 300 másodperces TTL-ű rekord módosítása...

Első kanyarban azt lenne célszerű pontosítani, hogy az ns1.ujszerver.hu és az ns1.regiszerver.hu valójában mindkét esetben ns1.endomainem1.hu, ns1.endomainem2.hu, ...
Tehát a névvel csak arra akarsz utalni, hogy másik DNS szerver, de egyébként ugyanazt a zónát szolgáltatja, ha jól gondolom. Nyilván ha ez az eset áll fenn és a zónát jól migráltad, akkor tök mindegy, hogy még a régi DNS oldja fel a nevet ugyanarra az IP-re, amelyikre az új feloldaná. Ezért mondtam, hogy a webszerver és a DNS szolgáltatás migrálása külön választható.

Hogy ki mennyit állít be default TTL-nek és igazából mi mikor fog frissülni, az egy külön tészta. Vegyük a következő teoretikus esetet. Legyen a vala.mi.csoda.org A rekordja a 127.0.0.1 és a TTL legyen egy óra. Át akarunk állni egy valós IP-re, mondjuk az 1.2.3.4-re. Kérdés: mikor lesz biztosan az új cím a kliensnél? Tegyük fel, hogy a DNS-ek figyelembe veszik a rekordhoz tartozó TTL értéket. Nos a gubanc ott van, hogy a szolgáltató hajlamos DNS cache-t használni. Tehát amikor DNS1 lekérdezi az authoritative névszervertől a rekordot, akkor azt egy órán át még nyugodtan szolgáltathatja. Ha 5 perccel később módosul az A rekord, akkor DNS1 még 55 percig a régi IP címet szolgáltatja. Ne legyen szerencséd, a céges hálóban is van DNS és az is cachel. A változás után 50 perccel ez - szerencsétlen módon - a DNS1-től kéri le a vala,mi,csoda.org IP-jét, ahol viszont a TTL még nem telt le. Kérdés: a DNS2 meddig fogja szolgáltatni a régi IP címet? Gyakorlatilag addig, amíg nála le nem jár. Ez persze kivédhető, ha a DNS1 módosítja a TTL értéket az eltelt idővel, azaz 5 percet mond rá, mert addig érvényes már csak nála - de ezt sajnos nem tudom, hogy így van-e... Ha nincs így, akkor minden egyes útban lévő cacheing DNS tovább nyújtja a változás észlelési időt, ha így van, akkro is a minimum a TTL duplája, amivel számolni kell.
Ugyanakkor egy dyndns szolgáltató is alacsony TTL értékkel dolgozik - pont azért, mert a rekord bármikor változhat és jó eséllyel változik is. De előre nem tudható, hogy mikor.
A probléma tehát az, hogy az összes DNS TTL lejárati idejét nem fogjuk tudni kivárni - ezzel a problémával sajnos együtt kell éli.

Igazából a probléma ugyan valós - de van orvosság is rá. Hasonló problémával korábban már futottam össze én is. A megoldás a következő volt:

  • A rekord átír
  • webtartalom átmigrál
  • a webtartalmat már az új webszerver szolgáltatja
  • a régi webszerver is szolgáltatja az oldalt, de a helyi kiszolgálás helyett proxy módban gurul, így a kérést tovább passzolja az oldalt ténylegesen kiszolgáló webszervernek, a választ meg visszaadja, mintha ő szolgáltatná az adatokat.
    • Ha az alkalmazás igényli, akkor ilyen esetekben hasznos lehet a headert bővíteni proxyed for és hasonló extra sorokkal..

Igazából viszont az eredeti kérdésem is nyitva van: miért generálsz minden domainhez önálló DNS-t és DNS szerver bejegyzést? Egy DNS több zónát is szolgáltathat.
Példa:

  • a komplett othello.eu oldalt az ns[1|2].desdemona.org szolgálja ki,
  • aki böngészget , az mindig az othello.eu-t fogaj emlegetni,
  • az, hogy a háttérben a névfeloldás kapcsán mi történik, azt nem fogja látni, tehát előtte rejtve maradnak az alábbi kérdések:
    • rootDNS-ektől: kik szolgáltatják a hu TLD-t?
    • az előbbi lista valamely DNS-től azt firtatjáu, hogy ki illetékes az othello.eu zóna tekintetében
    • a válasz az hogy az ns1.desdemona.org és ns2.desdemona.org
    • most valamely desdemona-s NS kapja meg a kérdést, hogy mit tud mondani az othello.eu illetve www.othello.eu kapcsán: A rekord, AAAA rekord, CNAME, valami...
    • ebben a listában az egyszerűség kedvéért nem szerepel az, hogy minden egyes NS lekérdezés után megy egy A rekord lekérdezés is, hogy meglegyen az NS A rekordja. Itt az A rekord a "szülőDNS-be" felvett glue rekord lesz!
  • de ez mind-mind a háttérben történik, tehát a kliens előtt ülő nagyon nem fogja látni, hogy a végén melyik DNS is oldotta fel az általa kért nevet.

Tehát ha közös a DNS, akkor így valójában csak egyetlen DNS szervert kell elmigrálnod és a többi megy vele. (Illetve ha te adod valahol máshol a másodlagosat és azt is arrább tolod, akkor azt is. De az élvezetek fokozhatóak: egy zónát minimum 2 DNS-sel kell szolgáltatni, de maximum nem adott, lehet több másodlagos DNS-ed is. :-D)