[웹 기반기술 38] DNS - 네임서버와 위임

도메인에 레코드를 넣어 두었다면, 그 레코드에 실제로 답하는 주체가 어딘가에는 있어야 한다. 그 주체가 바로 네임서버다. 네임서버는 특정 도메인의 레코드를 보관하고, 그 도메인에 대한 질문이 오면 권위 있는 답을 돌려주는 서버다. 도메인을 등록했다는 것은 이름을 확보한 것이고, 네임서버를 지정했다는 것은 그 이름의 질문에 누가 답할지를 정한 것이다. 이 둘은 별개의 결정이며, 실무에서 자주 혼동된다.

이번 편은 네임서버와 위임의 구조를 다룬다. 네임서버가 무엇이고 어떤 역할을 하는지, 위임이라는 개념이 계층을 따라 어떻게 이어지는지, 권위 있는 서버와 조회를 대신하는 리졸버가 어떻게 나뉘는지, 네임서버를 바꿀 때 무슨 일이 벌어지는지, 그리고 위임 과정에서 흔히 저지르는 실수는 무엇인지를 차례로 짚는다. 위임의 원리를 이해하면 도메인이 어떻게 전 세계 어디서든 같은 답을 내놓는지가 손에 잡힌다.

네임서버라는 응답 주체

네임서버는 한 도메인의 레코드 집합, 곧 존을 들고 있으면서 그에 대한 질문에 답하는 서버다. 누군가 특정 이름의 주소를 물으면, 그 이름을 관리하는 네임서버가 저장된 레코드를 찾아 응답한다. 도메인마다 이 응답을 책임지는 네임서버가 지정되어 있고, 그 지정 자체는 상위 계층에 기록된다. 그래서 도메인의 질문은 항상 위에서 아래로 내려가며 올바른 네임서버를 찾아간다.

하나의 도메인에는 대개 둘 이상의 네임서버가 지정된다. 서버 하나가 장애를 일으켜도 다른 서버가 답할 수 있어야 서비스가 끊기지 않기 때문이다. 이 여러 서버는 같은 존 내용을 공유하며, 그중 하나가 원본을 들고 나머지가 그 복제를 유지하는 구조가 흔하다. 어느 서버에 물어도 같은 답이 돌아오도록 존의 내용을 일관되게 맞추는 것이 네임서버 운영의 기본이다.

네임서버는 도메인을 등록한 곳과 무관하게 지정할 수 있다. 대행 기관이 기본으로 제공하는 네임서버를 그대로 쓸 수도 있고, 외부의 전문 서비스를 네임서버로 지정할 수도 있다. 외부 서비스로 네임서버를 옮기면 레코드 관리 도구, 응답 속도, 부가 기능이 달라진다. 도메인 등록과 네임서버 운영을 분리해 두면 각각을 독립적으로 교체할 수 있어 운영이 유연해진다.

네임서버를 어디에 두느냐는 성능과 안정성에 직접 영향을 준다. 전 세계에 분산된 네임서버는 사용자와 가까운 곳에서 응답해 조회 지연을 줄이고, 대규모 공격에도 견디는 여력을 갖는다. 반면 한 곳에 몰린 네임서버는 그 지점이 무너지면 도메인 전체가 응답을 멈춘다. 네임서버의 분산과 이중화는 눈에 띄지 않지만 서비스 가용성의 밑바탕을 이룬다.

위임이 계층을 잇는 방식

위임은 상위 계층이 하위 계층의 관리를 아래로 넘기는 일이다. 뿌리 계층은 최상위 도메인의 관리를 각 등록소의 네임서버에 위임하고, 그 등록소는 다시 개별 도메인의 관리를 소유자가 지정한 네임서버에 위임한다. 이렇게 관리 권한이 단계적으로 아래로 내려가므로, 어느 한 곳이 세상의 모든 이름을 알 필요가 없다. 각 계층은 자기 아래를 누가 관리하는지만 알면 된다.

이 위임은 상위 계층에 남는 특별한 레코드로 표현된다. 상위 네임서버는 하위 도메인의 질문에 직접 답하지 않고, 대신 그 도메인을 관리하는 네임서버가 어디인지를 가리키는 정보를 돌려준다. 질문하는 쪽은 이 안내를 따라 하위 네임서버로 옮겨 가 다시 질문한다. 위임은 곧 다음 단계로 가는 이정표이며, 조회는 이 이정표를 따라 계층을 내려간다.

위임에서 중요한 점은 상위와 하위의 네임서버 정보가 서로 맞아야 한다는 것이다. 상위 계층에 기록된 네임서버 목록과 실제로 존을 들고 있는 네임서버가 어긋나면, 조회는 엉뚱한 곳으로 안내되거나 답을 얻지 못한다. 네임서버를 바꿀 때 상위 계층의 위임 정보를 함께 갱신해야 하는 이유가 여기에 있다. 위임은 양쪽이 일치할 때만 온전히 동작한다.

