DNS TTL이란 무엇인가요? 개념 이해, 설정 방법, 그리고 모범 사례 알아보기

TTL이란 “Time To Live”의 준말으로 DNS 리졸버가 쿼리를 캐싱해야 하는 시간을 의미합니다. 데이터가 설정된 시간 만큼 DNS 리졸버 캐시에 저장되어 있으므로 DNS 쿼리를 계속 보내고 기본 서버의 주소를 계속해서 재확인하는 수고를 줄여줍니다. DNS는 TTL 시간이 만료되고 나서야 캐시를 폐기하거나 주소 확인을 위해 또 다른 쿼리를 전송합니다. DNS TTL 설정 값은 브라우징 경험에 상당한 영향력을 미칩니다. 예를 들어, TTL 값이 짧으면 오래되어 더 이상 유효하지 않은 IP 주소를 사용할 가능성이 줄어들어 보안에 도움이 됩니다. 하지만 긴 TTL은 캐시를 더 많이 사용하므로 응답 시간이 빨라집니다. 즉, TTL을 이용하여 최적의 보안과 속도 사이의 균형을 맞출 수 있습니다.

DNS 레코드란 도메인에 대한 상세 정보들을 나타내는 DNS 데이터베이스 내의 항목을 말합니다. 모든 DNS 레코드 타입은 각자 다른 고유의 목적을 가지고 있으며 도메인의 특정 기능(예시: 관련 웹 사이트나 이메일 시스템)을 안내합니다. 예를 들자면, 주소 레코드나 A 레코드의 경우 도메인을 상응하는 IPv4주소로 연결합니다. 반면, SOA(start of authority) 레코드는 도메인과 그의 DNS 영역에 대한 관리용 데이터를 가지고 있으며, 기본 권한 네임서버, 이메일 연락처, 영역의 새로 고침 및 재시도 기간과 관련된 다양한 타이밍 설정을 강조합니다. SOA에 대해서는 아래에서 자세히 다룰 것입니다. DNS와 VPN을 비교해보면 어떤가요? DNS 세팅을 변경하려면 당신의 디바이스가 도메인 이름을 IP 주소로 변경하는 데 사용하는 DNS 서버도 수정해야 합니다. 이로서 웹사이트 로딩 시간, 보안, 콘텐츠 필터링을 향상시킬 수 있습니다. 반면, VPN 서버에 연결하면 암호화된 DNS 트래픽을 보호해주고, 일정 수준의 프라이버시를 제공하며, 리소스에 안전하게 접근하는 것 까지 도와줍니다. 레코드를 안전하게 보호하는 DNS를 신뢰하지 못한다면, DNS 누출 테스트를 시행할 수 있습니다.

DNS의 TTL은 캐시에 데이터를 저장하는 적절한 기간을 설정하기 위해서 사용됩니다. 데이터가 너무 오래 남아있어서 업데이트가 되지 않거나, 혹은 너무 자주 리프레시 되어 IP 주소를 계속 재 검증하며 서버에 부담을 주지 않도록 해야 합니다. 날씨 정보 업데이트 서비스를 예시로 들어 봅시다. 당신은 잠자리에 들기 전에 내일 우산이 필요한 지 알아보고 싶어서 날씨를 체크합니다. 웹사이트에는 비가 오지 않는다고 되어 있는데, 아침에 다시 한번 더 일기예보도 체크하기로 합니다. 왜냐하면 TTL은 웹사이트의 캐시된 웹사이트를 보여주기도 하는데, TTL이 길다면 그 전날 밤에 봤던것과 같은 웹사이트 버전으로 보여줄 가능성이 높기 때문입니다. 반면, 짧은 TTL은 더 정확한 날씨 정보를 제공할 것입니다. 일반적으로 DNS TTL은 웹사이트 마이그레이션과 스케줄링 관리를 위해 사용되는데, 웹사이트 로드를 관리하는 것에 도움이 되기도 합니다. 만약 웹사이트 서버가 한계치에 다다른 상태라면 TTL을 길게 설정하는 것이 DNS 요청 수를 줄여 줄 것입니다. 하지만 사용자들이 가능한 빨리 가장 정확한 정보를 원한다면, 짧은 TTL이 사용자들에게 업데이트된 정보를 빨리 제공할 것이며 메인 서버가 고장날 경우에도 백업 서버로 더 빨리 전환해 줄 것입니다. {SHORTCODES.blogRelatedArticles}

만약 당신이 웹사이트를 소유하고 있다면, 사이트 로딩 속도가 얼마나 중요한 것인지 알 것입니다. 광고, 트래커, 스크립트, 써드 파티 서비스 등 무수히 많은 요소들이 웹 페이지 로딩 시간을 증가시킵니다. DNS TTL은 DNS 서버 로드를 줄이는 것과 최적의 사용자 경험을 위한 웹사이트 최적화를 하는 것 사이에서 알맞은 밸런스를 잡도록 도와줍니다.

