DNS 장애는 전부가 한꺼번에 망가질 것 같죠? 사실은 어떤 사람에게는 정상이고, 어떤 사람에게는 장애처럼 보이는 시간이 꽤 길게 남을 수 있어요.DNS는 어떻게 이름을 IP 주소로 바꿀까요?에서는 DNS가 도메인 이름을 IP 주소로 바꿔주는 안내 데스크라는 큰 그림을 봤어요. 그리고 DNS TTL과 캐시는 왜 바뀐 주소를 바로 안 보여줄까요?에서는 재귀 리졸버가 답을 TTL 동안 캐시할 수 있다는 것도 봤죠. 이번 글은 그 지식이 실제 장애처럼 보이는 장면에서 어떻게 쓰이는지 볼게요. 장면은 이래요.
- 새 서버로 DNS 레코드를 바꿨어요.
- 내 노트북에서는 새 IP가 보여요.
- 그런데 고객 일부는 계속 예전 서버로 가요.
- 다른 지역 모니터링은 정상과 실패가 번갈아 보여요.
- 팀 채널에서는 “DNS가 플랩한다”는 말이 나오기 시작해요.
여기서는 DNS가 됐다 안 됐다 하는 증상을 TTL과 캐시 관점으로 좁히는 읽기 순서에 집중해요. 특정 DNS 사업자의 장애 공지, 특정 제품의 레코드 편집 화면, Anycast 라우팅 문제까지 한꺼번에 다루지는 않을게요.
먼저 같은 안내문을 보고 있는지 확인해요
건물 입구 안내판을 새 주소로 바꿨다고 해볼게요. 본사 안내판은 이미 새 주소예요. 그런데 각 지점 안내 데스크 직원들이 어제 복사해 간 메모를 아직 들고 있다면요? 어떤 지점에서는 새 주소를 알려주고, 어떤 지점에서는 예전 주소를 알려줄 수 있어요. 본사 안내판이 다시 예전 주소로 바뀐 게 아니라, 메모를 새로 받아간 시각이 지점마다 다른 것이죠. DNS도 비슷해요.
여기서 핵심 질문은 이거예요.
“지금 내가 보는 답은 권한 DNS의 원본일까요, 어느 재귀 리졸버의 캐시일까요?”이 질문을 빼먹으면 “DNS가 이상하다”는 말이 너무 커져요. 권한 DNS가 틀린 건지, 재귀 리졸버 캐시가 아직 남은 건지, 내 로컬 캐시가 붙잡고 있는 건지 갈라지지 않거든요. 이 그림에서 겉으로는 “DNS가 사용자마다 다르다”로 보이지만, 실제로는 조회한 위치가 달라요. 그래서 장애 초반에는 누가, 어느 리졸버를 통해, 어떤 TTL이 남은 답을 봤는지를 먼저 모아야 해요.
먼저 읽을 신호 여섯 가지
DNS 플랩처럼 보이는 장면에서는 레코드를 계속 바꾸기 전에 신호를 짧게 잡아야 해요.
예를 들어
www.example.com의 A 레코드를 새 서버로 바꿨다고 해볼게요. 아래 dig 출력과 이 글에 이어지는 IP·TTL·시각 값은 모두 설명을 위해 만든 합성 예시이며, 실제 장애에서 수집한 출력은 아니에요.
1.1.1.1은 새 IP198.51.100.20을 보고 있어요.8.8.8.8은 예전 IP192.0.2.10을 아직 캐시하고 있어요.- 예전 IP 응답의 TTL이
721초 남아 있으니, 이 리졸버를 쓰는 사용자는 한동안 예전 서버로 갈 수 있어요.
권한 DNS와 재귀 리졸버를 나눠서 봐요
DNS 전환 장애에서 제일 먼저 갈라야 하는 건 원본과 캐시예요. 권한 DNS는 도메인의 원본 레코드를 들고 있는 쪽이에요. 재귀 리졸버는 사용자 대신 권한 DNS를 찾아가고, 답을 TTL 동안 보관할 수 있는 쪽이고요. 그래서 확인도 두 갈래로 나눠요.dig NS example.com으로 먼저 확인해야 해요. 두 번째와 세 번째는 서로 다른 재귀 리졸버가 어떤 답을 들고 있는지 보는 의도고요.
여기서 중요한 반전이 있어요.
권한 DNS가 새 값을 보여준다고 해서, 모든 사용자가 이미 새 값을 본다는 뜻은 아니에요.
TTL은 남은 시간을 보여줘요
TTL은 원본에 적힌 숫자이기도 하지만, 재귀 리졸버 응답에서는 남은 시간처럼 보일 때가 많아요. 예를 들어 전환 전 레코드가 이랬다고 해볼게요.”됐다 안 됐다”는 네 가지 모양으로 갈라져요
DNS가 흔들린다고 말할 때 실제 모양은 하나가 아니에요. 처음에는 아래 네 갈래로 나눠보면 좋아요.
특히 두 번째 줄은 TTL 문제처럼 보이지만 아닐 수 있어요. A 레코드가 여러 개면 DNS는 여러 주소를 돌려줄 수 있고, 클라이언트는 IPv4와 IPv6 중 더 잘 닿는 쪽을 고르기도 해요. 이때는 “예전 값과 새 값이 섞였다”가 아니라 원래 여러 값을 주는 설정인지를 먼저 봐야 해요. 아래도 그 모양만 보여주는 합성 출력이에요.
없는 이름도 잠깐 기억될 수 있어요
DNS 전환에서 또 자주 헷갈리는 장면은NXDOMAIN이에요. 새 서브도메인을 만들기 전에 누군가가 먼저 조회했는데, 그때 “그런 이름 없음”이라는 답을 받아갔다고 해볼게요. 아래 역시 음성 캐시의 모양을 보여주기 위한 합성 출력이에요.
api-new.example.com 레코드를 만들었어요. 권한 DNS에는 이제 존재해요. 그런데 어떤 재귀 리졸버는 여전히 한동안 없다고 말할 수 있어요. 성공한 A 레코드만 캐시되는 게 아니라, 없는 이름이라는 답도 음성 캐시로 남을 수 있기 때문이에요.
RFC 2308은 이런 음성 응답 캐시의 동작을 정리해요. 운영자가 자세한 숫자를 볼 때는 응답의 SOA 정보와 리졸버별 남은 TTL을 같이 확인해야 해요.
잘못 읽기 쉬운 함정
DNS TTL 장애는 눈에 보이는 증상이 들쭉날쭉해서 결론을 빨리 내리기 쉬워요. 특히 아래 함정은 자주 나와요.
운영 채널에서는 “전파가 덜 됐다”는 말이 편해요. 하지만 실제로 조치해야 할 때는 조금 더 작게 말하는 편이 좋아요.
“권한 DNS는 새 값이고, 일부 재귀 리졸버가 예전 A 레코드를 남은 TTL 동안 캐시 중이에요.”이렇게 말하면 기다릴 문제인지, 설정을 고칠 문제인지, 사용자 안내를 해야 할 문제인지 훨씬 분명해져요.
실제 대응 순서는 이렇게 잡아요
DNS 플랩 의심 장면에서 바로 할 수 있는 대응 순서를 하나로 묶으면 이래요. 이 순서에서 중요한 건 도메인 이름과 타입을 고정하는 것이에요.www.example.com A를 보는 중에 갑자기 example.com AAAA나 api.example.com CNAME 이야기를 섞으면 판단이 흐려져요. DNS 문제는 이름과 타입이 조금만 달라도 완전히 다른 레코드예요.
실제 기록은 아래 정도면 시작하기 충분해요. 다만 아래 기록 자체는 형식을 보여주기 위한 합성 예시예요.
자, 정리해볼까요?
- DNS가 됐다 안 됐다 하는 것처럼 보여도, 실제로는 재귀 리졸버별 캐시 상태 차이일 수 있어요.
- 먼저 권한 DNS 원본과 재귀 리졸버 캐시를 나눠서 봐야 해요.
- TTL은 전환 예약 시간이 아니라, 이미 받아간 답이 얼마나 더 캐시될 수 있는지를 읽는 시간표예요.
- TTL을 낮추는 일은 전환 직전 버튼이 아니라, 기존 긴 캐시가 빠질 시간을 두는 준비 동작이에요.
-
없는 이름이라는
NXDOMAIN응답도 음성 캐시로 잠깐 남을 수 있어요.
이어서 보면 좋은 글
- DNS TTL과 캐시는 왜 바뀐 주소를 바로 안 보여줄까요? — TTL과 재귀 리졸버 캐시의 기본 동작을 더 차분히 보고 싶을 때 좋아요.
- dig 출력은 어디부터 읽어야 할까요? —
ANSWER,AUTHORITY,SERVER, TTL 줄을 도구 화면에서 직접 읽고 싶을 때 이어서 보면 좋아요. - DNS 재귀 조회와 반복 조회는 뭐가 다를까요? — 사용자가 권한 DNS에 직접 묻지 않는 이유와 재귀 리졸버의 역할을 다시 잡을 수 있어요.