위임 구조 덕분에 이름 조회는 놀라울 만큼 확장성이 좋다. 세상에 아무리 많은 도메인이 생겨도 각 계층은 자기 바로 아래만 관리하면 되므로, 어느 서버도 감당할 수 없을 만큼의 짐을 지지 않는다. 관리의 책임이 트리 전체에 고르게 분산되는 것이다. 이 분산된 위임이야말로 전 세계의 이름 조회가 한 곳의 병목 없이 돌아가게 하는 근본 설계다.

권위 있는 서버와 리졸버

이름 조회에 관여하는 서버는 크게 두 성격으로 나뉜다. 하나는 자신이 관리하는 도메인에 대해 최종적인 답을 내놓는 권위 있는 서버이고, 다른 하나는 사용자를 대신해 그 답을 찾아 나서는 리졸버다. 권위 있는 서버는 존의 원본을 들고 있고, 리졸버는 원본을 갖고 있지 않은 대신 계층을 따라가며 답을 수집한다. 이 둘의 역할을 구분하는 것이 조회 흐름을 이해하는 열쇠다.

사용자의 기기는 대개 직접 계층을 돌아다니지 않는다. 대신 가까운 리졸버에 질문을 맡기고, 리졸버가 뿌리부터 시작해 최상위 도메인, 다시 해당 도메인의 권위 있는 서버로 차례차례 물어 최종 답을 가져온다. 리졸버는 이렇게 모은 답을 사용자에게 돌려주는 동시에 일정 시간 저장해 둔다. 다음에 같은 질문이 오면 계층을 다시 도는 대신 저장된 답을 곧바로 내놓는다.

이 저장, 곧 캐싱이 이름 조회의 속도를 결정한다. 인기 있는 이름은 여러 리졸버에 답이 저장되어 있어 대부분의 질문이 계층 끝까지 가지 않고 중간에서 해결된다. 캐싱이 없다면 모든 질문이 매번 뿌리부터 시작해야 하고, 뿌리 서버는 감당할 수 없는 부하에 짓눌릴 것이다. 리졸버의 캐싱은 조회를 빠르게 하는 동시에 상위 계층의 짐을 덜어 주는 이중의 역할을 한다.

권위 있는 서버와 리졸버의 구분은 문제를 진단할 때도 유용하다. 어떤 이름이 잘못 응답할 때, 원본인 권위 있는 서버가 잘못된 값을 들고 있는 것인지, 아니면 리졸버에 옛 답이 저장되어 있는 것인지를 나누어 살펴야 한다. 권위 있는 서버에 직접 물어 답을 확인하면 원본의 상태를 알 수 있고, 그 답과 사용자가 받는 답이 다르면 중간의 캐싱이 원인임을 짐작할 수 있다.

이 구분은 책임의 소재를 나누는 데도 쓰인다. 권위 있는 서버는 도메인 소유자가 관리하는 영역이고, 리졸버는 대개 통신 사업자나 공용 서비스가 운영하는 영역이다. 소유자가 통제할 수 있는 것은 권위 있는 서버의 값까지이며, 리졸버에 저장된 옛 답은 소유자가 강제로 지울 수 없다. 그래서 변경이 곧바로 반영되지 않는 상황을 만나면, 그것이 소유자의 잘못이 아니라 통제 밖의 캐싱 때문인 경우가 많다. 어디까지가 자신의 손이 닿는 영역인지를 아는 것이 문제 해결의 출발점이다.

네임서버 변경과 그 여파

네임서버를 바꾸는 일은 도메인의 응답 주체를 통째로 옮기는 무거운 작업이다. 이 변경은 상위 계층의 위임 정보에 기록되므로, 바꾼 즉시 모두에게 반영되지 않고 상위 계층이 지정한 유효 기간에 따라 서서히 퍼진다. 그동안은 일부 조회가 옛 네임서버로, 일부가 새 네임서버로 향하는 과도기가 이어진다. 이 과도기를 무사히 넘기려면 준비가 필요하다.

가장 중요한 준비는 새 네임서버에 기존 레코드를 미리 그대로 옮겨 두는 것이다. 네임서버만 바꾸고 레코드를 옮기지 않으면, 조회가 새 네임서버로 향하는 순간 텅 빈 존을 만나 서비스가 끊긴다. 옛 네임서버와 새 네임서버가 같은 레코드를 들고 있으면, 조회가 어느 쪽으로 향하든 같은 답이 돌아와 과도기에도 서비스가 멀쩡하다. 두 네임서버의 내용을 먼저 일치시키는 것이 무중단 이전의 핵심이다.

네임서버 변경은 상위 계층의 유효 기간에 의존하므로 완전히 퍼지기까지 시간이 걸린다. 이 기간에는 옛 네임서버를 성급히 내려서는 안 된다. 아직 옛 네임서버로 향하는 조회가 남아 있는데 그 서버를 내리면, 그 조회들이 답을 얻지 못한다. 옛 네임서버는 변경이 완전히 퍼졌다고 확신할 수 있을 만큼 충분히 기다린 뒤에 내려야 안전하다.

