# 새 서버를 위한 도메인, DNS 및 TLS 전환 런북 | SwissOctet 인사이트 https://swissoctet.com/ko/insights/dns-tls-cutover-runbook/ SwissOctet / 인사이트 / 웹 및 onion 웹 및 onion 응용 · 4분 소요 새 서버를 위한 도메인, DNS 및 TLS 전환 런북 호스트 이름 라우팅, 인증서 및 롤백을 함께 준비하여 마이그레이션이 사이트의 정체성이나 보안 연결을 깨뜨리지 않고 서버를 변경하도록 하십시오. SwissOctet 편집팀 작성 가이드 저장 링크 복사 이 페이지에서 01 이름과 종속성 인벤토리 작성 02 새 서버에서 호스트 이름 라우팅 준비 03 인증서 검증 방법 선택 04 DNS 변경 전 캐시 기간 계획 05 DNS 및 TLS을 별도로 확인 06 롤백도 데이터 결정으로 만들기 07 전환 후 사이트 관찰 실용 체크리스트 출처 및 추가 자료 라이브러리로 돌아가기 직접적인 답변 의도한 호스트 이름에 대해 서버와 인증서를 준비하고, 공개 DNS를 변경하기 전에 애플리케이션을 테스트하며, 전환 중에 기존 환경을 사용 가능하게 유지하십시오. 권위 있는 레코드, 캐시된 응답 및 TLS을 독립적으로 확인하십시오. DNS 업데이트만으로는 올바른 애플리케이션과 인증서가 제공되고 있음을 입증하지 못합니다. 01 이름과 종속성 인벤토리 작성 기본 도메인, 별칭, API 엔드포인트 및 애플리케이션 콜백을 포함하여 사이트가 사용하는 모든 호스트 이름을 나열하십시오. 등록 및 권위 있는 DNS을 누가 제어하는지 기록하십시오. 애플리케이션을 호스팅한다고 해서 해당 도메인이 자동으로 등록되거나 서버 운영자가 해당 레코드를 제어하게 되는 것은 아닙니다. 새 환경이 검증될 때까지 기존 환경에 대한 접근을 유지하십시오. 또한 이전 시 보존해야 하는 이메일 및 제3자 검증 레코드를 식별하십시오. 웹사이트 마이그레이션은 전체 DNS 영역을 무심코 교체해서는 안 됩니다. 의도한 주소와 롤백 값을 포함한 레코드 수준 변경 계획을 작성하십시오. 자격 증명은 비공개로 저장하십시오. 런북에는 실제 비밀번호나 API 토큰이 아니라 책임자와 절차가 필요합니다. 02 새 서버에서 호스트 이름 라우팅 준비 연결을 수신하는 머신은 해당 호스트 이름에 대해 의도한 애플리케이션을 제공해야 합니다. 웹 서버나 호스팅 패널을 그에 맞게 구성하고, 공개 문서 루트를 비공개 구성 및 자격 증명과 분리하십시오. 서버 주소를 통해 접근하는 일반 환영 페이지뿐만 아니라 필요한 모든 이름과 리디렉션을 테스트하십시오. 공개 변경 전에 의도한 호스트 이름을 새 엔드포인트로 보내는 통제된 테스트 방법을 사용하십시오. 해당되는 경우 로그인, 업로드 및 애플리케이션 생성 링크를 확인하십시오. 테스트 중 프로덕션 작업을 중복할 수 있는 작업은 비활성화하십시오. 테스트는 실제 메일을 보내거나 결제를 받거나 기존 라이브 데이터베이스를 의도치 않게 수정하지 않고 애플리케이션 동작을 입증해야 합니다. 03 인증서 검증 방법 선택 인증서 발급에는 요청된 이름에 대한 제어 증명이 필요합니다. Let's Encrypt는 검증 방법 중 HTTP-01 및 DNS-01를 문서화합니다. HTTP 검증은 필요한 챌린지를 올바르게 제공하는 데 의존하며, DNS 검증은 지정된 DNS 레코드를 사용하고 와일드카드 발급을 지원할 수 있습니다. 실제 배포에 맞고 안전하게 유지 관리할 수 있는 방법을 선택하십시오. 가능하면 검증 자격 증명의 범위를 좁게 유지하십시오. DNS 자동화는 광범위한 DNS 자격 증명이 하나 이상의 웹사이트에 영향을 미칠 수 있으므로 특히 민감합니다. 인증서 갱신과 갱신된 파일이 제공 프로세스에 도달하는 방법을 계획하십시오. 최초 발급 성공은 유용하지만, 사이트에는 작동하는 갱신 프로세스와 실제로 제공하는 인증서에 대한 모니터링도 필요합니다. 04 DNS 변경 전 캐시 기간 계획 DNS 레코드는 리졸버가 응답을 캐시할 때 사용하는 TTL을 가집니다. 레코드 변경이 모든 캐시된 결과를 즉시 대체하지는 않습니다. 전환에 더 짧은 TTL이 유리하다면, 이전에 캐시된 응답이 만료될 수 있도록 충분히 일찍 조정을 계획하십시오. 기존 환경과 새 환경 모두 설계한 전환을 처리할 수 있도록 유지하십시오. 이 예시적 순서는 준비와 공개 전환을 분리합니다. 그 시점은 도메인, 리졸버 동작 및 애플리케이션에 맞게 조정해야 합니다. 보편적인 전파 일정이 아닙니다. 라이브 쓰기를 포함하는 마이그레이션에는 애플리케이션별 데이터 전환도 필요합니다. 그렇지 않으면 두 개의 작동하는 웹 서버가 서로 다른 데이터 세트에 변경을 수락할 수 있습니다. 단계 작업 진행 전 조건 준비 레코드 인벤토리 작성 및 새 엔드포인트 구성 의도한 이름에 대해 애플리케이션 작동 인증서 인증서 발급 및 설치 올바른 체인 및 호스트 이름 검증 전환 계획된 DNS 레코드만 업데이트 데이터 전환 및 롤백 정의됨 관찰 권위 있는 결과 및 클라이언트 결과 확인 새 엔드포인트를 통한 사용자 여정 성공 완료 검증 후 기존 서비스 종료 잔여 트래픽 및 복구 필요성 검토됨 05 DNS 및 TLS을 별도로 확인 먼저 권위 있는 레코드를 확인한 다음, 전환에 관련된 클라이언트나 리졸버의 응답을 비교하십시오. 올바른 권위 값과 이전 캐시 값이 공존할 수 있습니다. 모든 연결이 이미 새 주소를 사용한다고 가정하지 말고 브라우저가 도달하는 엔드포인트를 검사하십시오. 전환을 이해할 수 있도록 관찰에 타임스탬프를 남기십시오. TLS의 경우 실제 클라이언트 연결을 통해 의도한 호스트 이름, 인증서 유효성 및 체인을 검증하십시오. 필요한 모든 별칭과 리디렉션 경로를 검사하십시오. Mozilla의 TLS 문서는 서버 인증 및 혼합 콘텐츠 문제를 설명합니다. 페이지와 하위 리소스는 안전하게 제공되어야 합니다. 하나의 호스트 이름에 있는 인증서가 다른 애플리케이션 엔드포인트를 자동으로 커버하지는 않습니다. 06 롤백도 데이터 결정으로 만들기 DNS 롤백은 트래픽을 리디렉션할 수 있지만, 새 애플리케이션에서 이루어진 쓰기를 되돌리지는 않습니다. 전환 전에 해당 데이터를 처리할 방법을 정의하십시오. 정적 게시물의 경우 롤백이 간단할 수 있지만, 업로드나 주문을 수락하는 서비스의 경우 애플리케이션 상태에 명확한 책임자와 조정 절차가 필요합니다. 댓글이 있는 소규모 게시 사이트를 마이그레이션한다고 가정해 보십시오. 최종 데이터가 복사되는 동안 유지보수 기간이나 통제된 읽기 전용 전환을 준비할 수 있습니다. 재개 절차를 테스트하고 기존 배포를 준비 상태로 유지하십시오. DNS 변경을 일관성 계획의 대체물로 사용하지 말고 애플리케이션에 맞는 접근 방식을 선택하십시오. 07 전환 후 사이트 관찰 새 엔드포인트가 트래픽을 받은 후 실제 사용자 여정, 오류율, 인증서 제공 및 백그라운드 작업을 확인하십시오. 백업이 이제 의도한 애플리케이션과 데이터를 커버하는지 확인하십시오. 종료 전에 이전 서버 접근을 검토하고 복구 및 롤백 요구 사항이 해결되면 사용하지 않는 자격 증명을 제거하십시오. 최종 DNS 및 인증서 구성을 기록하십시오. SwissOctet 웹 호스팅이나 컴퓨팅을 선택할 때 구성에 대한 실제 도메인, 인증서 및 관리 책임을 확인하십시오. 카탈로그는 호스팅 대상과 리소스를 제공하지만, 도메인이 이미 연결되었거나 인증서 갱신이 구성되었음을 입증하지는 않습니다. 배포 계획에서 해당 단계를 구체적이고 검증 가능하게 유지하십시오. 행동으로 옮기기 실용 체크리스트. ✓ 모든 호스트 이름을 인벤토리화하고 관련 없는 DNS 레코드를 보존하십시오. ✓ 공개 전환 전에 호스트 이름 라우팅을 테스트하십시오. ✓ 적합한 인증서 챌린지를 선택하고 자동화하십시오. ✓ TTL 변경 및 데이터 전환을 계획하십시오. ✓ 별도의 점검을 통해 DNS 및 TLS을 확인하십시오. ✓ 롤백 접근을 유지하고 되돌리기 전에 새 쓰기를 해결하십시오. 체크리스트 다운로드 자주 묻는 질문 중요한 세부 사항. A 레코드를 변경하면 HTTPS가 활성화됩니까? + 아니요. DNS는 엔드포인트를 선택하며, 해당 엔드포인트에는 여전히 올바른 호스트 이름 라우팅과 유효하게 설치된 인증서가 필요합니다. 문제가 발생하면 DNS 레코드만 되돌릴 수 있습니까? + 트래픽은 리디렉션될 수 있지만 애플리케이션 쓰기는 별도로 처리해야 합니다. 마이그레이션 전에 데이터 롤백 또는 조정 계획을 정의하십시오. 와일드카드 인증서가 항상 필요합니까? + 아니요. 실제 호스트 이름에 따라 인증서 이름과 검증을 선택하십시오. 와일드카드는 특정 커버리지와 검증 요구 사항이 있으며, 보편적인 마이그레이션 지름길이 아닙니다. 주요 참고 자료 출처로 이동하세요. 이 참고 자료는 이 가이드의 기술 개념을 뒷받침합니다. 프로덕션 시스템을 변경하기 전에 최신 문서를 확인하세요. Let's Encrypt: 챌린지 유형 letsencrypt.org IETF RFC 1034: DNS 개념 및 기능 datatracker.ietf.org Mozilla MDN: 전송 계층 보안 developer.mozilla.org SwissOctet의 편집 지침. 예시는 설명용입니다. 서비스 사양, 사용 가능한 옵션 및 계약 조건은 별도로 확인해야 합니다. 지식 연결 관련 인프라. Canvas Web 스위스 Vector VPS 스위스 Pulse NVMe 스위스 흐름 유지 다음 필드 노트. 모든 가이드 살펴보기 필드 노트 / 01 + 클라우드 및 VPS 기초 추측 없이 VPS를 선택하는 방법 애플리케이션 아이디어를 유용한 리소스 예산으로 바꾸고, CPU, 메모리, 스토리지 및 전송량을 함께 비교하세요. 4분 소요 가이드 읽기 필드 노트 / 02 + 웹 및 onion 기초 웹 호스팅 또는 VPS: 직접 소유할 작업을 선택하세요 VPS를 모든 웹사이트의 자동 다음 단계로 취급하지 말고 애플리케이션 요구 사항, 제어 및 유지 관리 책임을 비교하세요. 6분 읽기 가이드 읽기 필드 노트 / 03 + 웹 및 onion 응용 애플리케이션을 간과하지 않고 onion 서비스 게시 통제된 백엔드 노출, 신중한 콘텐츠 검토, 서비스 키 복구 및 명시적인 사용자 접근 모델을 갖춘 합법적인 onion 게시를 계획하십시오. 4분 소요 가이드 읽기