DNS TTL이란? TTL을 300초로 설정하면 정말 5분 뒤에 IP가 바뀔까?

서비스를 운영하다 보면 DNS 레코드를 변경해야 하는 경우가 있다.

예를 들어 기존 서버에 장애가 발생해 새로운 서버로 트래픽을 전환한다고 생각해보자.

기존

example.com
    ↓
10.0.0.1


장애 발생 후

example.com
    ↓
10.0.0.2

DNS의 A Record를 10.0.0.1에서 10.0.0.2로 변경하면 사용자들은 바로 새로운 서버로 접속하게 될까?

여기서 등장하는 개념이 **DNS TTL(Time To Live)**이다.

---

1. DNS TTL이란?

DNS는 도메인 이름을 IP 주소로 변환해준다.

example.com
     ↓
  DNS 조회
     ↓
10.0.0.1

그런데 사용자가 example.com에 접근할 때마다 매번 DNS 서버에 처음부터 질의한다면 불필요한 DNS 요청이 계속 발생하게 된다.

그래서 DNS 조회 결과는 여러 계층에서 캐싱(Cache) 될 수 있다.

예를 들어 DNS Resolver가 다음과 같은 응답을 받았다고 해보자.

example.com → 10.0.0.1
TTL = 300

TTL이 300초라는 것은 이 DNS 레코드를 300초 동안 캐시하여 사용할 수 있다는 의미다.

따라서 캐시가 유효한 동안에는 동일한 도메인에 대한 요청이 들어와도 매번 Authoritative DNS Server까지 질의할 필요 없이 캐싱된 결과를 사용할 수 있다.

Client
   ↓
Recursive Resolver
   │
   ├── Cache HIT
   │      ↓
   │   10.0.0.1 반환
   │
   └── Cache MISS
          ↓
   Authoritative DNS

TTL 덕분에 DNS 조회 횟수를 줄이고 빠르게 응답할 수 있는 것이다.

---

2. 그런데 DNS 레코드의 IP가 변경된다면?

이번에는 운영 중인 서버에 장애가 발생했다고 해보자.

기존 DNS 설정은 다음과 같다.

example.com → 10.0.0.1
TTL = 300

장애 대응을 위해 DNS 레코드를 새로운 서버로 변경했다.

example.com → 10.0.0.2
TTL = 300

Authoritative DNS Server에는 새로운 IP가 반영되었다.

하지만 문제가 하나 있다.

어떤 Recursive Resolver가 변경 직전에 기존 IP를 조회해 캐싱했다면, 해당 캐시는 아직 유효하다.

                    ┌─ 기존 캐시 ─────────┐
Client → Resolver   │ example.com         │
                    │ → 10.0.0.1          │
                    │ TTL remaining: 280s │
                    └─────────────────────┘

이 Resolver를 사용하는 클라이언트는 TTL이 만료될 때까지 기존 IP를 전달받을 수 있다.

즉, DNS 레코드를 수정했다고 해서 기존 캐시까지 동시에 사라지는 것은 아니다.

---

3. 그렇다면 TTL 300초면 정확히 5분 뒤 모두 바뀔까?

여기서 한 가지 의문이 생긴다.

TTL을 300초로 설정했으니 DNS를 변경하고 정확히 5분만 기다리면 모든 사용자가 새로운 IP를 사용하게 되는 걸까?

꼭 그렇다고 볼 수는 없다.

우선 중요한 것은 각 Resolver의 캐시가 만들어진 시간이 다르다는 것이다.

Resolver A
14:00:00 조회
→ 14:05:00 만료

Resolver B
14:02:00 조회
→ 14:07:00 만료

Resolver C
14:04:30 조회
→ 14:09:30 만료

TTL은 DNS 변경 시점을 기준으로 시작되는 타이머가 아니다.

각 Resolver가 해당 레코드를 캐싱한 시점부터 감소하는 값이다.

따라서 DNS 레코드를 변경하는 순간에도 인터넷 곳곳에는 서로 다른 TTL이 남아 있는 기존 캐시가 존재할 수 있다.

또한 실제 클라이언트까지 내려오면 로컬 DNS 캐시 등 추가적인 캐싱 계층의 영향을 받을 수 있다.

따라서

TTL 300초
≠
DNS 변경 후 정확히 300초 뒤
전 세계 모든 클라이언트가 동시에 변경

이라고 이해하는 것이 좋다.

TTL은 DNS 변경의 정확한 전파 완료 시간을 의미하는 값이라기보다 DNS 레코드를 얼마 동안 캐싱하여 사용할 수 있는지를 나타내는 값에 가깝다.

---

4. 그렇다면 TTL은 짧을수록 좋은 걸까?

장애 대응만 생각하면 TTL을 짧게 설정하는 것이 좋아 보인다.

예를 들어,

TTL = 3600

이라면 기존 DNS 결과가 비교적 오래 남을 수 있지만,

TTL = 60

이라면 Resolver가 훨씬 자주 DNS 정보를 다시 확인하게 된다.

따라서 장애가 발생해 IP를 변경해야 할 때 새로운 레코드가 더 빠르게 반영될 가능성이 높아진다.

