DNS가 됐다 안 됐다 하는 장애는 TTL부터 어떻게 읽어야 할까요?¶

DNS 장애는 전부가 한꺼번에 망가질 것 같죠? 사실은 어떤 사람에게는 정상이고, 어떤 사람에게는 장애처럼 보이는 시간이 꽤 길게 남을 수 있어요.

DNS는 어떻게 이름을 IP 주소로 바꿀까요?에서는 DNS가 도메인 이름을 IP 주소로 바꿔주는 안내 데스크라는 큰 그림을 봤어요. 그리고 DNS TTL과 캐시는 왜 바뀐 주소를 바로 안 보여줄까요?에서는 재귀 리졸버가 답을 TTL 동안 캐시할 수 있다는 것도 봤죠.

이번 글은 그 지식이 실제 장애처럼 보이는 장면에서 어떻게 쓰이는지 볼게요.

장면은 이래요.

• 새 서버로 DNS 레코드를 바꿨어요.
• 내 노트북에서는 새 IP가 보여요.
• 그런데 고객 일부는 계속 예전 서버로 가요.
• 다른 지역 모니터링은 정상과 실패가 번갈아 보여요.
• 팀 채널에서는 "DNS가 플랩한다"는 말이 나오기 시작해요.

처음 보면 DNS가 랜덤하게 흔들리는 것 같아요. 근데요, DNS가 정말로 매초 값을 바꾸고 있을 수도 있지만, 더 흔한 장면은 여러 재귀 리졸버가 서로 다른 캐시 상태를 보고 있는 것이에요.

먼저 같은 안내문을 보고 있는지 확인해요¶

건물 입구 안내판을 새 주소로 바꿨다고 해볼게요. 본사 안내판은 이미 새 주소예요. 그런데 각 지점 안내 데스크 직원들이 어제 복사해 간 메모를 아직 들고 있다면요?

어떤 지점에서는 새 주소를 알려주고, 어떤 지점에서는 예전 주소를 알려줄 수 있어요. 본사 안내판이 다시 예전 주소로 바뀐 게 아니라, 메모를 새로 받아간 시각이 지점마다 다른 것이죠.

DNS도 비슷해요.

여기서 핵심 질문은 이거예요.

"지금 내가 보는 답은 권한 DNS의 원본일까요, 어느 재귀 리졸버의 캐시일까요?"

이 질문을 빼먹으면 "DNS가 이상하다"는 말이 너무 커져요. 권한 DNS가 틀린 건지, 재귀 리졸버 캐시가 아직 남은 건지, 내 로컬 캐시가 붙잡고 있는 건지 갈라지지 않거든요.

flowchart LR
    A[사용자 A<br/><small>회사 DNS 사용</small>] --> R1[재귀 리졸버 1<br/><small>예전 IP 캐시, TTL 남음</small>]
    B[사용자 B<br/><small>공용 DNS 사용</small>] --> R2[재귀 리졸버 2<br/><small>새 IP 조회 완료</small>]
    C[운영자<br/><small>권한 DNS 직접 확인</small>] --> AUTH[권한 DNS<br/><small>새 IP 보유</small>]

    R1 --> OLD[예전 IP 응답]
    R2 --> NEW[새 IP 응답]
    AUTH --> NEW

이 그림에서 겉으로는 "DNS가 사용자마다 다르다"로 보이지만, 실제로는 조회한 위치가 달라요. 그래서 장애 초반에는 누가, 어느 리졸버를 통해, 어떤 TTL이 남은 답을 봤는지를 먼저 모아야 해요.

먼저 읽을 신호 여섯 가지¶

DNS 플랩처럼 보이는 장면에서는 레코드를 계속 바꾸기 전에 신호를 짧게 잡아야 해요.

예를 들어 www.example.com의 A 레코드를 새 서버로 바꿨다고 해볼게요. 아래 출력은 읽기 연습용 예시예요.

$ dig @1.1.1.1 www.example.com A +noall +answer
www.example.com.      41    IN    A    198.51.100.20

$ dig @8.8.8.8 www.example.com A +noall +answer
www.example.com.     721    IN    A    192.0.2.10

두 줄을 보고 바로 "1.1.1.1은 맞고 8.8.8.8은 틀렸다"고 끝내면 조금 위험해요. 더 정확히는 이렇게 읽는 편이 좋아요.

• 1.1.1.1은 새 IP 198.51.100.20을 보고 있어요.
• 8.8.8.8은 예전 IP 192.0.2.10을 아직 캐시하고 있어요.
• 예전 IP 응답의 TTL이 721초 남아 있으니, 이 리졸버를 쓰는 사용자는 한동안 예전 서버로 갈 수 있어요.

