회사 도메인과 DNS는 웹사이트 주소뿐 아니라 업무메일과 여러 클라우드 서비스의 신뢰 기반입니다. 등록기관 계정이 탈취되거나 갱신이 누락되고 DNS 레코드가 잘못 바뀌면 정상 주소가 가짜 사이트로 연결되거나 메일이 끊길 수 있습니다. 회사 명의와 공용 연락처로 자산을 정리하고 등록기관 계정에 강한 다중인증과 전송 잠금을 적용하세요. DNS 변경은 요청·승인·적용·검증을 나눠 기록하고, 현재 레코드와 복구 연락처를 별도 보관하며 만료·전송·네임서버 변경 알림을 두 명 이상이 받게 해야 합니다.
도메인을 결제 항목이 아니라 핵심 정보자산으로 등록합니다
도메인은 홈페이지 주소에 그치지 않습니다. 업무메일의 수신 경로, 인증서 발급, 고객 로그인과 외부 클라우드 서비스 검증에도 연결됩니다. 등록이 만료되거나 권한이 다른 사람에게 넘어가면 웹사이트 중단뿐 아니라 메일 가로채기와 사칭으로 이어질 수 있으므로 서버와 같은 핵심 자산으로 관리해야 합니다.
먼저 회사가 사용하는 대표·서비스·단축 도메인을 목록으로 만들고 등록기관, 등록자 명의, 관리 계정, 네임서버, 만료일, 자동갱신과 결제수단, 내부 책임자를 기록하세요. 퇴사자 개인 이메일이나 개인 카드에 연결된 항목은 회사가 통제하는 공용 연락처와 결제수단으로 옮기고, 등록정보가 실제 담당자와 일치하는지 정기적으로 확인합니다.
- 대표·서비스·방어 등록 도메인과 등록기관을 한 목록으로 관리
- 등록자 명의·관리 계정·네임서버·만료일·책임자 기록
- 개인 이메일과 개인 결제를 회사 통제 연락처·결제로 전환
등록기관 계정은 일반 업무 계정보다 강하게 보호합니다
등록기관 계정에 접근한 공격자는 네임서버나 등록 연락처를 바꾸고 도메인을 다른 등록기관으로 옮길 수 있습니다. 관리 계정에는 다른 서비스와 겹치지 않는 긴 비밀번호와 피싱에 강한 다중인증을 적용하고, 복구 이메일과 전화번호도 조직이 계속 관리할 수 있는지 확인하세요. 일상 업무용 관리자 계정과 도메인 소유권 계정을 분리하면 한 계정의 침해가 바로 전체 통제권 상실로 번지는 위험을 줄일 수 있습니다.
ICANN의 도메인 탈취 보고서는 등록기관 잠금과 고유한 이전 인증정보, 이전 알림을 일관되게 사용하는 것이 일부 탈취를 막을 수 있다고 설명합니다. 제공되는 경우 전송 잠금과 중요 변경 추가 인증을 켜고, 이전 코드나 복구 코드는 비밀번호와 다른 승인된 보관소에 두세요.
- 등록기관 계정에 고유 비밀번호와 피싱 저항 다중인증 적용
- 전송 잠금과 중요 변경 추가 인증·알림 활성화
- 복구 연락처와 이전 코드는 별도 통제하고 정기 점검
DNS 변경은 요청자와 승인자를 나눠 검증합니다
A·AAAA·CNAME·MX·TXT 같은 DNS 레코드는 짧은 값 하나만 잘못 바뀌어도 사이트와 메일, 인증 절차에 영향을 줍니다. 누가 어떤 업무 목적과 대상 레코드, 이전 값과 새 값, 적용·복구 시점을 요청했는지 기록하고 다른 담당자가 서비스 소유자와 요청 내용을 확인한 뒤 승인하도록 하세요. 긴급 변경도 구두 지시만으로 처리하지 말고 확인 가능한 업무 채널에 최소 기록을 남깁니다.
적용 전에는 현재 영역 파일이나 레코드 목록을 내보내고 영향받는 서비스와 TTL을 확인하세요. 변경 뒤에는 등록기관 화면의 성공 표시만 믿지 말고 권한 DNS와 외부 조회에서 새 값이 응답되는지, 웹·메일·인증서가 정상인지 검증합니다. NIST SP 800-81r3는 DNS 데이터의 무결성과 인증, 가용성을 보호하고 DNSSEC 등 조직 환경에 맞는 통제를 적용하도록 안내합니다.
- 업무 목적·대상·이전값·새값·적용·복구 시점을 변경표에 기록
- 요청자와 승인자를 분리하고 서비스 책임자에게 독립 확인
- 변경 전 백업, 변경 후 외부 조회와 웹·메일·인증서 검증
만료와 무단 변경 신호를 두 명 이상이 받게 합니다
자동갱신을 켰더라도 카드 만료, 결제 실패, 연락처 오류로 갱신이 멈출 수 있습니다. 만료일을 자산 일정에 별도로 등록하고 90일·60일·30일 전에 담당자와 대체 담당자가 확인하세요. 등록기관과 DNS 제공자의 로그인, 비밀번호 재설정, 연락처·네임서버·잠금 해제·이전 요청 알림도 개인 한 명이 아니라 공용 보안 채널과 두 명 이상의 담당자에게 전달되게 합니다.
정기 점검에서는 등록기관 화면의 네임서버와 실제 권한 DNS, 핵심 레코드의 기준값을 대조하세요. 예상하지 못한 레코드, TTL 급변, 낯선 관리자 로그인이나 인증서 발급을 발견하면 단순 오타로 단정하지 말고 변경 기록과 승인자를 확인하고 관련 로그를 보존합니다.
- 자동갱신 상태·결제수단·만료일을 복수 담당자가 사전 확인
- 로그인·재설정·잠금 해제·이전·네임서버 변경 알림 공유
- 핵심 DNS 기준값과 실제 응답, 인증서 발급 내역 정기 대조
통제권 상실을 가정한 복구 절차를 미리 연습합니다
도메인이 무단 이전되거나 등록정보가 바뀌었다면 현재 등록기관과 이전 등록기관의 긴급 지원 채널에 즉시 연락해야 합니다. ICANN도 승인하지 않은 이전이나 등록정보 변경이 확인되면 등록기관에 바로 조사를 요청하라고 안내합니다. 계약번호, 결제 증빙, 회사 등록정보와 과거 DNS 값을 평소에 준비하면 소유권 확인과 복구 요청 시간을 줄일 수 있습니다.
사고 중에는 정상 DNS와 메일을 복구하는 동시에 등록기관·DNS·이메일 관리자 계정의 인증정보와 세션을 교체하고 영향 범위를 확인하세요. 고객에게 안내할 대체 채널, 등록기관 긴급 연락처, DNS 백업과 검증 명령을 포함한 절차를 반기마다 탁상훈련하고 담당자 부재 상황에서도 실행되는지 점검합니다.
- 등록기관 긴급 연락처·계약·결제·회사 소유 증빙을 오프라인 보관
- 과거 DNS·변경 로그를 보존하고 관리자 인증정보·세션 동시 교체
- 웹·메일 복구와 고객 안내, 담당자 부재를 포함한 반기 훈련
이 주제로 함께 많이 찾는 안내
상담 전에 많이 묻는 내용
Q. 자동갱신을 켜면 도메인 만료 걱정은 없어지나요?
아닙니다. 결제수단 만료, 한도나 연락처 오류로 자동갱신이 실패할 수 있습니다. 자동갱신 상태와 결제수단을 확인하고 만료일 전 여러 시점에 복수 담당자가 직접 점검하세요.
Q. DNS를 한 사람이 관리하면 더 빠르고 안전하지 않나요?
작업은 빨라질 수 있지만 계정 탈취, 실수와 담당자 부재가 단일 실패점이 됩니다. 요청과 승인을 분리하고 비상 접근권한을 별도로 마련해 최소 두 명이 검증·복구할 수 있게 하세요.
Q. 네임서버가 갑자기 바뀌었다면 무엇부터 해야 하나요?
등록기관과 DNS 제공자의 변경 기록과 로그인 알림을 보존하고 즉시 긴급 지원에 연락하세요. 정상 네임서버와 레코드를 복구하는 동시에 관련 관리자 계정의 비밀번호·다중인증·세션을 교체하고 웹·메일 영향을 확인해야 합니다.
참고 출처 및 업데이트
NIST, Secure Domain Name System (DNS) Deployment Guide | Final publication, 작성기관 미국 국립표준기술연구소(NIST), 작성자 기관 편집팀, 작성일 2026-03-19, 수집일 2026-09-18NIST SP 800-81r3, Secure Domain Name System (DNS) Deployment Guide, 작성기관 미국 국립표준기술연구소(NIST), 작성자 기관 공동명의, 작성일 2026-03, 수집일 2026-09-18ICANN SSAC, SAC 007 Domain Name Hijacking: Incidents, Threats, Risks and Remediation, 작성기관 ICANN Security and Stability Advisory Committee, 작성자 위원회 공동명의, 작성일 2005-07-12, 수집일 2026-09-18ICANN, About Lost Domain Names, 작성기관 Internet Corporation for Assigned Names and Numbers(ICANN), 작성자 기관 편집팀, 작성일 미표기, 수집일 2026-09-18최초 작성 2026-09-18 · 최종 수정 2026-09-18
