업데이트됨 1개월 전
브라우저에 도메인 이름을 입력하면 이상한 일이 벌어집니다. 당신의 컴퓨터는 답을 모르는 서버에게 묻습니다. 그 서버는 역시 답을 모르는 다른 서버에게 묻습니다. 이 과정이 계속되다가 마침내 어딘가의 서버가 말합니다. "네, 알고 있습니다. IP 주소는 이렇습니다."
이것이 DNS의 설계 방식입니다. DNS는 답을 가진 시스템이 아니라 다음에 물어볼 곳을 안내하는 시스템입니다.
루트는 google.com이 어디에 있는지 모릅니다. .com을 담당하는 서버가 누구인지만 알고 있습니다. 그것으로 충분합니다. 바로 이 방식 덕분에 시스템이 자체 무게에 눌려 무너지지 않고 매일 수십억 건의 도메인 조회가 이루어집니다.
뒤집힌 트리
DNS는 뒤집힌 트리 구조로 운영됩니다. 꼭대기에는 루트가 있으며, 하나의 점(.)으로 표현됩니다. 그 아래에 최상위 도메인—.com, .org, .uk—이 가지를 뻗습니다. 그 아래에는 실제로 입력하는 도메인—example.com, connected.app—이 있습니다. 그리고 그 아래에는 www, blog, api와 같은 서브도메인이 있습니다.
www.example.com을 조회할 때 DNS는 이를 오른쪽에서 왼쪽으로 읽습니다: 루트 → .com → example.com → www. 각 단계는 다음 단계에 위임합니다. 평소에 입력하지 않는 마지막 점—www.example.com.—이 모든 조회가 시작되는 루트를 나타냅니다.
이 구조는 근본적인 문제를 해결합니다. 지구상의 모든 도메인을 담은 데이터베이스를 단 하나의 주체가 유지할 필요가 없다는 것입니다. 루트는 TLD에 대해 알고 있습니다. .com TLD는 .com으로 끝나는 도메인에 대해 알고 있습니다. 그리고 example.com은 자신의 서브도메인에 대해 알고 있습니다. 각 단계는 자신의 영역만 관리합니다.
루트 서버: 13개의 주소, 약 2,000대의 머신
꼭대기에는 루트 네임서버가 있습니다. A부터 M까지의 알파벳으로 식별되는 13개의 논리적 서버입니다. 하지만 "13개"라는 표현은 오해의 소지가 있습니다. 각 알파벳은 하나의 IP 주소를 나타내고, 각 IP 주소는 애니캐스트를 통해 전 세계에 분산된 여러 물리적 머신에서 서비스됩니다. a.root-servers.net에 쿼리를 보내면 당신과 가장 가까운 "A" 서버에 요청이 전달됩니다.
2024년 기준으로 전 세계에 약 2,000개의 루트 서버 인스턴스가 운영되고 있습니다1. 12개의 독립 기관이 운영합니다. Verisign은 A와 J를, NASA는 E를, 미국 육군 연구소는 H를 운영하며, RIPE NCC, Netnod, 일본의 WIDE Project 같은 국제 기관들이 나머지를 운영합니다. 이러한 다양성은 의도적인 것입니다. 단 하나의 주체가 DNS의 근간을 통제하지 못하도록 하기 위해서입니다.
루트 서버의 역할은 딱 하나입니다. 어떤 TLD 서버가 특정 확장자를 담당하는지 알려주는 것입니다. 루트 서버에 example.com에 대해 물으면 이렇게 응답합니다. "저는 모르지만, .com을 담당하는 서버들은 여기 있습니다." example.jp에 대해 물으면 .jp 서버들을 알려줍니다.
이 제한된 범위 덕분에 루트 서버는 빠르게 동작합니다. 전체 루트 존—현존하는 모든 TLD 위임 정보—은 2MB 미만의 파일에 담깁니다2. 이 파일에는 1,500개 이상의 최상위 도메인이 나열되어 있으며, 모든 루트 서버 인스턴스가 전체를 메모리에 올려둘 수 있을 만큼 작습니다.
TLD 서버: 중간 계층
최상위 도메인 서버는 자신의 확장자 아래에 있는 모든 것을 관리합니다. .com 서버는 모든 .com 도메인에 대해 알고 있습니다. .uk 서버는 모든 .uk 도메인에 대해 알고 있습니다.
TLD는 여러 종류가 있습니다:
- 일반 TLD (gTLD):
.com,.org,.net, 그리고.app,.dev,.blog같은 신규 TLD - 국가 코드 TLD (ccTLD):
.us,.uk,.de,.jp—각 국가가 자국 TLD를 관리 - 스폰서 TLD:
.edu,.gov,.mil—특정 기관에만 제한
Verisign은 .com과 .net을 운영하는데, 이 둘을 합치면 1억 6,900만 개가 넘는 도메인 등록을 차지합니다3. Verisign의 TLD 서버가 example.com에 대한 쿼리를 받으면 IP 주소를 반환하지 않습니다. 또 다른 안내를 반환합니다. "example.com을 담당하는 네임서버들은 여기 있습니다."
또 한 번의 전달. 또 한 번의 위임.
권위 있는 네임서버: 답이 있는 곳
권위 있는 네임서버는 이 연쇄가 끝나는 곳입니다. 이 서버들은 실제 DNS 레코드를 보유합니다—이름을 IP 주소로 매핑하는 A 레코드, 이메일을 라우팅하는 MX 레코드, 별칭을 만드는 CNAME 레코드.
도메인을 등록할 때, 어떤 네임서버가 해당 도메인을 대리하는지 지정합니다. 그 네임서버는 등록 기관, Cloudflare나 AWS Route 53 같은 호스팅 제공업체, 또는 직접 구축한 인프라가 될 수 있습니다.
권위 있는 네임서버는 최종 정보 소스입니다. ns1.example.com이 www.example.com이 192.0.2.1을 가리킨다고 말하면, 그것이 정답입니다. 그 위의 어떤 서버도 이를 무시할 수 없습니다. 그들은 쿼리를 이 서버 방향으로 안내할 수 있을 뿐입니다.
대부분의 도메인은 여러 개의 권위 있는 네임서버를 갖습니다—ns1과 ns2, 흔히 서로 다른 데이터 센터에 위치합니다. 하나가 장애를 일으키면 쿼리는 다른 서버로 라우팅됩니다. 모든 단계에서 이중화가 이루어집니다.
처음부터 끝까지의 쿼리
www.example.com을 입력합니다. 브라우저가 운영체제에 묻습니다. 운영체제가 설정된 리졸버—보통 ISP의 것, 또는 Google의 8.8.8.8, Cloudflare의 1.1.1.1—에 묻습니다.
리졸버가 캐시를 확인합니다. 아무것도 없습니다. 이제 계층을 하나씩 따라갈 차례입니다.
1단계: 루트에 문의. ".com에 대한 정보는 어디서 찾을 수 있나요?" 루트가 .com TLD 서버 목록으로 응답합니다.
2단계: TLD에 문의. 리졸버가 하나를 선택하고 묻습니다. "example.com에 대한 정보는 어디서 찾을 수 있나요?" TLD가 example.com의 권위 있는 네임서버—그리고 그 IP 주소—를 응답합니다.
마지막 부분이 중요합니다. 이것을 글루 레코드라고 하며, 닭이 먼저냐 달걀이 먼저냐 하는 문제를 해결합니다. ns1.example.com을 조회하려면 DNS가 필요하지만, example.com의 DNS를 위해서는 ns1.example.com이 필요합니다. TLD가 안내 응답 안에 IP 주소를 포함시킴으로써 이 순환을 끊습니다.
3단계: 권위 있는 서버에 문의. "www.example.com의 IP 주소는 무엇인가요?" 마침내 실제 답이 옵니다: 192.0.2.1.
리졸버는 TTL에 따라 응답을 캐시하고, 브라우저에 반환하며, 브라우저가 연결합니다. 전체 여정—루트에서 TLD, 권위 있는 서버까지—은 보통 수십 밀리초 안에 완료됩니다. 캐시에 저장된 경우 이후 조회는 한 자릿수 밀리초 안에 해결됩니다.
위임이 효과적인 이유
각 단계는 모든 것을 알려 하지 않습니다. 각 단계는 다음에 누구에게 물어야 하는지만 압니다.
루트는 .com을 Verisign에 위임합니다. Verisign은 example.com을 등록한 사람에게 위임합니다. 도메인 소유자는 더 세분화하여 위임할 수 있습니다—blog.example.com은 api.example.com과 완전히 다른 네임서버를 가리킬 수 있습니다.
중앙 데이터베이스 없음. 새 도메인을 추가해도 루트를 업데이트할 필요가 없습니다. TLD만 업데이트하면 되고, 그것조차도 단지 포인터를 추가하는 것에 불과합니다.
격리된 장애. 당신의 권위 있는 네임서버가 다운되면 그건 당신의 문제입니다. 루트 서버는 눈치채지 못합니다. TLD 서버는 관심 없습니다. 당신의 장애가 상위로 전파되지 않습니다.
분산된 제어. 서로 다른 기관이 서로 다른 영역을 통제합니다. 루트 존은 국제 협력을 통해 관리되고, TLD는 해당 운영자가, 개별 도메인은 소유자가 관리합니다. 단 하나의 주체가 DNS를 일방적으로 통제할 수 없습니다.
무한한 성장. 트리는 계속해서 성장할 수 있습니다. 새 TLD, 새 도메인, 새 서브도메인—각각은 그저 또 하나의 가지일 뿐이며, 해당 가지의 소유자가 관리합니다.
이것이 1980년대에 설계된 시스템이 하루에 수십억 건의 쿼리를 처리하는 방식입니다. 힘으로 밀어붙이는 것이 아니라 우아한 위임을 통해서. 모든 사람은 한 단계 아래를 가리키기에 충분한 것만 알고 있습니다.
DNS 계층 구조에 관한 자주 묻는 질문
루트 서버가 다운되면 어떻게 되나요?
눈에 띄는 일은 없습니다. 13개의 애니캐스트 주소 뒤에 약 2,000개의 물리적 인스턴스가 있고, 모든 단계에서 적극적인 캐싱이 이루어지기 때문에 개별 서버 장애는 주목받지 않습니다. DNS 리졸버는 자동으로 다른 루트 서버를 시도하며, 대부분의 쿼리는 어차피 루트에 도달하지도 않습니다—TLD 정보는 몇 시간 또는 며칠 동안 캐시됩니다.
직접 권위 있는 네임서버를 운영할 수 있나요?
네. 도메인 등록 기관에 네임서버의 IP 주소를 등록하면, 해당 서버가 도메인의 권위 있는 소스가 됩니다. 그러면 서버를 정상적으로 운영하고 올바르게 응답하는 것은 직접 책임져야 합니다. 많은 기관이 DNS 인프라에 대한 통제권을 위해 직접 운영합니다.
루트 서버 주소가 13개밖에 없는 이유는 무엇인가요?
역사적인 제약 때문입니다. 초기 DNS 패킷은 512바이트에 맞아야 했으며, 이는 응답에 포함할 수 있는 주소의 수를 제한했습니다. 애니캐스트가 물리적 한계를 해결했습니다—이제 13개의 주소가 전 세계 약 2,000대의 서버를 나타내지만—논리적 주소의 수는 그대로 유지됩니다.
등록 기관과 권위 있는 네임서버의 차이점은 무엇인가요?
등록 기관은 도메인을 구매하는 곳입니다. 비즈니스 관계를 처리하고 TLD의 레코드를 업데이트하여 네임서버를 가리키게 합니다. 권위 있는 네임서버는 DNS 레코드가 실제로 존재하는 곳으로, 도메인에 대한 쿼리에 응답합니다. 많은 등록 기관이 네임서버 서비스도 제공하지만, 그것들은 별개의 기능입니다. 한 등록 기관에서 도메인을 구입하고 DNS는 다른 곳에서 호스팅할 수 있습니다.
출처
이 페이지가 도움이 되었나요?