권한 DNS와 재귀 리졸버를 나눠서 봐요¶

DNS 전환 장애에서 제일 먼저 갈라야 하는 건 원본과 캐시예요.

sequenceDiagram
    participant O as 운영자
    participant R as 재귀 리졸버
    participant A as 권한 DNS

    O->>A: www.example.com A?
    A-->>O: 새 IP, TTL 60
    O->>R: www.example.com A?
    alt 재귀 리졸버가 예전 답을 캐시 중
        R-->>O: 예전 IP, 남은 TTL 721
    else R 캐시가 만료됨
        R->>A: 원본 다시 조회
        A-->>R: 새 IP, TTL 60
        R-->>O: 새 IP, TTL 60
    end

권한 DNS는 도메인의 원본 레코드를 들고 있는 쪽이에요. 재귀 리졸버는 사용자 대신 권한 DNS를 찾아가고, 답을 TTL 동안 보관할 수 있는 쪽이고요.

그래서 확인도 두 갈래로 나눠요.

dig @ns1.example-dns.net www.example.com A +noall +answer
dig @1.1.1.1 www.example.com A +noall +answer
dig @8.8.8.8 www.example.com A +noall +answer

첫 번째는 권한 DNS를 직접 보는 의도예요. 실제 권한 DNS 이름은 도메인마다 다르니 dig NS example.com으로 먼저 확인해야 해요. 두 번째와 세 번째는 서로 다른 재귀 리졸버가 어떤 답을 들고 있는지 보는 의도고요.

여기서 중요한 반전이 있어요.

권한 DNS가 새 값을 보여준다고 해서, 모든 사용자가 이미 새 값을 본다는 뜻은 아니에요.

TTL은 남은 시간을 보여줘요¶

TTL은 원본에 적힌 숫자이기도 하지만, 재귀 리졸버 응답에서는 남은 시간처럼 보일 때가 많아요.

예를 들어 전환 전 레코드가 이랬다고 해볼게요.

www.example.com.    1800    IN    A    192.0.2.10

운영자가 10:00에 새 IP로 바꿨어요.

www.example.com.      60    IN    A    198.51.100.20

그런데 어떤 재귀 리졸버는 09:55에 예전 답을 받아갔어요. 전환 시각 10:00에는 아직 1500초 정도가 남아 있을 수 있죠.

flowchart LR
    A[09:55<br/><small>리졸버가 예전 IP 조회<br/>TTL 1800</small>]
    B[10:00<br/><small>권한 DNS를 새 IP로 변경</small>]
    C[10:00 이후<br/><small>해당 리졸버는 남은 TTL 동안<br/>예전 IP 응답 가능</small>]
    D[10:25 전후<br/><small>TTL 만료 뒤 새 IP 조회</small>]

    A --> B --> C --> D

이때 "10:00에 TTL을 60으로 바꿨는데 왜 아직 25분이나 예전 IP가 보이죠?"라는 질문이 나와요.

이유는 단순해요. 이미 받아간 예전 답의 TTL은 나중에 원본 TTL을 낮춘다고 자동으로 줄어들지 않아요. 새 TTL 60은 새로 받아가는 답부터 의미가 있어요.

그래서 큰 전환 전에는 보통 이런 순서가 더 안전해요.

"됐다 안 됐다"는 네 가지 모양으로 갈라져요¶

DNS가 흔들린다고 말할 때 실제 모양은 하나가 아니에요. 처음에는 아래 네 갈래로 나눠보면 좋아요.

특히 두 번째 줄은 TTL 문제처럼 보이지만 아닐 수 있어요. A 레코드가 여러 개면 DNS는 여러 주소를 돌려줄 수 있고, 클라이언트는 IPv4와 IPv6 중 더 잘 닿는 쪽을 고르기도 해요. 이때는 "예전 값과 새 값이 섞였다"가 아니라 원래 여러 값을 주는 설정인지를 먼저 봐야 해요.

$ dig www.example.com A +short
198.51.100.20
198.51.100.21

이런 응답은 그 자체로 장애가 아니에요. 하지만 한 주소만 실패한다면 DNS보다 뒤쪽의 서버, 로드 밸런서, 방화벽, 배포 상태를 같이 봐야 해요.

없는 이름도 잠깐 기억될 수 있어요¶

DNS 전환에서 또 자주 헷갈리는 장면은 NXDOMAIN이에요. 새 서브도메인을 만들기 전에 누군가가 먼저 조회했는데, 그때 "그런 이름 없음"이라는 답을 받아갔다고 해볼게요.

