네임서버구축 처음부터 안전하게 하는 방법

얼마 전 사이트 이전을 돕다가 웹서버는 정상인데 접속이 끊긴 사례를 봤습니다. 새 서버의 IP는 맞았지만 권한 네임서버 두 대 중 한 대에 예전 주소가 남아 있었습니다. 이런 장애는 서버 사양을 올려도 해결되지 않습니다. 네임서버구축은 DNS 레코드를 입력하는 일보다, 어느 서버가 최종 답을 내는지와 변경이 어떻게 전파되는지를 관리하는 일이 더 큽니다.

직접 운영할 이유부터 계산한다

도메인 몇 개에 웹사이트와 메일만 연결한다면 등록업체나 호스팅업체의 관리형 DNS로 충분한 경우가 많습니다. 월 방문자가 늘었다는 이유만으로 권한 네임서버를 직접 세울 필요는 없습니다. DNS 서버가 받는 질의량은 웹페이지 조회 수와 일대일로 늘지 않습니다. 재귀 DNS의 캐시와 레코드의 TTL이 중간에서 질의를 줄여 줍니다.

직접 운영이 필요한 쪽은 여러 도메인의 변경을 자체 절차로 통제해야 하거나, 내부 시스템과 연동해 레코드를 자주 생성하는 경우입니다. 대신 운영 책임도 따라옵니다. 네임서버가 멈추면 웹서버가 살아 있어도 새로 이름을 찾는 이용자는 접속하지 못할 수 있습니다. 소규모 사이트라면 저렴한 관리형 DNS를 쓰고, 서버 이전 절차와 백업에 시간을 쓰는 편이 실익이 큽니다.

두 대를 세우고 권한 범위를 맞춘다

직접 구축한다면 권한 네임서버를 최소 두 대 준비합니다. 같은 VPS 안에서 프로세스만 둘로 나누면 호스트 장애를 견디지 못합니다. 가능하면 서로 다른 물리 호스트와 네트워크에 두고, 주 서버에서 보조 서버로 존 데이터를 복제합니다. 작은 사이트라면 고사양 장비보다 서로 독립된 저가 인스턴스 두 대가 더 합리적일 수 있습니다. 실제 메모리와 CPU 사용량은 질의량과 소프트웨어 구성에 따라 확인하면 됩니다.

등록업체에 지정한 NS 정보와 각 네임서버가 응답하는 존의 NS 정보는 일치시켜야 합니다. 네임서버 이름이 운영할 도메인 안에 있다면 등록업체에 해당 이름의 IP도 등록해야 하는 경우가 있습니다. 이를 글루 레코드라고 합니다. 이 단계가 빠지면 이름을 찾기 위해 다시 그 이름을 찾아야 하는 상황이 생깁니다. IPv6 주소를 등록했다면 해당 주소에서도 실제로 응답하는지 확인합니다.

존 파일에는 SOA, NS, 웹서버 주소 레코드, 메일을 쓴다면 MX와 관련 주소 레코드를 넣습니다. 보조 서버가 변경을 알아차리도록 SOA 일련번호를 변경 때마다 올려야 합니다. 날짜 형식을 쓰더라도 같은 날 여러 번 수정할 수 있으니 뒤에 순번을 붙여 관리하는 편이 편합니다. 주 서버의 존 전송은 보조 서버의 주소로 제한하고, 가능하면 TSIG로 전송 요청을 인증합니다.

공개 전에 질의 경로를 직접 확인한다

권한 네임서버는 자신이 맡은 존에 답하는 역할만 하게 둡니다. 외부 사용자의 재귀 질의를 허용하면 엉뚱한 도메인의 조회 요청까지 처리하게 되고, 증폭 공격에 악용될 여지도 생깁니다. 방화벽에서는 UDP 53번과 TCP 53번을 모두 확인합니다. 큰 응답이나 일부 재시도 경로에서는 TCP도 필요합니다. 존 전송과 관리용 접속은 필요한 상대에게만 열어 둡니다.

등록업체의 네임서버 설정을 바꾸기 전에 두 서버 각각에 직접 질의해 봅니다. 같은 레코드가 같은 값으로 나오는지, SOA 일련번호가 같은지, 존재하지 않는 이름에는 적절한 부정 응답이 오는지 확인합니다. 그다음 상위 DNS에 등록된 NS와 글루 정보가 의도한 값인지 확인합니다. 한 서버에서만 맞는 답이 나오면 이용자마다 접속 결과가 달라질 수 있습니다. 이 상태로 전환하는 것은 피해야 합니다.

DNSSEC을 사용 중이라면 확인 항목이 하나 더 늘어납니다. 등록업체의 DS 정보와 새 네임서버의 서명 키가 맞지 않으면, 레코드 자체가 정확해도 검증하는 재귀 DNS에서 실패할 수 있습니다. 기존 DNSSEC 구성을 그대로 옮길지, 절차에 따라 DS를 변경할지 먼저 결정하고 전환 순서를 잡아야 합니다.

이전과 장애 복구는 TTL보다 기록이 중요하다

서버 이전 전에는 기존 TTL을 확인합니다. 예를 들어 현재 TTL이 3600초라면 이전 하루쯤 전에 300초로 낮춰 두면 변경 시 캐시가 오래 남을 가능성을 줄일 수 있습니다. 다만 이미 캐시된 값은 그때 받은 TTL이 끝날 때까지 남습니다. 등록업체에서 NS를 바꾸는 작업도 개별 레코드의 TTL만으로 전환 시간을 단정할 수 없습니다. 기존 네임서버는 새 경로가 안정된 뒤에 내리는 편이 안전합니다.

장애가 나면 웹서버부터 재시작하기 전에 이름 조회 경로를 나눠 봅니다. 권한 네임서버 두 대가 모두 응답하는지, 상위 DNS의 위임이 맞는지, 글루의 IP가 현재 서버와 같은지, DNSSEC 검증에서만 실패하는지 차례로 확인합니다. 특정 이용자만 옛 주소로 간다면 캐시가 남았는지도 봅니다. 이 순서를 기록해 두면 장애 중에 설정을 무작정 바꾸는 일을 줄일 수 있습니다.

백업에는 존 파일만 넣지 않습니다. 서버 설정, 접근 제한, TSIG 키, DNSSEC을 쓴다면 서명 키와 복구 절차도 함께 챙깁니다. 키는 존 파일과 접근 권한을 분리해 보관하고, 복원한 서버가 실제로 같은 답을 내는지 가끔 시험해야 합니다. 네임서버는 평소 자원 사용량이 작아 눈에 잘 띄지 않지만, 한번 틀어지면 사이트 전체가 멈춘 것처럼 보입니다. 저는 장비 비용보다 두 서버의 응답 일치와 복구 연습에 먼저 시간을 씁니다.