레지스트라 잠금 vs 계층형 방어: 언제 무엇이 이길까

야간에 자고 일어났더니 회사가 소유한 모든 도메인이 — 운영 서버, 스테이징, MX 레코드를 담고 있던 그 도메인까지 — 도메인 등록기관에 의해 정지되어 있다고 생각해 보세요. 배포가 깨진 것도, 서버가 죽은 것도 아닙니다. 신뢰·안전 팀의 누군가(아마도 자동화된 악용 신고 파이프라인)가 스위치를 내렸고, 인터넷에서의 존재감 전체가 사라진 겁니다. 가설이 아닙니다. 확인되지 않은 악용 신고, 모호한 트윗, 수백만 개 사용자 업로드 중 단 하나의 플래그된 이미지 때문에 등록기관이 계정을 비활성화했다는 공포 사례가 sysadmin 커뮤니티에 꾸준히 올라올 정도로 자주 일어납니다.

인프라 팀에서 장애 대응을 해온 지 여러 해가 됐는데, 패턴은 늘 같습니다. 엔지니어들은 컴퓨트에는 정교한 이중화를 설계합니다. 멀티 AZ, 멀티 리전, 페일오버 런북까지요. 그러면서 정작 다시 배포할 수 없는 단 하나의 자산, 즉 도메인 이름은 비밀번호와 어쩌면 SMS 코드 하나로 보호되는 단일 계정에 그대로 둡니다. 이 글은 그 위험을 다루는 두 가지 철학을 비교합니다. 전통적인 등록기관 잠금(괜찮은 등록기관을 고르고, 계정을 강화하고, 그들을 믿는다) 방식과 계층형 방어(등록기관이 당신을 저버릴 것이라 가정하고 그 주변을 설계한다) 방식입니다. 결론부터 말하면 둘 다 필요하지만, 새벽 3시에 실제로 당신을 살리는 쪽은 두 번째입니다.

등록기관이 왜 다른 종류의 단일 장애점인가

스택에 있는 대부분의 단일 장애점은 직접 통제하는 것들입니다. 데이터베이스 프라이머리, NAT 게이트웨이, 메시지 브로커 같은 것들은 복제할 수 있고, 페일오버 계획도 직접 작성했죠. 등록기관은 세 가지 이유로 다릅니다. 첫째, 복제할 수 없는 제어 평면 의존성입니다. 같은 도메인에 대해 등록기관을 두 개 둘 수는 없습니다. 레지스트리에는 등록 대행자(sponsor of record)가 정확히 하나뿐이니까요. 둘째, 등록기관 장애는 느리게 진행됩니다. 정상 상황에서도 도메인 이전에는 5~7일이 걸리고, 현재 등록기관이 계정을 막아버렸다면 이전을 시작하기 위한 인증 코드조차 받지 못할 수 있습니다. 셋째, 장애가 기묘하게 적대적입니다. 공격자가 아니라 제공자 자신이, 당신이 본 적도 없는 악용 신고를 근거로 당신에게 등을 돌리는 겁니다.

피해 범위도 사람들이 생각하는 것보다 나쁩니다. 등록기관이 도메인을 정지시키면 보통 NS 레코드를 차단 안내 페이지로 돌리거나 그냥 응답을 멈춥니다. 웹사이트가 죽는 건 당연하고, 이메일(MX 레코드는 DNS에 있으니까요)도, 콜백이 도메인을 참조하는 SSO도, API 클라이언트도, 같은 도메인에 있는 상태 페이지도 죽습니다. 그리고 제가 가장 황당하게 여기는 것은 복구 안내를 받을 이메일 주소까지 막힌다는 점입니다. 등록기관 계정 이메일이 admin@yourdomain.com인데 yourdomain.com이 정지되면, 지원팀이 신뢰하지 않을 주소로 당신의 신원을 증명해야 하는 상황이 됩니다. 이 악순환이 장애 대응 하루를 통째로 잡아먹는 걸 직접 본 적이 있습니다.

경제적 인센티브도 당신에게 불리하게 움직입니다. 여러 대형 등록기관이 그랬듯이 사모펀드에 인수되면 전개 방식은 예측 가능합니다. 사람 지원을 줄이고, 악용 처리를 자동화하고, 가격을 올리죠. 자동화된 악용 시스템은 당신의 위험이 아니라 자신들의 위험을 최적화합니다. 나중에 무고한 것으로 밝혀진 도메인을 정지시켜도 그들에게는 비용이 없습니다. 나중에 유죄로 밝혀진 도메인을 그대로 두면 레지스트리 문제와 나쁜 언론이 따라옵니다. 자동화가 어느 쪽으로 실수할지는 뻔합니다.

