도메인의 서버 주소를 바꿨는데 집에서는 새 사이트가 열리고 휴대전화에서는 예전 서버로 연결되는 상황을 생각해 봅시다. 두 기기가 같은 이름을 입력해도 서로 다른 DNS 캐시를 거쳤다면 결과가 잠시 다를 수 있습니다. 페이지를 다시 내려받는 HTTP 캐시와, 접속할 주소를 알아내는 DNS 캐시는 확인할 대상부터 다릅니다.
이 글은 가상의 도서관 호스트 www.library.example을 따라 이름 해석과 캐시의 관계를 살펴봅니다. 예시 이름과 시간표는 설명을 위해 만들었으며 실제 서비스의 응답을 측정하지 않았습니다. DNS가 주소를 알려주는 과정, 변경이 늦게 보이는 이유, 이름 해석 이후의 실패를 나누는 것이 목표입니다.
1. DNS에는 이름별로 여러 종류의 답이 있다
DNS는 도메인 이름에 연결된 정보를 종류별 레코드로 제공합니다. A는 IPv4 주소, AAAA는 IPv6 주소를 나타내며, 한 이름에 여러 주소가 있을 수도 있습니다. CNAME은 다른 이름을 가리키는 별칭이고, MX는 메일을 받을 서버, NS는 해당 영역의 권한 네임서버를 나타냅니다. 따라서 같은 이름을 물어도 요청한 레코드 종류가 다르면 답이 달라집니다.
Cloudflare의 DNS 레코드 설명처럼 CNAME의 값은 IP 주소가 아니라 다른 이름입니다. 주소가 필요하면 그 이름에 대한 해석이 이어질 수 있습니다. 또 https://www.library.example/books에서 DNS가 다루는 호스트 이름은 www.library.example입니다. /books라는 경로나 페이지 본문을 DNS에 등록하는 것은 아닙니다. CNAME을 설정해도 브라우저 주소창을 바꾸는 HTTP 리디렉션이 자동으로 생기지 않습니다.
2. 재귀 리졸버가 권한 서버를 찾아가는 과정
기기의 이름 해석 기능은 보통 설정된 재귀 리졸버에 답을 구합니다. 재귀 리졸버는 필요한 정보가 캐시에 있으면 이를 사용하고, 부족하면 다른 DNS 서버에 질의하여 최종 답이나 오류를 돌려줍니다. DNS 용어 표준 RFC 9499는 이렇게 대신 해석하는 역할과, 자신이 맡은 영역의 정보를 보유하는 권한 서버를 구분합니다. 한 서버가 어떤 역할로 응답하는지에 따라 답의 출처를 읽어야 합니다.
캐시와 중간 전달자가 없는 단순한 흐름이라면 리졸버는 루트에서 최상위 도메인의 서버를 안내받고, 그 서버에서 대상 영역의 권한 서버를 안내받습니다. 마지막 권한 서버에서 원하는 레코드나 별칭을 얻는 식입니다. 루트 서버 하나가 모든 웹사이트의 IP 주소를 보관하는 구조는 아닙니다. 실제로는 이미 저장한 위임 정보에서 시작하거나 다른 리졸버로 전달할 수 있으므로, 방문할 때마다 이 전체 순서를 반드시 반복하지는 않습니다.
3. TTL은 캐시에 남은 시간이지 전 세계의 시계가 아니다
레코드의 TTL은 초 단위로 전달되는 캐시 수명 정보입니다. 일반적인 캐시 응답에서는 저장해 둔 동안 남은 시간이 줄어듭니다. 예를 들어 리졸버가 10시 정각에 TTL 300초인 주소를 저장했다면, 같은 저장본을 10시 2분에 답할 때 남은 TTL은 약 180초입니다. 아래는 재조회·미리 갱신·오래된 응답 제공을 하지 않는 리졸버 하나를 가정한 시간표입니다.
| 가상 시각 | 권한 서버의 주소 | 이 리졸버의 처리 |
|---|---|---|
| 10:00 | 이전 주소 | 이전 주소를 TTL 300초로 저장 |
| 10:01 | 새 주소로 변경 | 저장본에는 아직 240초가 남음 |
| 10:03 | 새 주소 | 남은 120초 동안 이전 주소를 재사용할 수 있음 |
| 10:05 이후 첫 질의 | 새 주소 | 만료된 저장본 대신 다시 조회하여 새 주소를 얻는다고 가정 |
다른 리졸버는 이 레코드를 더 늦게 저장했거나 아직 한 번도 보지 않았을 수 있습니다. 갱신 시점이 서로 달라 전 세계 사용자가 동시에 바뀌는 순간을 TTL 하나로 정할 수 없습니다. 캐시는 만료 전에 자료를 버릴 수도 있으며, 웹페이지를 새로고침했다고 공유 리졸버의 저장본까지 삭제되지는 않습니다. TTL은 DNS 응답의 재사용을 이해하는 단서이지 웹 연결이나 화면 갱신 전체의 제한 시간이 아닙니다.
4. TTL을 낮추는 시점과 ‘없다’는 답의 캐시
이전 주소를 TTL 3,600초로 받아 간 캐시는 운영자가 지금 TTL을 60초로 낮춰도 그 사실을 즉시 전달받지 않습니다. 예정된 주소 변경이라면 미리 TTL을 조정하고, 기존의 긴 수명으로 저장된 응답이 남을 시간을 고려해야 합니다. 낮은 TTL은 변경을 더 자주 확인하게 할 수 있지만 질의 부담과 권한 서버에 대한 의존도도 높입니다. 모든 서비스에 같은 짧은 숫자를 적용하기보다 변경 계획과 장애 대응을 함께 검토합니다.
존재하지 않는 이름이라는 NXDOMAIN이나, 이름은 있지만 요청한 종류의 레코드가 없다는 NODATA도 캐시될 수 있습니다. 부정 캐시 표준 RFC 2308은 권한 서버의 SOA 레코드 TTL과 SOA의 MINIMUM 값 중 작은 값을 부정 응답의 캐시 수명에 사용하도록 정의합니다. 따라서 없던 호스트를 추가한 직후에도 이전의 ‘없다’는 답이 남을 수 있습니다. 새 A 레코드의 TTL만 보고 그 답의 수명까지 같다고 생각하면 원인을 놓칩니다.
5. 같은 이름·종류·서버를 고정해서 확인하기
확인 기록에는 질의한 정확한 이름, A 또는 AAAA 같은 종류, 질의한 DNS 서버와 시각을 함께 적습니다. dig가 설치된 환경이라면 dig example.com A처럼 이름과 종류를 명시할 수 있습니다. 실제 문제를 조사할 때는 example.com을 본인이 확인할 호스트로 바꿉니다. 이 명령은 실행 절차의 예시이며 이 글에서 실제 실행하거나 응답 시간을 측정한 기록은 아닙니다.
응답의 상태, ANSWER에 들어 있는 이름·종류·값·TTL을 함께 봅니다. 동일한 리졸버에 같은 질의를 다시 보냈을 때 TTL이 줄어드는지 살피되, 값이 늘었다고 바로 오류로 판단하지 않습니다. 미리 갱신했거나 여러 캐시 노드 중 다른 노드가 응답했을 수도 있습니다. A와 AAAA의 결과를 섞지 않고 각각 기록하면 어느 주소 계열에 차이가 있는지 구분하기 쉽습니다.
운영자라면 사용 중인 재귀 리졸버의 답과 관리 영역의 권한 서버 답을 같은 이름·종류로 비교할 수 있습니다. 차이가 있으면 캐시 잔여 시간, 권한 서버 간 자료 일치, 위임 설정을 차례로 점검합니다. 한 공개 리졸버의 답을 모든 이용자의 상태로 일반화하지 않습니다. 회사망의 내부 DNS나 브라우저의 별도 DNS 설정은 조회 경로를 바꿀 수 있으므로, 비교할 때는 접속 환경도 함께 남깁니다.
6. DNS 오류와 연결 오류, 예외를 나누어 읽기
NXDOMAIN은 이름이 없다는 응답이고, NODATA는 요청한 레코드 종류가 없다는 경우입니다. 반면 SERVFAIL은 서버가 질의를 처리하지 못했다는 실패이며, 시간 초과는 정해진 대기 안에 답을 받지 못한 관찰입니다. 이들을 모두 ‘도메인이 삭제됐다’고 해석해서는 안 됩니다. 응답 코드가 있었는지, 어느 서버에 물었는지를 먼저 보존해야 다음 확인 대상을 정할 수 있습니다.
TTL이 지났는데 이전 답이 보인다고 언제나 규칙 위반은 아닙니다. RFC 8767의 serve-stale 방식은 권한 서버에서 갱신할 수 없는 예외 상황에서 만료된 정보를 활용해 가용성을 높이는 방법을 정의합니다. 모든 리졸버가 이를 같은 설정으로 사용한다는 뜻은 아닙니다. 따라서 단일 TTL 값만으로 변경 반영 시간을 단정하기보다 실제 사용한 리졸버의 동작을 확인합니다.
마지막으로 주소가 정상 조회되어도 웹사이트 접속 성공이 보장되지는 않습니다. 그 주소로 가는 네트워크, TLS 인증서, 웹서버와 애플리케이션은 별도의 단계입니다. DNS 답은 기대한 주소인데 페이지가 열리지 않는다면 그다음 연결 단계로 조사 범위를 옮깁니다. 이름 해석의 답과 웹 응답을 각각 기록하면, 페이지 캐시를 지우거나 DNS 설정을 무작정 바꾸기 전에 실패한 지점을 더 정확히 좁힐 수 있습니다.