도메인을 등록했다면 그것은 아직 아무 곳도 가리키지 않는 빈 이름이다. 이 이름을 실제 서버와 서비스로 연결하는 일은 레코드라는 항목을 통해 이루어진다. 레코드는 이름 조회 체계가 응답으로 돌려주는 정보의 단위이며, 하나의 도메인 아래에는 용도가 다른 여러 종류의 레코드가 함께 놓인다. 어떤 레코드는 웹 주소를 가리키고, 어떤 레코드는 전자우편을 안내하며, 어떤 레코드는 다른 이름을 대신 가리킨다.
이번 편은 이 레코드들의 구조와 대표적인 종류를 정리한다. 레코드가 어떻게 구성되고 어디에 저장되는지, 주소를 가리키는 레코드는 어떤 것인지, 다른 이름을 가리키는 별칭은 어떻게 동작하는지, 전자우편과 부가 정보를 담는 레코드는 무엇인지, 그리고 이들을 실무에서 배치할 때 무엇을 주의해야 하는지를 차례로 짚는다. 레코드를 정확히 이해하면 도메인이 왜 지금처럼 동작하는지가 손에 잡힌다.
레코드의 구성과 존
하나의 레코드는 몇 가지 요소로 이루어진다. 어떤 이름에 대한 것인지를 나타내는 이름, 어떤 종류인지를 나타내는 유형, 실제 값이 담기는 데이터, 그리고 이 정보를 얼마나 오래 재사용해도 되는지를 나타내는 유효 기간이다. 예를 들어 www.example.com이 A 유형으로 203.0.113.10을 가리키고 그 유효 기간이 3600초라면, 이 네 요소가 하나의 레코드를 이룬다.
이 레코드들은 도메인 단위로 묶여 하나의 관리 구역에 모인다. 이 구역을 존이라고 부르며, 존은 한 도메인과 그 아래 이름들에 대한 레코드의 집합이다. 존을 관리하는 서버가 그 도메인에 대한 질문에 권위 있는 답을 내놓는다. 레코드를 편집한다는 것은 결국 이 존의 내용을 고치는 일이며, 대행 기관의 관리 화면은 이 존을 다루기 쉽게 감싼 도구에 지나지 않는다.
존을 텍스트 형태로 표현하면 각 레코드가 한 줄로 나열된다. 왼쪽에 이름, 유효 기간, 부류, 유형, 그리고 값이 순서대로 놓이는 형식이다. 관리 화면의 표는 이 한 줄을 항목별로 쪼개어 보여 주는 것이며, 안에서 벌어지는 일은 같다. 이 텍스트 형식을 한 번 이해해 두면 어떤 관리 도구를 쓰더라도 그 화면이 무엇을 편집하는지 헷갈리지 않는다.
유효 기간은 레코드마다 따로 설정된다. 자주 바뀌지 않는 레코드는 유효 기간을 길게 두어 조회 부담을 줄이고, 곧 바꿀 예정인 레코드는 짧게 두어 변경이 빨리 퍼지게 한다. 이 유효 기간의 의미와 활용은 뒤에서 전파를 다룰 때 자세히 살피지만, 지금은 모든 레코드가 각자의 수명을 갖는다는 점만 기억하면 된다.
주소를 가리키는 A와 AAAA
가장 기본이 되는 레코드는 이름을 숫자 주소로 잇는 것이다. A 레코드는 도메인 이름을 네 자리 숫자로 이루어진 주소에 연결하고, AAAA 레코드는 더 긴 새 방식의 주소에 연결한다. 브라우저가 어떤 이름의 서버에 접속하려면 결국 이 레코드로부터 숫자 주소를 얻어야 하므로, 웹 서비스에서 가장 먼저 갖추어야 할 레코드가 이것이다.
하나의 이름에 여러 개의 A 레코드를 둘 수 있다. 같은 이름에 여러 주소를 연결해 두면 조회할 때마다 다른 주소가 돌아오게 하여 부하를 나눌 수 있다. 이는 정교한 부하 분산은 아니지만, 여러 서버에 요청을 분산시키는 가장 단순한 방법으로 오래 쓰여 왔다. 주소 중 하나가 응답하지 않을 때 다른 주소로 넘어가는 여지도 이 구성에서 나온다.
새 방식의 주소를 위한 AAAA 레코드는 점점 더 중요해지고 있다. 기존 주소 공간이 고갈되면서 새 주소 체계가 확산되고 있으므로, 두 종류의 주소를 함께 제공하는 것이 안전하다. 다만 두 레코드를 모두 두었을 때 한쪽 경로가 제대로 동작하지 않으면 연결이 느려지거나 실패할 수 있으므로, 새 방식의 주소를 넣을 때는 그 경로가 실제로 서비스되는지 확인해야 한다.
도메인의 뿌리 이름, 그러니까 앞자리가 없는 이름에 대한 주소 지정은 특히 신경 써야 한다. 뿌리 이름에는 뒤에서 다룰 별칭 레코드를 그대로 쓸 수 없다는 제약이 있어, 여기에는 직접 주소를 가리키는 A 레코드를 두거나 대행 기관이 제공하는 특별한 기능을 써야 한다. 이 제약은 실무에서 자주 걸림돌이 되므로 미리 이해해 두는 편이 낫다.
다른 이름을 가리키는 CNAME
CNAME 레코드는 한 이름이 다른 이름을 대신 가리키게 하는 별칭이다. www.example.com을 example.com이나 외부 서비스의 이름으로 향하게 해 두면, 조회는 그 별칭을 따라가 최종 이름의 주소를 얻는다. 이 방식의 장점은 목적지의 주소가 바뀌어도 별칭은 그대로 두면 된다는 데 있다. 주소 대신 이름을 가리키므로 목적지의 주소 변경에 자동으로 따라간다.
별칭에는 중요한 제약이 있다. 한 이름에 CNAME이 있으면 그 이름에는 다른 유형의 레코드를 함께 둘 수 없다. 별칭은 그 이름의 모든 조회를 다른 이름으로 넘겨 버리기 때문에, 같은 이름에 전자우편 레코드나 다른 정보를 얹으려는 시도와 충돌한다. 그래서 도메인의 뿌리 이름에는 CNAME을 두기 어렵다. 뿌리에는 대개 다른 유형의 레코드가 함께 필요하기 때문이다.
이 제약을 우회하기 위해 여러 대행 기관은 뿌리 이름에서도 별칭처럼 동작하는 특별한 기능을 제공한다. 겉으로는 뿌리 이름을 다른 이름으로 가리키는 것처럼 보이지만, 실제로는 조회 시점에 목적지의 주소를 조회해 A 레코드로 응답해 주는 방식이다. 이름은 대행 기관마다 다르지만 원리는 같으며, 뿌리 이름을 외부 서비스로 연결할 때 유용하다.
별칭을 여러 단계로 이으면 조회가 여러 번 이어져 느려진다. 별칭이 다른 별칭을 가리키고 그것이 또 다른 별칭을 가리키는 사슬은 조회 지연을 키우고 관리도 복잡하게 만든다. 가능하면 별칭은 한 단계로 끝내고 최종 이름을 곧바로 가리키게 두는 것이 원칙이다. 편의를 위해 도입한 별칭이 오히려 성능을 갉아먹는 일을 피해야 한다.
전자우편을 위한 MX와 정보용 TXT
MX 레코드는 도메인으로 오는 전자우편을 어느 서버가 받을지를 지정한다. 웹 접속과 전자우편은 같은 도메인을 쓰더라도 서로 다른 레코드로 안내되므로, 웹 서버와 메일 서버는 얼마든지 다른 곳에 둘 수 있다. MX 레코드에는 우선순위 값이 함께 붙어, 값이 작은 서버가 먼저 시도되고 그 서버가 응답하지 않으면 다음 서버로 넘어간다.
전자우편을 다룰 때 MX만으로는 부족하다. 스팸과 위조를 막기 위해 발신을 인증하는 여러 정보가 필요한데, 이 정보들은 대개 TXT 레코드에 담긴다. TXT 레코드는 이름에 임의의 문자열을 붙일 수 있는 자유로운 레코드라, 발신 인증 정책이나 소유권 증명 같은 다양한 용도로 쓰인다. 전자우편 인증의 세 축은 뒤의 편에서 자세히 다룬다.
TXT 레코드는 도메인 소유를 증명하는 데도 널리 쓰인다. 외부 서비스가 이 도메인이 정말 당신 것인지 확인할 때, 지정한 문자열을 TXT 레코드로 넣으라고 요구하는 방식이 흔하다. 그 문자열이 조회로 확인되면 소유가 증명된다. 도메인의 관리 권한을 가진 사람만이 레코드를 넣을 수 있다는 사실을 신뢰의 근거로 삼는 것이다.
이 밖에도 서비스의 위치나 정책을 지정하는 여러 유형의 레코드가 있다. 특정 서비스가 어느 서버의 어느 포트에서 제공되는지를 알리는 레코드, 이름 조회 자체를 다른 방식으로 여는 레코드 등이 그것이다. 모든 유형을 외울 필요는 없지만, 필요할 때 어떤 유형의 레코드가 그 일을 담당하는지를 찾아볼 수 있을 만큼의 지도는 머릿속에 두는 것이 좋다.
레코드의 종류가 이렇게 나뉘어 있는 이유는 하나의 이름에 걸리는 서비스가 여러 갈래이기 때문이다. 같은 도메인이라도 웹을 여는 경로와 전자우편을 받는 경로, 소유를 증명하는 경로가 서로 독립적으로 관리되어야 한다. 유형이 이 갈래를 구분해 주므로, 한 서비스의 설정을 바꾸어도 다른 서비스가 영향을 받지 않는다. 웹 서버를 옮긴다고 전자우편이 끊기지 않고, 소유 증명 문자열을 바꾸어도 웹 접속이 멀쩡한 것은 이 구분 덕분이다. 레코드의 유형 체계는 결국 한 이름 아래의 여러 책임을 깔끔하게 나누기 위한 장치다.
레코드를 배치할 때의 판단
레코드를 배치할 때 가장 먼저 정할 것은 어떤 이름에 어떤 서비스를 걸 것인가다. 뿌리 이름과 앞자리가 붙은 이름 중 무엇을 대표 주소로 삼을지, 전자우편은 어느 서버로 받을지, 부속 서비스는 어떤 서브도메인에 둘지를 미리 정해 두면 레코드 구조가 정돈된다. 즉흥적으로 하나씩 추가하다 보면 나중에 서로 충돌하는 레코드가 쌓인다.
레코드를 편집할 때는 유효 기간을 의식해야 한다. 곧 바꿀 예정인 레코드라면 미리 유효 기간을 짧게 줄여 두어야, 실제로 값을 바꾼 뒤 그 변경이 빠르게 퍼진다. 유효 기간을 길게 둔 채로 값을 바꾸면 옛 정보가 한동안 남아 일부 사용자는 옛 주소로, 일부는 새 주소로 흩어지는 어정쩡한 상태가 이어진다. 이 조절은 무중단 전환의 핵심이다.
실무에서 자주 겪는 실수는 별칭의 제약을 잊는 것이다. 뿌리 이름에 별칭을 넣으려다 실패하거나, 별칭이 걸린 이름에 다른 레코드를 얹으려다 충돌하는 경우가 흔하다. 이름 하나에는 그 이름이 어떤 성격의 레코드를 이미 갖고 있는지를 먼저 확인하고 손대야 한다. 레코드 사이의 충돌 규칙을 알고 있으면 대부분의 오류를 미리 피할 수 있다.
레코드를 바꾼 뒤에는 반드시 실제 조회로 확인해야 한다. 관리 화면에 저장되었다는 것과 그 값이 실제로 조회에 응답한다는 것은 다르다. 값을 바꾼 직후에는 옛 정보가 남아 있을 수 있으므로, 유효 기간이 지난 뒤 조회 도구로 응답을 직접 확인하는 습관이 필요하다. 관리 화면에 저장되었다는 것과 그 값이 실제로 조회에 응답한다는 것은 다르다.
레코드가 조회로 이어지는 흐름
레코드가 존에 놓여 있다고 해서 곧바로 모든 사용자에게 보이는 것은 아니다. 사용자의 요청은 여러 단계의 서버를 거쳐 존에 도달하고, 그 과정에서 각 단계는 응답을 일정 시간 저장해 둔다. 그래서 방금 바꾼 레코드가 어떤 사용자에게는 새 값으로, 어떤 사용자에게는 옛 값으로 보이는 시차가 생긴다. 레코드를 편집하는 사람은 이 저장과 재사용의 흐름을 항상 염두에 두어야 한다.
이 흐름을 이해하면 레코드 변경의 순서를 어떻게 짜야 하는지가 분명해진다. 서비스를 옮길 때는 새 서버를 먼저 준비해 두 곳이 함께 응답하게 만든 뒤, 레코드를 바꾸고, 옛 정보가 완전히 사라질 때까지 기다린 다음 옛 서버를 내린다. 순서를 거꾸로 하면 옛 정보를 붙든 사용자가 이미 사라진 서버로 향하게 되어 접속이 끊긴다. 레코드는 값 하나를 바꾸는 일이지만 그 여파는 시간에 걸쳐 퍼진다.
조회 도구로 레코드를 직접 확인하는 습관은 이 시차를 다루는 가장 확실한 방법이다. 특정 유형의 레코드가 어떤 값으로 응답하는지, 유효 기간이 얼마나 남았는지를 눈으로 확인하면, 지금 변경이 어디까지 퍼졌는지를 가늠할 수 있다. 관리 화면만 믿고 확인을 건너뛰면, 자신에게는 이미 새 값으로 보여도 다른 지역의 사용자에게는 여전히 옛 값이 남아 있는 상황을 놓친다.
레코드는 결국 도메인이라는 이름에 여러 서비스를 나누어 거는 배선판과 같다. 웹은 주소 레코드로, 전자우편은 전용 레코드로, 소유 증명과 정책은 문자열 레코드로 각기 다른 선을 잇는다. 이 배선을 어떻게 정돈하느냐가 도메인 운영의 질을 좌우한다. 선이 뒤엉키면 사소한 변경 하나가 엉뚱한 서비스를 끊고, 잘 정돈되어 있으면 각 서비스를 독립적으로 손볼 수 있다. 이렇게 레코드의 구조와 종류, 배치의 판단, 그리고 조회로 퍼지는 흐름까지 이해하면 도메인은 비로소 살아 있는 이름이 된다. 다음 편은 이 레코드들을 실제로 응답하는 네임서버와 위임을 다룬다.