첫 번째 접근: 등록기관 잠금 — 단일 지점을 단단히 만들기

잠금 철학은 이렇게 말합니다. 등록기관이 단일 장애점이라는 사실을 받아들이고, 그 지점을 최대한 강하게 만들라는 것입니다. 이는 대부분의 기업이 실제로 쓰는 전략입니다. 명확히 정리했든 아니든 말이죠. 제대로 하면 다음과 같습니다.

• 가격이 아니라 지원 품질로 등록기관을 고르세요. 도메인 하나당 아끼는 연 3달러는 하루 다운타임 앞에서 아무 의미가 없습니다. 전화 지원, 대규모 포트폴리오라면 지정 담당자, 그리고 최악의 경우 내 관할권에서 소송을 걸 수 있는 회사를 원해야 합니다.
• 모든 도메인에 등록기관 잠금(clientTransferProhibited)을 켜고, 중요한 도메인에는 레지스트리 잠금도 거세요. 레지스트리 잠금은 네임서버나 이전에 대한 어떤 변경이든 대역 외 검증(보통 암호 구절을 이용한 전화 확인)을 요구합니다. 귀찮지만, 그게 핵심입니다.
• 하드웨어 키나 TOTP 2단계 인증을 쓰고 SMS는 절대 쓰지 마세요. 그럴듯한 채팅 이야기에 속아 지원 담당자가 2FA를 제거해 준 사고 사례는 수없이 많습니다. 일부 등록기관은 이제 '하드웨어 키 없이는 계정 변경 불가' 정책을 제공하니 꼭 활용하세요.
• 등록기관 계정에는 해당 등록기관에 등록된 도메인이 아닌, 역할 기반의 전용 이메일 주소를 쓰세요. 예를 들면 완전히 다른 곳에 등록된 domains-admin@example.org 같은 주소입니다.
• 접근 권한을 제한하세요. 이름이 명시된 두세 명만 두고, 자격 증명은 회사 금고에 보관하세요. 스프레드시트에 적힌 공용 로그인은 안 됩니다.
• 모든 것을 문서화하세요. 계정 번호, PIN, 지원 에스컬레이션 경로, 계정 인증에 쓴 정확한 신분증 정보까지요. 장애 대응 런북에 넣어두세요.

잠금에는 확실한 장점이 있습니다. 가장 흔한 등록기관 사고를 막아주죠. 그 사고는 압류가 아니라 탈취입니다. 사회공학적 이전과 계정 탈취로 수년간 고가 도메인이 도난당해 왔는데, 레지스트리 잠금과 하드웨어 2FA를 쓰면 그 대부분을 막을 수 있습니다. 또 저렴하고 지속적인 엔지니어링도 필요 없습니다.

하지만 불편한 진실이 있습니다. 잠금은 공격자로부터 당신을 보호할 뿐, 등록기관 자신으로부터는 보호하지 못합니다. 위에 나열한 모든 통제 수단은 등록기관이 운영하는 통제입니다. 그들의 악용 자동화가 계정을 정지시키면, 등록기관 잠금이 오히려 당신을 잠가버립니다. 지원 PIN은 닿을 수 없는 시스템에 있고, 이 모든 것을 무시할 수 있었던 사람은 지난 분기에 지원 조직이 '최적화'되면서 이제 존재하지 않을지도 모릅니다. 단순한 오탐 사례에서도 복구에 여섯 시간 이상 걸린다는 보고가 있고, 정지가 주말을 끼면 며칠짜리 소동이 됩니다. 잠금은 필요하지만 충분하지는 않습니다.

두 번째 접근: 계층형 방어 — 등록기관이 당신을 배신할 것이라고 가정하기

계층형 철학은 더 어두운 전제에서 출발합니다. 언젠가 악의, 자동화, 또는 실수로 등록기관이 도메인을 내려버릴 것이고, 그들의 지원 대기열이 당신 차례에 닿기 전에 다시 온라인 상태로 돌아가야 한다는 것입니다. 이는 치명적 장애에 대비한 방어적 엔지니어링과 같은 사고방식입니다. 재앙을 막는 게 아니라, 재앙을 견딜 수 있게 만드는 겁니다.