$ dig @8.8.8.8 api-new.example.com A +noall +answer +authority
example.com.    600    IN    SOA    ns1.example-dns.net. hostmaster.example.com. ...

그 뒤 운영자가 api-new.example.com 레코드를 만들었어요. 권한 DNS에는 이제 존재해요. 그런데 어떤 재귀 리졸버는 여전히 한동안 없다고 말할 수 있어요. 성공한 A 레코드만 캐시되는 게 아니라, 없는 이름이라는 답도 음성 캐시로 남을 수 있기 때문이에요.

RFC 2308은 이런 음성 응답 캐시의 동작을 정리해요. 운영자가 자세한 숫자를 볼 때는 응답의 SOA 정보와 리졸버별 남은 TTL을 같이 확인해야 해요.

잘못 읽기 쉬운 함정¶

DNS TTL 장애는 눈에 보이는 증상이 들쭉날쭉해서 결론을 빨리 내리기 쉬워요. 특히 아래 함정은 자주 나와요.

운영 채널에서는 "전파가 덜 됐다"는 말이 편해요. 하지만 실제로 조치해야 할 때는 조금 더 작게 말하는 편이 좋아요.

"권한 DNS는 새 값이고, 일부 재귀 리졸버가 예전 A 레코드를 남은 TTL 동안 캐시 중이에요."

이렇게 말하면 기다릴 문제인지, 설정을 고칠 문제인지, 사용자 안내를 해야 할 문제인지 훨씬 분명해져요.

실제 대응 순서는 이렇게 잡아요¶

DNS 플랩 의심 장면에서 바로 할 수 있는 대응 순서를 하나로 묶으면 이래요.

flowchart TD
    A[사용자별 결과가 다름] --> B[문제 이름과 타입 고정<br/><small>A / AAAA / CNAME</small>]
    B --> C[권한 DNS 직접 조회]
    C --> D{권한 DNS 값이 맞나요?}
    D -->|아니오| E[원본 zone / NS / serial 수정]
    D -->|예| F[여러 재귀 리졸버 조회]
    F --> G{예전 값에 TTL이 남았나요?}
    G -->|예| H[남은 TTL, 영향 리졸버, 사용자 안내]
    G -->|아니오| I[로컬 캐시, IPv6, HTTP/TLS/오리진 분리]
    H --> J[안정화 뒤 TTL 복구와 전환 절차 회고]
    I --> J

이 순서에서 중요한 건 도메인 이름과 타입을 고정하는 것이에요. www.example.com A를 보는 중에 갑자기 example.com AAAA나 api.example.com CNAME 이야기를 섞으면 판단이 흐려져요. DNS 문제는 이름과 타입이 조금만 달라도 완전히 다른 레코드예요.

실제 기록은 아래 정도면 시작하기 충분해요.

증상 시각: 2026-06-23 10:04 KST
대상: www.example.com A
기대값: 198.51.100.20
예전값: 192.0.2.10

권한 DNS:
  ns1.example-dns.net -> 198.51.100.20 TTL 60
  ns2.example-dns.net -> 198.51.100.20 TTL 60

재귀 리졸버:
  1.1.1.1 -> 198.51.100.20 TTL 41
  8.8.8.8 -> 192.0.2.10 TTL 721
  회사 DNS -> 192.0.2.10 TTL 1140

해석:
  원본은 새 값으로 바뀌었고, 일부 재귀 리졸버가 예전 답을 캐시 중.

이렇게 적어두면 "DNS가 이상해요"보다 훨씬 실행 가능한 상태가 돼요. 남은 TTL 동안 예전 서버를 유지해야 하는지, 예전 서버에서 새 서버로 임시 리다이렉트나 프록시를 둘 수 있는지, 사용자에게 어느 정도 시간을 안내해야 하는지 판단할 수 있거든요.

자, 정리해볼까요?¶

이어서 보면 좋은 글¶

• DNS TTL과 캐시는 왜 바뀐 주소를 바로 안 보여줄까요? — TTL과 재귀 리졸버 캐시의 기본 동작을 더 차분히 보고 싶을 때 좋아요.
• dig 출력은 어디부터 읽어야 할까요? — ANSWER, AUTHORITY, SERVER, TTL 줄을 도구 화면에서 직접 읽고 싶을 때 이어서 보면 좋아요.
• DNS 재귀 조회와 반복 조회는 뭐가 다를까요? — 사용자가 권한 DNS에 직접 묻지 않는 이유와 재귀 리졸버의 역할을 다시 잡을 수 있어요.