하지만 TTL을 짧게 만드는 것에도 비용이 있다.

TTL이 짧은 경우

TTL ↓

DNS Cache Hit ↓
DNS Query ↑
DNS 변경 반영 속도 ↑

TTL이 긴 경우

TTL ↑

DNS Cache Hit ↑
DNS Query ↓
DNS 변경 반영 속도 ↓

결국 TTL에는 캐싱 효율과 변경 반영 속도 사이의 Trade-off가 존재한다.

따라서 무조건 TTL을 짧게 설정하기보다는 서비스의 특성에 맞는 값을 선택해야 한다.

---

5. 예정된 서버 이전이라면?

장애가 아니라 서버 이전처럼 DNS 변경 시점을 미리 알고 있는 경우에는 조금 다른 전략을 사용할 수 있다.

예를 들어 현재 TTL이 1시간이라고 해보자.

example.com → 10.0.0.1
TTL = 3600

서버를 변경하기 직전에 TTL을 60초로 낮춘다고 해서 기존 Resolver들의 캐시가 바로 60초로 변경되는 것은 아니다.

이미 Resolver가 받아간 기존 레코드는 기존 TTL을 기준으로 캐싱되고 있기 때문이다.

따라서 예정된 DNS 변경이라면 충분히 미리 TTL을 낮춰 기존의 긴 TTL 캐시가 만료될 시간을 확보할 수 있다.

[기존]

TTL = 3600


        ↓ 변경보다 충분히 이전

TTL = 60


        ↓ 기존 캐시 만료 대기

DNS IP 변경


        ↓

새로운 IP가 짧은 TTL을 기준으로 반영

DNS 변경이 끝나 안정화되었다면 필요에 따라 TTL을 다시 원래 수준으로 높일 수도 있다.

---

6. Negative Caching도 있다

DNS에는 정상적인 응답만 캐싱되는 것은 아니다.

예를 들어 존재하지 않는 도메인을 조회했다고 해보자.

api.example.com
      ↓
     DNS
      ↓
   NXDOMAIN

이처럼 도메인이 존재하지 않는다는 응답 자체도 캐싱될 수 있다.

이를 Negative Caching이라고 한다.

따라서 방금까지 존재하지 않던 DNS 레코드를 새롭게 생성한 경우에는 Authoritative DNS에 레코드를 추가했더라도 일부 Resolver가 기존의 NXDOMAIN 응답을 캐싱하고 있다면 일정 시간 동안 새로운 레코드를 바로 조회하지 않을 수도 있다.

단, 이것은 기존 A Record의 IP를 10.0.0.1 → 10.0.0.2로 변경하는 일반적인 상황과는 구분해서 생각해야 한다.

Negative Cache는 주로 “해당 레코드가 존재하지 않는다”는 응답을 캐싱하는 문제이기 때문이다.

---

7. TTL이 만료되면 무조건 기존 값이 사라질까?

일반적으로 TTL이 만료되면 Resolver는 기존 캐시를 그대로 계속 사용하는 대신 다시 DNS 정보를 확인해야 한다.

다만 DNS에는 장애 상황에서 가용성을 높이기 위해 만료된 데이터를 일시적으로 제공하는 Serve Stale 같은 메커니즘도 존재한다.

즉 실제 운영 환경에서는 단순히

TTL 만료
→ 무조건 기존 IP 즉시 제거

라고만 생각하기보다는 Resolver와 DNS 인프라의 동작 방식도 함께 고려해야 한다.

다만 DNS TTL을 처음 공부하는 단계에서는 우선

TTL은 DNS 레코드가 캐시에 머물 수 있는 시간을 제어한다.

정도로 이해한 뒤 이런 예외적인 동작을 추가로 알아두면 충분하다.

---

8. 정리

처음 질문으로 돌아가보자.

TTL을 300초로 설정하면 DNS IP를 변경한 뒤 정확히 5분 후 모든 사용자가 새로운 IP를 사용하게 될까?

정확히 그렇다고 보기는 어렵다.

TTL은 DNS 변경 후 전 세계에 전파되는 시간을 의미하는 값이 아니라, DNS 레코드를 캐싱할 수 있는 시간을 의미하기 때문이다.

각 Resolver가 캐시를 생성한 시점도 다르고, 실제 클라이언트까지 DNS 결과가 전달되는 과정에는 여러 캐싱 계층이 존재할 수 있다.

결국 TTL을 결정할 때는 단순히 짧게 설정하는 것이 아니라,

빠른 DNS 변경 및 Failover
             ↕
DNS 캐싱 효율과 Query 비용

사이의 균형을 고려해야 한다.

그리고 예정된 DNS 변경이라면 변경 직전에 TTL을 낮추는 것이 아니라 충분히 미리 TTL을 낮춰 기존 캐시가 만료될 시간을 확보하는 것도 중요한 운영 전략이 될 수 있다.

DNS TTL은 단순히 “캐시가 몇 초 동안 유지되는가”라는 작은 설정처럼 보이지만, 장애 대응이나 서버 이전 상황에서는 실제 트래픽이 어느 서버로 향하는지를 결정하는 중요한 값이 될 수 있다.