핵심 기법은 보통 묶여 있는 계층들을 분리하는 것입니다. 작은 회사 대부분은 도메인을 사고, 등록기관의 DNS를 쓰고, 등록기관의 호스팅 부서에서 호스팅하고, 이메일까지 같은 곳에서 받습니다. 한 계정에 단일 장애점이 네 개나 쌓여 있는 셈이죠. 이것들을 분리하세요.

• 도메인 등록: 안정성과 지원을 기준으로 고른 등록기관 A.
• 권한 있는 DNS: 독립된 DNS 제공자 B(또는 이중 프라이머리 구성의 두 제공자)에서 코드로 관리.
• 호스팅: 워크로드에 맞는 곳이면 어디든, 위 둘과 무관하게.
• 이메일: 전용 제공자를 쓰고, A와 B의 계정 복구 주소는 또 다른 도메인에 둡니다.
• 예비 도메인: 다른 등록기관에 미리 준비해 둔 대체 도메인. TLS 인증서를 발급해 두고, 가장 중요한 서비스의 최소 버전이 이미 그 도메인에서 응답하도록 해 둡니다.

예비 도메인은 강조할 가치가 있습니다. 거의 아무도 하지 않는데, 레버리지가 가장 큰 조치이기 때문입니다. 주 도메인이 정지되면 DNS TTL과 리졸버 캐시 때문에 그냥 '백업으로 전환'할 수 없습니다. 백업은 장애 이전에 이미 존재하고, 워밍업되고, 해석 가능한 상태여야 합니다. 다른 곳에 등록된 example-status.net 같은 대체 도메인에 상태 페이지, 장애 공지, 비상 MX 레코드를 올려두면, 회사를 죽일 수 있는 장애가 창피한 화요일 하루로 바뀝니다.

DNS를 코드로: 모두가 건너뛰는 계층

실제 장애에서 두 번이나 본 실패 사례가 있습니다. 팀이 등록기관 정지 후 도메인을 되찾고 모든 것을 다시 켰는데, DNS가 틀려 있는 겁니다. 존의 '원본'이 등록기관의 웹 UI였는데, 그 UI는 장애 중에 접근할 수 없었고 어차피 누구의 기억과도 어긋나 있었기 때문입니다. 장애 중에 200개 레코드짜리 존 파일을 기억에 의존해 재구성하는 건 특별한 종류의 고통입니다. 앞서 쓴 글에서 말했듯이 DNS 설정 실수는 정상 상황에서도 운영 환경을 계속 망가뜨립니다. 등록기관 장애 중에는 그게 치명적입니다.

해결책은 지루합니다. DNS 존을 버전 관리되는 코드로 관리하고, CI로 배포하세요. dnscontrol이나 Terraform의 DNS 프로바이더 같은 도구로 존을 선언적으로 기술하고, 여러 제공자에 밀어 넣을 수 있습니다. 그러면 어떤 제공자의 제어 평면이 사라져도 DNS 상태는 살아남고, 'DNS 제공자 B로 페일오버'는 복사-붙여넣기 대작업이 아니라 한 줄짜리 변경과 배포가 됩니다.

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

이중 권한 DNS는 과소평가되고 있습니다. 대부분의 리졸버는 나열된 모든 네임서버를 기꺼이 시도하므로, 한 제공자가 장애를 겪어도(그리고 대형 DNS 제공자들은 실제로 장애를 겪습니다) 이름 해석은 계속됩니다. 문제는 두 제공자를 동기화 상태로 유지하는 것인데, 바로 이것이 DNS-as-code가 공짜로 주는 것입니다. 그것 없이는 이중 제공자 DNS는 드리프트를 만들어내는 기계이며, 단일 제공자보다 나쁠 수도 있습니다.

TTL에 관한 주의점 하나: 팀들은 '성능을 위해' TTL을 86400으로 올리기를 좋아하는데, 장애 중에야 인터넷의 상당수가 옛 네임서버 레코드를 하루 종일 캐싱하고 있다는 걸 발견합니다. 네임서버 관련 레코드와 비상시 바꿀 수 있는 모든 레코드는 TTL을 300~900초로 유지하세요. 쿼리 볼륨 비용은 민첩성에 비하면 사소합니다.

정면 비교: 각 접근이 이기는 경우

두 전략은 서로 다른 위협과 서로 다른 조직을 위해 최적화되어 있으니, 트레이드오프를 분명히 짚어보겠습니다.

