[웹 기반기술 49] DNS - 흔한 DNS 문제 진단

이름과 관련된 문제는 유난히 진단하기 까다롭다. 원인이 여러 계층에 흩어져 있고, 캐시 때문에 사람마다 보는 증상이 다르며, 방금 바꾼 설정이 아직 퍼지지 않아 옳게 고쳐도 낫지 않은 것처럼 보이기 때문이다. 그래서 이름 문제는 감으로 이것저것 바꾸기보다, 어느 계층에서 무엇이 어긋났는지를 차근차근 좁혀 가는 체계적인 진단이 필요하다.

이번 편은 흔한 이름 관련 문제의 진단을 다룬다. 진단의 출발점을 어디에 두어야 하는지, 조회 도구로 무엇을 확인하는지, 캐시로 인한 시차를 어떻게 다루는지, 레코드 설정 오류에는 어떤 유형이 있는지, 위임과 네임서버 문제는 어떻게 짚는지, 보안 연결과 인증서 오류는 어떻게 나누는지, 그리고 진단의 원칙은 무엇인지를 차례로 짚는다. 계층을 나누어 좁혀 가면 대부분의 문제는 원인이 드러난다.

진단의 출발점은 계층 분리

이름 관련 문제를 만나면 가장 먼저 할 일은 문제가 어느 계층에 있는지를 나누는 것이다. 이름을 주소로 바꾸는 조회 단계가 잘못된 것인지, 조회는 되는데 그 주소의 서버가 응답하지 않는 것인지, 서버는 응답하는데 보안 연결이 성립하지 않는 것인지를 구분해야 한다. 이 셋은 증상이 비슷해 보여도 원인과 해결이 전혀 다르다.

계층을 나누는 간단한 방법은 각 단계를 따로 시험하는 것이다. 이름이 주소로 바뀌는지를 조회 도구로 확인하고, 그 주소의 서버에 직접 연결이 되는지를 확인하고, 보안 연결이 맺어지는지를 확인한다. 어느 단계에서 처음 실패하는지를 찾으면 문제의 계층이 특정된다. 처음 실패하는 지점보다 뒤의 계층을 아무리 살펴도 소용이 없다.

증상만으로 계층을 넘겨짚는 것이 흔한 실수다. 사이트가 열리지 않는다는 하나의 증상 뒤에는 이름 조회 실패, 서버 다운, 인증서 만료, 잘못된 안내 등 전혀 다른 원인이 있을 수 있다. 증상에서 곧바로 원인을 단정하고 엉뚱한 곳을 고치면 시간만 허비한다. 증상은 출발점일 뿐이고, 계층을 나누어 실제 실패 지점을 찾는 것이 진단의 본체다.

계층을 나눌 때는 문제가 나에게만 나타나는지 모두에게 나타나는지도 구분해야 한다. 나에게만 보이는 문제라면 내 기기나 내가 쓰는 조회 서비스의 캐시가 원인일 수 있고, 모두에게 보이는 문제라면 원본 설정 자체가 잘못된 것이다. 이 구분을 하지 않으면, 내 환경의 일시적 문제를 원본의 문제로 오인하거나 그 반대의 실수를 저지른다. 범위의 확인이 계층 분리의 일부다.

조회 도구로 확인하기

이름이 주소로 올바로 바뀌는지는 조회 도구로 직접 확인한다. 특정 이름의 특정 유형 레코드가 어떤 값으로 응답하는지를 조회하면, 관리 화면에 무엇을 저장했든 실제로 무엇이 응답되는지를 눈으로 볼 수 있다. 관리 화면에 저장된 값과 실제 응답되는 값이 다를 수 있으므로, 진단은 항상 실제 응답을 확인하는 데서 시작해야 한다.

