○웹살림
← 모든 기록
DNS TTL 변경 후 전파 상태를 dig로 확인하는 방법 대표 이미지
웹 운영

DNS TTL 변경 후 전파 상태를 dig로 확인하는 방법

dig 명령어로 DNS 변경 사항이 전파되었는지 확인하는 실전 가이드입니다. TTL을 미리 낮추고 dig로 확인하는 방법을 배웁니다.

글 수정

DNS 변경 후 전파가 완료되었는지 확인하려면 dig 명령어가 가장 확실한 도구입니다. dig는 지정한 DNS 서버에 직접 쿼리를 보내 현재 레코드와 TTL 값을 즉시 보여줍니다. 이 글에서는 TTL을 미리 낮추는 방법과 dig로 전파 상태를 확인하는 절차를 함께 설명합니다.

DNS TTL이 전파에 미치는 영향 이해하기

DNS를 운영하다 보면 TTL이라는 값을 자주 만납니다. TTL은 Time to Live의 약자로, DNS 레코드가 캐시에 얼마나 오래 남아 있을지를 초 단위로 정합니다. TTL(Time to Live)은 DNS 레코드가 캐시되는 시간을 결정하며, 일반적으로 300초에서 86,400초 사이입니다. 캐시가 유지되는 동안에는 권위 있는 DNS 서버의 변경 사항이 반영되지 않으므로, TTL이 길수록 변경 전파가 오래 걸립니다. TTL은 DNS 전파에 직접적인 영향을 미칩니다. 짧은 TTL은 빠른 DNS 전파를 만들고, 긴 TTL은 느린 DNS 전파를 만듭니다. DNS 레코드를 자주 변경해야 하는 상황이라면 TTL을 평소에도 적절히 낮게 유지하는 편이 유리합니다.

레코드 유형에 따라 권장 TTL도 다릅니다. A/AAAA 레코드에는 360014400초(14시간)의 TTL이 권장됩니다. MX 레코드에는 4320086400초(1224시간)의 TTL이 권장됩니다. 메일 서버의 경우 변경 빈도가 낮고 안정성이 중요하기 때문에 상대적으로 긴 TTL을 사용하는 것이 일반적입니다. 하지만 변경을 앞두고 있다면 사전에 TTL을 낮추어야 합니다. 서로 다른 DNS 레코드 유형에는 서로 다른 TTL 값을 설정해야 합니다. 예를 들어 웹 서버를 이전하면서 A 레코드를 변경할 계획이라면, A 레코드의 TTL을 미리 낮추고 MX 레코드는 기존 값을 유지할 수 있습니다.

변경 전 TTL을 낮추는 사전 준비

DNS 변경을 계획했다면, 변경 작업 2448시간 전에 TTL을 300초로 낮추는 것이 좋습니다. 전파 시간을 최소화하려면 변경 계획 2448시간 전에 TTL을 300초로 낮추어야 합니다. 이렇게 미리 낮춰 두면 변경 시점에 기존 캐시가 대부분 만료된 상태가 되어, 새 레코드가 빠르게 전파됩니다. 만약 TTL 필드를 비워 두면 DNS 서버의 기본값이 적용되는데, 이 값은 일반적으로 약 2448시간입니다. TTL 필드에 아무것도 입력하지 않으면 DNS 서버에서 기본적으로 정의한 TTL이 적용되며, 일반적으로 약 2448시간입니다. 따라서 필드 값을 비워 두고 변경하면 예상보다 훨씬 오래 기다려야 할 수 있습니다.

TTL을 낮출 때는 너무 낮은 값도 주의해야 합니다. DNS 레코드에 설정할 수 있는 가장 낮은 TTL은 1초입니다. 1초로 설정하면 매초마다 쿼리가 발생하여 부하가 커질 수 있으므로, 평상시에는 300초에서 3600초 사이를 권장합니다. 다만 이 숫자는 절대 기준이 아니라 권장 범위입니다. 실제 운영 환경에서 필요한 캐시 성능과 변경 빈도를 함께 고려하세요.

dig 명령어로 특정 DNS 서버 조회하기

dig는 DNS 질의를 보내고 응답을 확인하는 명령어입니다. 운영체제의 터미널에서 dig 뒤에 질의할 도메인과 레코드 유형을 입력합니다. 특정 DNS 서버를 지정하려면 도메인 앞에 @서버주소를 붙입니다. 예를 들어 구글 DNS 8.8.8.8에 example.com의 A 레코드를 질의하려면 다음과 같이 입력합니다.

dig @8.8.8.8 example.com A