네임서버를 옮길 때는 전자우편 같은 다른 서비스의 레코드도 함께 챙겨야 한다. 네임서버가 바뀌면 그 네임서버가 들고 있는 모든 레코드가 새 존으로 넘어가야 하는데, 웹 주소만 옮기고 전자우편 레코드를 빠뜨리면 메일이 조용히 끊긴다. 네임서버 변경은 웹만의 문제가 아니라 그 도메인에 걸린 모든 서비스를 동시에 옮기는 일이라는 점을 잊지 말아야 한다.

위임에서 흔한 실수

가장 흔한 실수는 상위 계층의 네임서버 지정과 실제 존의 네임서버 목록이 어긋나는 것이다. 존 안에도 그 도메인을 관리하는 네임서버 목록이 레코드로 담기는데, 이것이 상위 계층에 기록된 지정과 다르면 조회 도구가 경고를 내고 일부 환경에서 조회가 불안정해진다. 양쪽 목록을 항상 같게 유지하는 것이 위임의 기본 위생이다.

네임서버로 별칭을 가리키게 하는 것도 피해야 할 실수다. 네임서버를 지정하는 이름은 다른 이름을 대신 가리키는 별칭이 아니라 실제 주소를 갖는 이름이어야 한다. 네임서버 이름에 별칭을 걸면 규격에 어긋나 일부 조회가 실패한다. 네임서버는 반드시 최종 주소로 이어지는 온전한 이름으로 지정해야 한다.

위임한 하위 도메인의 네임서버가 응답하지 않는 상태를 방치하는 것도 문제를 부른다. 어떤 하위 도메인을 다른 네임서버에 위임해 두었는데 그 네임서버가 사라지거나 멈추면, 그 하위 도메인 전체가 답을 잃는다. 위임은 넘긴 것으로 끝나는 것이 아니라, 넘긴 곳이 계속 정상 응답하는지를 지켜봐야 하는 지속적인 책임을 남긴다.

위임 정보의 유효 기간을 지나치게 길게 둔 채로 네임서버를 자주 바꾸는 것도 곤란하다. 유효 기간이 길면 변경이 퍼지는 데 오래 걸려, 과도기가 길게 늘어지고 옛 정보가 오래 남는다. 네임서버 변경을 앞두고 있다면 미리 관련 유효 기간을 짧게 줄여 두어야 변경이 빠르게 반영된다.

위임이 만드는 신뢰의 사슬

위임은 관리 권한을 아래로 넘기는 일이지만, 동시에 신뢰를 아래로 넘기는 일이기도 하다. 상위 계층이 어떤 네임서버로 하위 도메인을 위임하면, 그 순간부터 상위는 하위의 답을 그 네임서버에 맡긴다. 조회하는 쪽은 상위의 안내를 믿고 하위 네임서버로 향하며, 그 네임서버의 답을 그 도메인의 진짜 답으로 받아들인다. 위임의 사슬은 곧 신뢰의 사슬이며, 이 사슬의 어느 고리가 어긋나거나 탈취되면 그 아래 전체가 위험에 빠진다.

이 신뢰가 순수하게 안내에만 기대고 있다는 점은 오랫동안 약점으로 지적되어 왔다. 중간의 누군가가 위임 안내나 응답을 가로채 조작하면, 조회하는 쪽은 가짜 네임서버나 가짜 주소를 진짜로 믿게 된다. 이 위조를 막기 위해 응답에 서명을 붙여 진위를 검증하는 확장이 도입되었으며, 이는 위임의 사슬에 암호적 신뢰를 덧입히는 시도다. 이 주제는 뒤의 보안 편에서 따로 다룬다.

위임의 사슬을 이해하면 도메인 관리 계정을 왜 그토록 강하게 지켜야 하는지도 분명해진다. 이 계정을 쥔 쪽은 위임의 방향을 바꿀 수 있고, 방향을 바꾼다는 것은 그 도메인에 걸린 모든 서비스의 목적지를 바꾼다는 뜻이다. 계정이 탈취되면 공격자는 네임서버를 자신의 것으로 바꿔 트래픽과 전자우편을 통째로 가로챌 수 있다. 위임의 정점에 있는 계정은 서비스에서 가장 민감한 열쇠다.

결국 네임서버와 위임은 이름 조회가 전 세계 어디서든 일관되게 동작하게 하는 뼈대다. 각 계층이 자기 아래만 관리하되 그 관리를 신뢰로 잇는 이 구조가, 어느 한 곳의 병목도 없이 거대한 이름 공간을 굴러가게 한다. 이렇게 네임서버와 위임의 구조, 변경의 절차, 흔한 실수, 그리고 그 위에 놓인 신뢰의 사슬까지 이해하면 도메인이 왜 지금처럼 안정적으로 응답하는지가 분명해진다. 다음 편은 이 구조 위에서 이름을 잘게 나누는 서브도메인 설계를 다룬다.