조회 도구로 원본 네임서버에 직접 물어볼 수도 있다. 중간의 캐시를 거치지 않고 그 도메인의 권위 있는 서버에 직접 조회하면, 원본이 지금 어떤 값을 들고 있는지가 캐시의 방해 없이 드러난다. 이 값이 잘못되어 있으면 문제는 원본 설정에 있고, 원본은 옳은데 사용자가 다른 값을 받는다면 문제는 중간의 캐시에 있다. 원본과 캐시를 나누어 보는 것이 조회 진단의 핵심이다.

조회 도구는 응답과 함께 남은 유효 기간도 보여 준다. 이 값을 보면 지금 받은 답이 캐시에 얼마나 더 남아 있을지를 알 수 있어, 방금 바꾼 값이 언제쯤 반영될지를 가늠할 수 있다. 유효 기간이 아직 많이 남은 옛 답을 받고 있다면, 그것이 만료되기 전에는 새 값이 보이지 않는다. 조회 결과의 유효 기간은 기다림의 길이를 알려 주는 지표다.

여러 지역의 조회 서비스에서 같은 이름을 조회해 비교하는 것도 유용하다. 지역마다 캐시된 값이 다르면 전환이 아직 완전히 퍼지지 않은 것이고, 모든 지역이 같은 값을 응답하면 전파가 끝난 것이다. 이 비교로 전파의 진행 상태를 파악할 수 있다. 한 곳에서만 조회하고 전체를 판단하면, 자신이 보는 값이 전 세계의 값이라고 착각한다.

캐시로 인한 시차 문제

가장 흔한 오진은 캐시로 인한 시차를 설정 오류로 오해하는 것이다. 레코드를 옳게 바꾸었는데도 여전히 옛 값이 보이면 설정이 잘못된 줄 알고 다시 손대게 되는데, 실제로는 캐시된 옛 답이 아직 만료되지 않았을 뿐인 경우가 많다. 이때 설정을 계속 바꾸면 문제를 더 꼬이게 만든다. 옳게 고친 뒤에는 기다림이 필요하다.

캐시로 인한 시차인지 확인하려면 원본 네임서버에 직접 조회해 본다. 원본이 새 값을 응답하는데 사용자가 옛 값을 받고 있다면, 그것은 설정 오류가 아니라 캐시 시차다. 이 경우 할 일은 설정을 더 바꾸는 것이 아니라, 옛 답의 유효 기간이 지나기를 기다리는 것이다. 원본이 옳다는 것을 확인하면 불필요한 재수정을 멈출 수 있다.

자신의 기기나 조회 서비스의 캐시가 원인일 때는 그 캐시를 비우면 즉시 새 값을 볼 수 있다. 다만 이것은 내 환경만 새로 고치는 것이지 전 세계의 캐시를 비우는 것이 아니다. 내 기기에서 새 값이 보인다고 모두가 새 값을 보는 것은 아니므로, 캐시를 비운 뒤의 결과를 전체 상태로 오해하지 말아야 한다. 내 환경의 확인과 전체의 전파는 다른 문제다.

변경을 앞두고 유효 기간을 미리 낮추어 두는 습관이 이 시차 문제를 줄인다. 유효 기간이 짧으면 옛 답이 빨리 만료되어 전파가 빠르고, 문제가 생겨 되돌릴 때도 빠르다. 진단의 관점에서 보면, 짧은 유효 기간은 변경의 효과를 빨리 확인하게 해 주어 진단을 쉽게 만든다. 캐시 시차로 인한 혼란은 대부분 사전 준비로 완화할 수 있다.

레코드 설정 오류의 유형

레코드 설정 오류에는 반복되는 유형이 있다. 가장 흔한 것은 값의 오타나 형식 오류다. 주소를 잘못 적거나, 이름 끝의 점을 빠뜨려 상대적인 이름으로 해석되게 하거나, 값에 허용되지 않은 문자를 넣는 실수다. 이런 오류는 조회 도구로 실제 응답을 보면 대개 눈에 띄므로, 저장한 값과 응답된 값을 대조하는 것이 첫 확인이다.