대개의 경우 기본 DNS 캐싱 설정값을 바꿀 필요는 없습니다. 하지만 만약에 바꿔야 할 경우 TTL 값에 대해 알아야 할 점들이 있습니다. DNS TTL 값은 초 단위로 설정되므로, 설정할 수 있는 최소 값은 1초 입니다. 하지만, 그건 DNS 리졸버가 레코드의 권한 서버를 요청이 들어올 때 마다 거의 매번 조회해야 하는 것을 의미하므로 서버의 부하가 엄청나게 늘 것입니다. 종종, 기본 TTL 설정 값의 범위는 최소 몇 분에서 최대 48시간 까지입니다. TTL의 최대 값은 DNS 공급자에 따라서 달라집니다. 주로 값을 24시간(86,400초)로 설정하는데 최대 3일(259,200초)까지 설정할 수 있습니다. 경우에 따라 그것보다 더 크게 설정할 수 있기도 합니다. 먼저 현재 상황을 심사숙고 해보십시오. 굳이 기본 TTL DNS 설정을 바꾸지 않아도 되는 것은 아닐까요? 만약 바꾸어야 한다면, TTL 값을 낮춰야 하는지 높여야 하는지 생각해 두었을 것입니다. 일단 시간 값을 약간만 조정해 본다음 다시 평가해 보십시오. 항상 최적의 TTL 값을 알지는 못하지만, DNS 설정을 변경해야 할 대표 사례들을 나열해 보았습니다. 기본 도메인의 IP 주소가 몇년 째 동일한 경우에는 86,400과 같이 긴 TTL이 적당한 값이라 할 수 있습니다. 마이그레이션이나 테스트를 할 때는 300초 정도로 설정하십시오. DDoS 공격이 염려될 경우 43,200 초 정도로 길게 TTL 값을 설정하면 DNS 서버가 공격을 당하는 중에도 사용자들에게 캐시된 버전의 웹사이트를 보여줄 수 있을 것입니다. DNS를 장애 조치, 즉 failover 용도로 사용할 경우에는 600초에서 1,800초 사이의 값을 설정하십시오. 클라우드 서비스를 사용 중이라면, 해당 서비스 가이드라인에서 권장 TTL 값이 있는지 확인하십시오. 빈번한 서비스 업데이트가 꼭 필요할 경우 7,200초 정도의 TTL을 설정하면 성능과 최신 업데이트간의 밸런스를 맞출 수 있습니다. 온라인 게임 보안 향상을 위해 네트워크 연결을 개선하려면 TTL 값을 바꾸는 것 보다는 DNS 서버를 게임용 DNS 서버로 교체하는 것을 고려하십시오.

동적 TTL을 사용하면 실시간 조건이나 요구 사항에 자동적으로 맞출 수 있습니다. 이는 시스템 관리자가 정해진 하나의 값에 매이지 않고 TTL을 바꿀 수 있도록 유연성을 제공하는 훌륭한 툴입니다.

DNS TTL lookup은 특정 DNS 레코드의 TTL 값을 확인할 수 있게 해 줍니다. 다양한 온라인 툴을 이용해서 DNS lookup을 하거나 본인이 직접 DNS TTL 확인할 수도 있습니다. Windows 에서는 명령 프롬프트를 열고, “nslookup -type=any domain.com” 를 입력 후 엔터를 누릅니다. 맥 OS와 리눅스 환경에서는 “dig” 명령어를 사용합니다: “dig domain.com.”

SOA(start of authority) 레코드는 기본 DNS 서버의 세부 정보, 도메인 관리자의 이메일 주소, 도메인 시리얼 넘버, 새로 고침 및 재시도 타이머 등 도메인에 관한 권한 정보를 제공합니다. SOA TTL은 SOA 레코드가 업데이트 되어야 하는 제한 시간입니다. Refresh TTL은 보조 서버가 업데이트 되어야 하는 제한 시간입니다. Retry TTL은 실패했을 경우에 업데이트를 다시 시작해야 하는 시간을 말합니다. Expiry TTL은 업데이트가 실패한 경우에 기본 서버가 만료된 것으로 간주하는 제한 시간을 말합니다. NX TTL 값은 도메인 쿼리 결과가 NXDOMAIN일때, 이 TTL 값에 따라 리졸버가 얼마나 오래동안 캐싱을 하고 “non-existence” 답을 재사용 할 지가 결정됩니다. 이 값들을 변경했다가 혹시 원치 않는 결과를 불러올 수도 있습니다. 꼭 해야만 할 이유가 있지 않은 이상 일반적으로는 SOA TTL을 변경하지 않는 것을 권장합니다.