이름 하나가 IP 주소가 되기까지
주소창에 www.example.com을 입력하면, 보통 ISP 등이 운영하는 재귀 리졸버(캐시 서버)가 대신 물어봅니다. 리졸버는 먼저 루트 서버에 묻고, 루트는 직접 답하는 대신 .com 담당 서버를 알려 줍니다. 다시 .com 서버에 물으면 example.com 담당 서버를 알려 주고, 마지막으로 그 서버가 www의 IP 주소를 답합니다(위키백과의 예시 흐름). 답에는 TTL(유효 시간)이 붙어 있어 그동안은 캐시에 저장되므로 대부분의 질의는 루트까지 올라가지 않습니다. 그래서 DNS 설정을 바꿔도 캐시가 만료될 때까지는 옛 값이 보일 수 있습니다. 루트 서버는 13개 그룹으로 나뉘고, 각 그룹은 애니캐스트로 전 세계에 복제본을 둡니다.
누가 무엇을 맡나: 역할 비교
| 주체 | 하는 일 | 예 |
|---|---|---|
| ICANN | 도메인 이름 공간의 최상위 정책 조정, 등록기관 인증, 루트 영역 관련 IANA 기능 수행 | 1998년 9월 30일 미국 캘리포니아에서 설립 |
| 레지스트리 | TLD 하나의 등록 데이터베이스를 관리 | .com, .org, .kr 등 TLD마다 각각 |
| 등록기관(레지스트라) | 고객에게 도메인 사용권을 등록·갱신해 주는 창구 | ICANN 인증을 받은 업체 |
| 등록자 | 도메인을 등록해 쓰는 개인·단체 | 사이트 운영자 |
TLD는 국가 코드 TLD(ccTLD, ISO 3166 두 글자 국가 코드 기반, 예: .kr)와 일반 TLD(gTLD, 예: .com .net .org)로 나뉩니다. ICANN은 2012년 1월부터 새 gTLD 신청을 받았고 초기 신청 수수료는 185,000달러였습니다. 한 이름(레이블)은 1~63바이트, 전체 이름은 텍스트 기준 253자 이내여야 합니다. 한글 같은 비ASCII 이름은 퓨니코드(Punycode)로 변환되어 DNS에 들어갑니다(예: københavn.eu는 xn--kbenhavn-54a.eu).
실제 사례 세 가지
사례 1. 2016년 Dyn 공격: 이름 체계 한 곳이 멈추자 (제공업체 장애)
2016년 10월 21일, DNS 제공업체 Dyn에 세 차례(UTC 기준 약 11시, 15시 50분, 20시)에 걸쳐 대규모 DDoS 공격이 들어왔습니다. 공격은 Mirai 악성코드에 감염된 카메라, 가정용 공유기 등 IoT 기기들의 봇넷에서 나왔다고 보도되었습니다. 그 결과 Twitter, Netflix, Reddit, GitHub, PayPal 등 약 70개 서비스를 이용하기 어려운 사람이 유럽과 북미, 특히 미국 동부에 많이 생겼습니다(위키백과 기준). 해당 서비스의 서버는 멀쩡했지만 이름을 IP 주소로 바꿔 주는 단계가 막힌 것입니다. 배울 점은 한 DNS 제공업체에 의존하는 구조가 단일 장애점이 될 수 있다는 것, 그리고 보안이 허술한 기기가 인프라를 흔드는 도구가 될 수 있다는 것입니다. 공격 주체에 대해서는 여러 주장이 있었으나 당시 확정되지 않았습니다.
사례 2. 2021년 Facebook 장애: 내부 명령이 DNS까지 닫은 경우 (설계 연쇄)
2021년 10월 4일 UTC 15시 39분경 시작된 Facebook 접속 불능은 약 6~7시간 이어졌습니다. Facebook 엔지니어링 팀은 10월 5일 블로그에서, 백본 용량을 점검하려던 유지보수 명령이 실수로 모든 데이터센터 연결을 끊었다고 설명했습니다. DNS 서버는 데이터센터와 연락이 끊기면 스스로 BGP 경로를 거두도록 설계되어 있었고, 그 결과 외부에서 Facebook의 DNS 서버에 닿지 못해 도메인 이름 조회가 모두 실패했습니다. 사내에서도 이메일, 사원 디렉터리, 출입 배지 시스템에 문제가 생겼다고 보도되었습니다(뉴욕타임스 보도를 인용한 위키백과 기준). 배울 점은 DNS가 라우팅(BGP)과 이어져 있어, 이름 조회 실패가 서버 장애처럼 보이지만 원인은 훨씬 아래 계층에 있을 수 있다는 것입니다.
사례 3. symbolics.com: 이름 등록의 출발점 (역사)
1985년 3월 15일 매사추세츠의 컴퓨터 회사 심볼릭스가 등록한 symbolics.com은 최초의 .com 도메인 등록으로 알려져 있습니다. 당시는 DNS 규격이 정해진 지 얼마 안 된 때여서, 도메인은 상업적 자산이라기보다 네트워크 연결에 필요한 주소 체계였습니다. 지금 .com은 레지스트리가 데이터베이스를 관리하고 ICANN 인증 등록기관이 판매하는 구조로 운영됩니다. 이 사례는 도메인이 처음에는 소수의 기관이 쓰던 주소였다가 일반 사용자의 이름표로 확장된 흐름을 보여 줍니다.
직접 확인해 보기
- 등록 정보 조회: WHOIS 도메인 조회 가이드를 참고해 등록일·만료일·네임서버를 확인합니다. 등록자 정보는 일부 가려져 표시될 수 있으며 공개 범위는 레지스트리와 등록기관 정책에 따라 다릅니다.
- 만료일 관리: 도메인은 기간 단위로 사용권을 유지하는 방식이므로 만료일과 자동 갱신 여부를 달력에 적어 둡니다.
- DNS 변경 후 기다리기: 값을 바꿨는데 안 보이면 TTL 때문에 캐시가 남은 것일 수 있습니다. DNS 전파 가이드도 참고하세요.
- 연락 가능한 이메일 유지: 등록 정보의 연락처가 바뀌면 갱신 안내를 놓치지 않도록 수정합니다.
흔한 오해와 정정
- 오해: 도메인을 사면 웹사이트가 생긴다. 실제: 도메인은 주소일 뿐이고, 사이트 파일을 올릴 호스팅이 따로 필요합니다. 이름을 가리킬 대상(IP)이 없으면 열리지 않습니다.
- 오해: .com이 아닌 도메인은 신뢰할 수 없다. 실제: TLD는 종류를 나타낼 뿐 사이트의 품질을 보증하지 않습니다. ccTLD, gTLD 모두 누구나 규정에 맞으면 등록할 수 있는 것이 많습니다(TLD마다 요건은 다름).
- 오해: 서브도메인은 별도로 사야 한다. 실제: blog.example.com 같은 서브도메인은 상위 도메인 소유자가 DNS 설정으로 만듭니다.
- 오해: 사이트가 안 열리면 서버가 죽은 것이다. 실제: 위 두 사례처럼 이름 조회 단계의 문제일 수 있습니다.
한계와 더 알아볼 점
이 글은 개념 이해를 위한 정리이며 등록 요건, 비용, 분쟁 해결 절차는 TLD와 등록기관마다 다릅니다. 상표와 관련된 분쟁이나 개인정보 공개 범위는 해당 레지스트리와 법령을 확인해야 합니다. DNS 응답에 서명하는 DNSSEC은 위조된 응답을 막는 기술이지만 도입 여부는 도메인마다 다릅니다. 루트 서버가 13개 그룹이라는 표현은 서버 대수가 아니라 주소(식별자) 수를 말하며 실제로는 훨씬 많은 복제 서버가 분산 운영됩니다.
이어서 읽어 보세요
- 웹 호스팅 종류 완전정복: 도메인이 가리킬 서버의 종류
- DNS 조회 과정: 리졸버가 묻는 순서를 더 자세히
- DNS 레코드 종류: A, CNAME, MX 등 설정 항목
- DNSSEC: 응답을 서명으로 보호하는 방법
자주 묻는 질문
레지스트리와 등록기관은 무엇이 다른가요?
레지스트리는 .com 같은 TLD 하나의 등록 데이터베이스를 관리하는 곳이고, 등록기관은 ICANN 인증을 받아 고객에게 도메인을 등록·갱신해 주는 창구입니다. 일반 사용자는 보통 등록기관만 상대합니다.
도메인 이름은 길이 제한이 있나요?
점으로 나뉜 각 부분(레이블)은 1~63바이트, 전체는 텍스트 기준 253자 이내입니다. 한글 도메인은 내부적으로 퓨니코드로 변환되어 이 제한이 변환된 길이에 적용됩니다.
DNS 설정을 바꿨는데 왜 어떤 곳에서는 옛 주소가 보이나요?
응답에 붙은 TTL 동안 리졸버가 이전 값을 캐시에 보관하기 때문입니다. TTL이 지나야 새 값을 다시 물어보며, 설정한 TTL 값에 따라 걸리는 시간이 달라집니다.
루트 서버가 13개라는데 정말 13대인가요?
13개 그룹(식별자)입니다. 각 그룹은 애니캐스트로 전 세계에 많은 복제 서버를 두고 있어 실제 대수는 13보다 훨씬 많습니다.
도메인은 한 번 사면 영원히 내 것이 되나요?
아니요, 도메인은 보통 1년 단위로 사용료를 지불하는 방식이며, 갱신하지 않으면 만료되어 다른 사람이 등록할 수 있게 됩니다.
도메인을 바꾸면 웹사이트 내용도 사라지나요?
아니요, 도메인은 어디까지나 주소 역할만 하기 때문에 실제 웹사이트 데이터가 저장된 호스팅 서버와는 별개이며, 도메인만 바꾸고 같은 호스팅을 계속 사용할 수 있습니다.