두 번째 유형은 레코드 사이의 충돌이다. 한 이름에 별칭이 걸려 있으면 그 이름에는 다른 유형의 레코드를 함께 둘 수 없는데, 이 규칙을 어겨 충돌이 생기는 경우다. 특히 뿌리 이름에 별칭을 걸려다 실패하거나, 별칭이 있는 이름에 다른 레코드를 얹으려다 어긋나는 일이 잦다. 이름 하나에 어떤 성격의 레코드가 이미 있는지를 확인하고 손대야 한다.

세 번째 유형은 필요한 레코드가 아예 없는 것이다. 웹은 되는데 전자우편이 안 되면 전자우편 안내 레코드가 없거나 잘못된 것이고, 특정 하위 이름만 안 되면 그 이름의 레코드가 없는 것이다. 무엇이 되고 무엇이 안 되는지를 나누어 보면, 어떤 레코드가 빠졌는지가 좁혀진다. 되는 것과 안 되는 것의 경계가 빠진 레코드를 가리킨다.

네 번째 유형은 별칭이 여러 단계로 이어지거나 순환하는 것이다. 별칭이 다른 별칭을 가리키고 그것이 또 다른 별칭을 가리키면 조회가 느려지고, 별칭이 결국 자기 자신을 가리키면 조회가 답을 찾지 못한다. 별칭을 쓸 때는 그것이 몇 단계를 거쳐 최종 주소에 닿는지를 확인하고, 가능하면 한 단계로 끝내야 한다. 별칭의 사슬은 짧을수록 안전하다.

위임과 네임서버 문제

조회 자체가 아예 실패한다면 위임이나 네임서버 문제일 수 있다. 상위 계층에 기록된 네임서버 지정과 실제 존을 들고 있는 네임서버가 어긋나면, 조회가 엉뚱한 곳으로 안내되거나 답을 얻지 못한다. 조회 도구로 상위 계층이 어떤 네임서버를 가리키는지, 그 네임서버가 실제로 응답하는지를 확인하면 이 어긋남이 드러난다.

네임서버가 응답하지 않는 것도 흔한 원인이다. 지정된 네임서버 중 일부가 멈추었거나 사라졌으면, 그 서버로 향한 조회가 실패한다. 여러 네임서버가 지정되어 있으면 살아 있는 서버가 답을 대신하지만, 모든 네임서버가 응답하지 못하면 도메인 전체가 조회 불가가 된다. 각 네임서버가 개별적으로 응답하는지를 하나씩 확인해야 한다.

존 안의 네임서버 목록과 상위 계층의 지정이 다른 것도 문제를 일으킨다. 이 둘이 어긋나면 일부 조회 환경에서 불안정한 응답이 나오고, 진단 도구가 경고를 낸다. 양쪽 목록을 같게 맞추는 것이 이 문제의 해결이다. 네임서버를 바꾼 뒤 한쪽만 갱신하고 다른 쪽을 빠뜨리면 이런 불일치가 생기므로, 변경 때 양쪽을 함께 맞추어야 한다.

위임한 하위 이름이 응답하지 않는 경우도 있다. 어떤 하위 이름을 다른 네임서버에 위임해 두었는데 그 네임서버가 사라졌으면, 그 하위 이름만 조회에 실패한다. 대표 이름은 되는데 특정 하위 이름만 안 된다면, 그 하위 이름의 위임이 어디로 향하고 그곳이 응답하는지를 확인해야 한다. 위임은 넘긴 뒤에도 그곳의 응답을 지켜봐야 하는 책임을 남긴다.

보안 연결과 인증서 오류

이름 조회와 서버 연결이 정상인데 보안 연결만 실패한다면 인증서 문제일 가능성이 높다. 인증서 오류는 몇 가지로 나뉘는데, 각각 원인과 해결이 다르므로 오류가 정확히 무엇을 가리키는지를 읽어야 한다. 만료, 이름 불일치, 사슬 누락, 신뢰받지 못하는 서명이 대표적인 유형이다.