• 위협 모델: 잠금은 탈취와 사회공학에 강합니다. 통계적으로 흔한 재난이죠. 계층형 방어는 등록기관 측 장애에 강합니다. 악용 자동화, 계정 압류, 파산, 지원 붕괴 같은 경우입니다.
• 비용: 잠금은 거의 비용이 들지 않습니다. 레지스트리 잠금 수수료, 하드웨어 키, 그리고 규율 정도죠. 계층형 방어에는 두 번째 제공자 요금, 예비 도메인, CI 배관 작업, 그리고 드리프트를 막기 위한 지속적인 관심이 듭니다.
• 복구 시간: 압류 상황에서 잠금만 한 팀은 지원 대기열의 처분에 맡겨집니다(제가 들은 모든 사례에서 몇 시간에서 며칠). 따뜻하게 준비된 예비 도메인이 있는 계층형 팀은 몇 분에서 몇 시간 안에 복구합니다.
• 운영 부담: 잠금은 한 번 설정하면 그만입니다. 계층형 방어는 관리하지 않으면 썩습니다. 테스트하지 않은 예비 도메인에 만료된 인증서가 붙어 있다면 그것은 보안 연극일 뿐입니다.
• 조직 적합성: 제품 하나를 가진 다섯 명짜리 스타트업이라면 완전한 잠금에 가장 저렴한 계층형 조치 두 가지(외부 DNS-as-code, 도메인 밖 복구 이메일)를 더하는 게 맞습니다. 도메인이 죽으면 매출도 죽는 회사라면 계층형 스택 전체가 필요합니다.

잠금은 공격자로부터 도메인을 보호합니다. 계층형 방어는 등록기관으로부터 비즈니스를 보호합니다. 당신은 둘 다에 노출되어 있으니 둘 다 필요합니다.

너무 늦기 전까지 아무도 쓰지 않는 복구 런북

어떤 자세를 고르든, 압류 런북을 지금 쓰세요. 제가 지켜본 장애 대응이 잘 된 곳은 모두 런북이 있었고, 재난으로 번진 곳은 즉흥적으로 대처한 곳이었습니다. 런북에는 순서대로 다음이 들어가야 합니다. 범위 확인(한 도메인인지 계정 전체인지 — clientHold나 serverHold 같은 whois 상태 코드를 확인), 문서화된 계정 식별자로 지원 티켓 열기, 예비 도메인 활성화 및 상태 공지 업데이트, 죽은 도메인에 의존하지 않는 채널로 고객에게 알림, 그리고 해결을 기다리지 말고 이전 반출 절차를 병렬로 시작하기. 해결될 때까지 기다렸다가 떠날지 결정하지 마세요.

지루한 부분도 리허설하세요. 하드웨어 키를 가지고, 정지된 도메인의 SSO 뒤에 있는 패스워드 매니저 없이, 깨끗한 기기에서 등록기관에 실제로 로그인할 수 있나요? 레지스트리 잠금 암호 구절은 온콜 담당자가 찾을 수 있는 곳에 있나요? 팀들은 분기마다 데이터베이스 페일오버를 테스트하지만 등록기관 복구는 한 번도 테스트하지 않습니다. 등록기관 장애가 다른 모든 것에 접근하는 데 쓰는 SSO까지 무너뜨린다는 점을 생각하면, 우선순위가 거꾸로입니다.

제 권장 사항

잠금은 완전하게 하세요. 반나절이면 끝나고, 가장 가능성 높은 공격을 막아줍니다. 그다음 계층형 방어 세 가지를 이 순서대로 정확히 구현하세요. 권한 있는 DNS를 등록기관에서 옮겨 코드로 관리하기, 등록기관 계정의 복구 이메일을 다른 등록기관에 등록된 도메인으로 옮기기, 그리고 인증서, 상태 페이지, 비상 MX를 갖춘 따뜻한 예비 도메인 구축하기. 이 세 가지만으로도 연간 수백 달러로 가장 흔한 장애 모드를 대부분 커버합니다. 하루 동안 도메인을 완전히 잃으면 얼마나 손해인지 설명할 수 있는 조직에만 등록기관 이중화와 DNS 이중화를 갖춘 완전한 아키텍처를 권합니다. 그 숫자에 여섯 자리가 들어간다면, 이미 무엇을 해야 할지 아시는 겁니다.

그리고 아직도 주로 가격을 보고 등록기관을 고르고 있다면, 그만두세요. 할인 등록기관 시장은 인간의 판단을 자동화로 대체하려는 소유주들 아래 통합되고 있습니다. 그 자동화는 오탐으로 기꺼이 당신을 정지시키고, 티켓은 목요일에야 확인할 겁니다. 도메인은 컨테이너 이미지로 다시 배포할 수 없는 유일한 인프라입니다. 그렇게 다루세요.