Készítse elő a szervert és a tanúsítványt a szándékolt hosztnévhez, tesztelje az alkalmazást a nyilvános DNS módosítása előtt, és tartsa elérhetően a régi környezetet az átmenet során. Függetlenül ellenőrizze a hiteles rekordokat, a gyorsítótárazott válaszokat és a TLS-t. Egyedül egy DNS frissítés nem bizonyítja, hogy a helyes alkalmazás és tanúsítvány kerül kiszolgálásra.
Készítsen leltárt a nevekről és a függőségekről
Sorolja fel az oldal által használt összes hosztnevet, beleértve a fő domaint, az aliasokat, a API végpontokat és az alkalmazás-visszahívásokat. Rögzítse, ki irányítja a regisztrációt és a hiteles DNS-t. Egy alkalmazás üzemeltetése nem regisztrálja automatikusan annak domainjét, és nem adja a szerver üzemeltetőjének ellenőrzését a rekordjai felett. Tartsa meg a hozzáférést a meglévő környezethez, amíg az újat érvényesítették.
Azonosítsa azokat az e-mail- és harmadik féltől származó ellenőrzési rekordokat is, amelyeket a költözésnek meg kell őriznie. Egy webhely-migrációnak nem szabad könnyedén lecserélnie egy teljes DNS zónát. Készítsen rekordszintű változtatási tervet a szándékolt címekkel és egy visszaállítási értékkel. A hitelesítő adatokat privát módon tárolja; az útmutatónak tulajdonosokra és eljárásokra van szüksége, nem tényleges jelszavakra vagy API tokenekre.
Készítse elő a hosztnév-útválasztást az új szerveren
A kapcsolatot fogadó gépnek a hosztnevéhez tartozó szándékolt alkalmazást kell kiszolgálnia. Ennek megfelelően konfigurálja a webszervert vagy a tárhelykezelő panelt, a nyilvános dokumentumgyökeret elkülönítve a privát konfigurációtól és hitelesítő adatoktól. Tesztelje az összes szükséges nevet és átirányítást, ne csak a szerver címén elérhető általános üdvözlőoldalt.
Használjon ellenőrzött tesztmódszert, amely a nyilvános változás előtt a szándékolt hosztnevet küldi az új végpontra. Adott esetben ellenőrizze a bejelentkezést, a feltöltéseket és az alkalmazás által generált hivatkozásokat. A tesztelés során tiltsa le azokat a feladatokat, amelyek megkettőzhetnék az éles műveleteket. A tesztnek bizonyítania kell az alkalmazás viselkedését anélkül, hogy valódi levelet küldene, fizetéseket venne fel vagy akaratlanul módosítaná a régi éles adatbázist.
Válasszon tanúsítvány-érvényesítési módszert
A tanúsítvány kiállítása a kért nevek feletti ellenőrzés bizonyítását igényli. A Let's Encrypt az érvényesítési módszerei között dokumentálja a HTTP-01 és a DNS-01 módszert. A HTTP érvényesítés a szükséges kihívás helyes kiszolgálásától függ; a DNS érvényesítés egy meghatározott DNS rekordot használ, és támogathatja a wildcard kiállítást. Válasszon olyan módszert, amely illik a tényleges telepítéshez, és biztonságosan karbantartható.
Ahol lehetséges, tartsa szűken körülhatárolva az érvényesítési hitelesítő adatokat. A DNS automatizálás különösen érzékeny, mert a széles hatókörű DNS hitelesítő adatok egynél több webhelyet érinthetnek. Tervezze meg a tanúsítvány megújítását, és azt, hogyan jutnak el a megújított fájlok a kiszolgálási folyamathoz. Az első sikeres kiállítás hasznos, de egy oldalnak működő megújítási folyamatra és a ténylegesen bemutatott tanúsítványának megfigyelésére is szüksége van.
Tervezze meg a gyorsítótár-ablakot a DNS módosítása előtt
A DNS rekordok time-to-live értéket hordoznak, amelyet a feloldók a válaszok gyorsítótárazásakor használnak. Egy rekordváltozás nem helyettesíti azonnal az összes gyorsítótárazott eredményt. Ha az átmenetnek rövidebb TTL kedvez, tervezze meg a módosítást elég korán ahhoz, hogy a korábban gyorsítótárazott válaszok lejárhassanak. Tartsa mind a régi, mind az új környezetet képesnek az Ön által tervezett átmenet kezelésére.
Ez a szemléltető sorrend elválasztja az előkészítést a nyilvános átállástól. Az időzítését a domainhez, a feloldók viselkedéséhez és az alkalmazáshoz kell igazítani. Ez nem egy univerzális propagációs ütemterv. Az élő írásokat tartalmazó migrációhoz alkalmazásspecifikus adatátállás is szükséges, mert különben két működő webszerver különböző adatkészletekbe fogadhatja a változásokat.
| Szakasz | Művelet | Feltétel a folytatás előtt |
|---|---|---|
| Előkészítés | Leltározza a rekordokat és konfigurálja az új végpontot | Az alkalmazás működik a szándékolt nevekhez |
| Tanúsítvány | Állítsa ki és telepítse a tanúsítványt | A helyes lánc és hosztnév érvényesül |
| Átmenet | Csak a tervezett DNS rekordok frissítése | Az adatátállás és a visszaállítás meghatározva |
| Megfigyelés | Ellenőrizze a hiteles és a klienseredményeket | A felhasználói útvonalak sikeresek az új végponton keresztül |
| Befejezés | A régi szolgáltatás kivonása az érvényesítés után | A maradék forgalom és a helyreállítási igények áttekintése |
A DNS és a TLS külön ellenőrzése
Először ellenőrizze a hiteles rekordot, majd hasonlítsa össze az átmenetben érintett kliensek vagy feloldók válaszait. Egy helyes hiteles érték és egy régebbi gyorsítótárazott érték együtt létezhet. Vizsgálja meg a böngésző által elért végpontot, ahelyett hogy feltételezné, hogy minden kapcsolat már az új címet használja. A megfigyeléseket lássa el időbélyeggel, hogy az átmenet érthető legyen.
A TLS esetében egy tényleges klienskapcsolaton keresztül érvényesítse a szándékolt hosztnevet, a tanúsítvány érvényességét és a láncot. Vizsgálja meg az összes szükséges aliast és átirányítási útvonalat. A Mozilla TLS dokumentációja elmagyarázza a szerverhitelesítést és a vegyes tartalommal kapcsolatos aggályokat: az oldalt és annak alerőforrásait biztonságosan kell kiszolgálni. Az egyik hosztnéven lévő tanúsítvány nem fedi automatikusan a másik alkalmazásvégpontot.
A visszaállítás is legyen adatdöntés
Egy DNS visszaállítás átirányíthatja a forgalmat, de nem fordítja vissza az új alkalmazáson tett írásokat. Az átállás előtt határozza meg, hogyan kezeli ezeket az adatokat. Egy statikus kiadvány esetében a visszaállítás egyszerű lehet; a feltöltéseket vagy megrendeléseket fogadó szolgáltatás esetében az alkalmazás állapotának világos felelőst és egyeztetési eljárást kell kapnia.
Képzelje el egy kis, megjegyzésekkel rendelkező kiadói oldal migrációját. Előkészíthet egy karbantartási időszakot vagy egy ellenőrzött, csak olvasható átmenetet, amíg a végső adatokat átmásolják. Tesztelje az újranyitási eljárást, és tartsa készen a régi telepítést. Válassza az alkalmazáshoz illő megközelítést, ahelyett hogy egy DNS módosítást a konzisztencia-tervezés helyettesítőjeként használna.
Figyelje meg az oldalt a váltás után
Miután az új végpont forgalmat kap, ellenőrizze a valós felhasználói útvonalakat, a hibaarányokat, a tanúsítvány bemutatását és a háttérfeladatokat. Erősítse meg, hogy a biztonsági mentések most a szándékolt alkalmazást és adatokat fedik le. A kivonás előtt tekintse át a régi szerver hozzáférését, és távolítsa el az elavult hitelesítő adatokat, amint a helyreállítási és visszaállítási igények rendeződtek. Rögzítse a végső DNS és tanúsítványkonfigurációt.
Amikor SwissOctet webes tárhelyet vagy számítási kapacitást választ, erősítse meg a konfiguráció tényleges domain-, tanúsítvány- és adminisztrációs felelősségeit. A katalógus tárhelycélállomást és erőforrásokat biztosít; nem bizonyítja, hogy a domainje már csatlakoztatva van, vagy hogy a tanúsítvány megújítása be van állítva. Tartsa ezeket a lépéseket konkrétan és ellenőrizhetően a telepítési tervben.
Az Ön gyakorlati ellenőrzőlistája.
- Leltározza az összes hosztnevet, és őrizze meg a nem kapcsolódó DNS rekordokat.
- A nyilvános átállás előtt tesztelje a hosztnév-útválasztást.
- Válasszon és automatizáljon megfelelő tanúsítvány-kihívást.
- Tervezze meg a TTL-változásokat és az adatátmenetet.
- A DNS és a TLS külön ellenőrzésekkel történő ellenőrzése.
- A visszaállítás előtt tartsa meg a visszaállítási hozzáférést, és oldja meg az új írásokat.
A fontos részletek.
Aktiválja a HTTPS-t egy A rekord megváltoztatása?+
Nem. A DNS kiválaszt egy végpontot; annak a végpontnak továbbra is szüksége van a helyes hosztnév-útválasztásra és egy érvényes, telepített tanúsítványra.
Visszaállíthatom csak a DNS rekordot, ha valami elromlik?+
A forgalom átirányítható, de az alkalmazásírásokat külön kell kezelni. A migráció előtt határozzon meg adat-visszaállítási vagy egyeztetési tervet.
Mindig szükséges a wildcard tanúsítvány?+
Nem. A tanúsítványneveket és az érvényesítést a tényleges hosztneveknek megfelelően válassza ki. A wildcardnak meghatározott lefedettségi és érvényesítési követelményei vannak; ez nem univerzális migrációs gyorsmegoldás.
Menjen a forráshoz.
Ezek a hivatkozások támogatják az útmutató műszaki fogalmait. Kövesse az aktuális dokumentációt, mielőtt éles rendszert módosítana.
- Let's Encrypt: Kihívástípusok letsencrypt.org
- IETF RFC 1034: DNS fogalmak és lehetőségek datatracker.ietf.org
- Mozilla MDN: Transport Layer Security developer.mozilla.org
Szerkesztői útmutatás: SwissOctet. A példák tájékoztató jellegűek. A szolgáltatási specifikációkat, az elérhető opciókat és a szerződéses feltételeket külön kell ellenőrizni.