만료는 인증서의 유효 기간이 지난 것이다. 자동 갱신이 실패해 옛 인증서가 그대로 남았거나, 갱신은 되었는데 서버가 새 인증서를 다시 읽어 들이지 않은 경우다. 서버가 실제로 제시하는 인증서의 만료일을 확인하면 어느 쪽인지 드러난다. 파일은 갱신되었는데 서버가 옛 것을 제시한다면, 서버를 다시 읽어들이게 하는 것이 해결이다.

이름 불일치는 인증서에 담긴 이름이 접속한 이름과 다른 것이다. 인증서가 대표 이름만 담고 있는데 앞자리 없는 이름으로 접속하거나, 포괄 이름의 범위를 벗어난 하위 이름으로 접속할 때 생긴다. 정규화에서 다루는 모든 이름 형태가 인증서에 함께 담겨 있는지를 확인해야 한다. 인증서의 이름 범위와 실제 접속하는 이름의 범위를 맞추는 것이 해결이다.

사슬 누락은 서버가 중간 인증서를 함께 제시하지 않아 신뢰의 사슬이 끊긴 것이다. 서버 인증서 자체는 올바른데도 일부 브라우저에서 신뢰가 성립하지 않는다면 이 누락을 의심해야 한다. 서버가 제시하는 인증서 사슬을 확인해 중간 인증서가 빠졌는지를 보고, 빠졌으면 그것을 함께 설치하면 된다. 이렇게 계층 분리, 조회 도구 확인, 캐시 시차, 레코드 오류, 위임과 네임서버, 그리고 인증서 오류까지 나누어 보면 대부분의 문제는 원인이 특정된다. 마지막 진단의 원칙은 이어서 정리한다.

진단의 원칙

진단의 첫 번째 원칙은 한 번에 하나씩 바꾸는 것이다. 문제가 급하다고 여러 설정을 한꺼번에 바꾸면, 그중 무엇이 효과가 있었는지 알 수 없고 새 문제까지 더한다. 하나를 바꾸고 그 효과를 확인한 뒤 다음으로 넘어가면, 각 변경의 인과가 분명해진다. 특히 전파를 동반하는 변경은 효과가 즉시 나타나지 않으므로, 여러 변경을 겹치면 인과가 완전히 뒤엉킨다.

두 번째 원칙은 원본을 기준으로 판단하는 것이다. 사용자가 보는 증상은 캐시에 좌우되어 흔들리지만, 원본 네임서버가 응답하는 값은 흔들리지 않는다. 원본이 옳은지를 먼저 확정하고, 그 위에서 캐시로 인한 시차를 따로 다루면 진단이 안정된다. 흔들리는 증상만 쫓으면 원인에 닿지 못한다. 원본이라는 고정점을 잡는 것이 진단의 축이다.

세 번째 원칙은 기다림을 진단의 일부로 받아들이는 것이다. 옳게 고친 변경이 아직 퍼지지 않아 낫지 않은 것처럼 보이는 상태는 오류가 아니라 정상적인 전파 과정이다. 이때 필요한 것은 추가 수정이 아니라 유효 기간만큼의 기다림이다. 조급함이 옳은 수정을 뒤엎게 만드는 것을 경계해야 한다. 언제까지 기다려야 하는지는 조회 결과의 유효 기간이 알려 준다.

마지막 원칙은 변경 전에 현황을 기록해 두는 것이다. 손대기 전의 상태를 기록해 두면, 무엇을 바꾸었는지 추적할 수 있고 문제가 생겨도 되돌릴 근거가 된다. 기록 없이 즉흥적으로 바꾸다 보면 원래 상태를 잊어 수습이 어려워진다. 진단은 무언가를 바꾸는 일이지만, 그 바탕에는 바꾸기 전의 상태를 아는 것이 있다. 이렇게 계층을 나누고, 원본을 기준으로 삼고, 기다림을 받아들이고, 현황을 기록하는 원칙을 지키면 이름 문제는 감이 아니라 논리로 풀린다. 다음 편은 이 모든 것의 바탕에 놓인 이름 조회의 보안을 다룬다.