이 명령은 8.8.8.8이라는 지정 DNS 서버에 example.com의 A 레코드를 직접 물어봅니다. 기본적인 dig 명령은 시스템에 설정된 기본 DNS 서버를 사용합니다. 특정 DNS 서버를 직접 지정하는 이유는, 로컬 캐시가 아닌 해당 서버의 현재 상태를 확인하기 위해서입니다. 여러 DNS 서버를 번갈아 질의하면 전파가 서버마다 어떻게 진행되고 있는지 비교할 수 있습니다.

예를 들어 다음 명령을 순서대로 실행해 보세요.

dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

첫 번째는 구글 DNS, 두 번째는 클라우드플레어 DNS를 사용합니다. 두 응답이 서로 다른 IP 주소를 알려 준다면, 아직 일부 서버에는 이전 레코드가 남아 있다고 볼 수 있습니다. 반대로 두 응답의 IP 주소가 같다면 해당 서버까지는 새 레코드가 전파된 상태입니다.

응답의 TTL 값으로 캐시 만료 여부 확인하기

dig의 응답에서 두 번째 열은 TTL 값입니다. 이 값이 작을수록 캐시 수명이 짧다는 뜻입니다. 변경 전에 TTL을 300초로 낮췄다면, dig 응답의 TTL 값도 300초로 표시되는지 확인하세요. 응답의 TTL 값이 300초라면 캐시가 곧 만료될 예정이므로, 새 레코드가 반영될 때까지 기다렸다가 다시 질의하면 됩니다. 만약 응답의 TTL 값이 86400과 같은 큰 값으로 나온다면, 질의한 DNS 서버가 아직 이전 설정을 캐시하고 있을 가능성이 높습니다.

TTL 값은 질의한 서버의 캐시 상태에 따라 달라집니다. 동일한 도메인을 여러 DNS 서버에 질의했을 때 TTL 값이 서로 다르다면, 그만큼 전파 진행 상태가 서버마다 다르다는 뜻입니다. 이때는 TTL이 낮은 서버는 이미 새 설정을 인식하고 있고, TTL이 높은 서버는 아직 이전 데이터를 들고 있는 것으로 해석할 수 있습니다.

전파가 완전히 끝났는지 확인하는 더 확실한 방법은, 변경한 레코드의 값이 실제로 응답에 나타나는지 보는 것입니다. 예를 들어 IP 주소를 변경했다면 dig 응답의 A 레코드 값이 새 IP 주소와 일치해야 합니다. 변경 전 값과 비교해 보고 싶다면, 변경 직전에 dig 명령을 실행해 기존 응답을 파일로 저장해 두는 것도 좋은 방법입니다.

Cloudflare를 사용하고 있다면 DNS 레코드 설정 단계에서 실수할 가능성도 있습니다. 이 경우 Cloudflare DNS 레코드 설정 오류 해결 방법을 참고해 레코드 설정부터 다시 확인할 수 있습니다.

전파 상태 확인 후 TTL 복원 및 추가 확인

실제 운영 중인 서비스라면 전파가 완료된 후에는 TTL을 원래 값으로 복원하는 것이 좋습니다. TTL이 긴 값이라도 DNS 캐시가 권위 있는 서버에 문제가 생겼을 때 스스로 응답할 수 있는 여유를 제공합니다. TTL이 길면 DNS 캐시가 권위 있는 서버에 문제가 있더라도 쿼리에 대한 응답을 스스로 제공할 수 있습니다. 그러니 변경 작업이 끝난 뒤에는 A 레코드라면 3600초 이상, MX 레코드라면 43200초 이상으로 되돌리는 것을 고려하세요.

여기까지의 내용을 단계로 정리하면 다음과 같습니다.

  1. 변경 예정 시점보다 24~48시간 전에 변경할 레코드의 TTL을 300초로 낮춥니다.
  2. TTL 변경이 적용될 시간을 기다린 후, dig @8.8.8.8 example.com A 명령으로 현재 상태를 확인합니다.
  3. 응답의 두 번째 열에서 TTL 값이 300초인지 확인합니다.
  4. 여러 DNS 서버(예: 8.8.8.8, 1.1.1.1)에 질의해 레코드 값이 동일한지 비교합니다.
  5. 새 IP 주소나 새 값이 응답에 나타나면 전파가 완료된 것입니다.
  6. 전파가 확인된 뒤에는 TTL을 원래 권장 값으로 복원합니다.

이 단계에서 응답이 여전히 이전 값을 가리킨다면, 질의한 DNS 서버가 아직 캐시를 보관하고 있는 것입니다. 이 경우 TTL이 만료될 때까지 기다린 뒤 다시 확인하세요. 여러 DNS 서버 중 일부만 새 값을 반환한다면 전파가 진행 중인 상태이므로, 조금 더 기다린 후 재확인하는 것이 좋습니다. 만약 모든 서버에서 이전 값이 계속 나온다면, DNS 설정이 실제로 저장되었는지 호스팅 업체의 관리 화면을 다시 확인해 보세요.

참고 자료