롤백 경로를 갖춘 DNS 레코드 변경: TTL 낮추기, 전환, 검증

목표

호스트명을 새 주소나 새 공급자로 옮기되, 일부 사용자가 죽은 대상에 접속하게 되는 구간이 생기지 않도록 하고, 수 시간이 아니라 수 분 안에 되돌릴 수 있도록 합니다.

전제 조건

권한 있는 존(authoritative zone)에 대한 쓰기 권한, 권한 있는 서버와 공개 리졸버를 직접 조회할 수 있는 방법(dig @server name type), 그리고 주소나 임시 이름으로 이미 서비스 중이며 테스트를 마친 새 대상.

단계

1. 현재 TTL을 확인합니다. RFC 1035는 TTL을 레코드를 다시 소스에 확인하러 가기 전까지 캐시할 수 있는 시간 간격으로 정의합니다. 레코드를 보유한 캐시는 변경 후에도 최대 그 시간만큼 계속 이전 값을 유지합니다.
2. TTL을 몇 분(예: 300초)으로 낮추고, 기존 TTL 한 주기 전체만큼 기다립니다. 그래야 긴 TTL을 가지고 있던 모든 캐시가 만료되어 짧은 TTL로 다시 가져오게 됩니다. 이 대기를 건너뛰는 것이, 변경이 하루 동안 "전파"되는 것처럼 보이는 흔한 원인입니다.
3. 롤백을 준비합니다. 기존 레코드 값을 정확히 기록해 두고, 기존 대상은 그동안 계속 가동해 둡니다.
4. 변경을 실행합니다. 먼저 권한 있는 서버를 확인하고, 그다음 공개 리졸버, 그다음 로컬 네트워크의 리졸버 순으로 확인합니다.
5. 새 대상의 로그에서 트래픽이 들어오는지, 기존 대상의 로그에서 트래픽이 짧은 TTL에 걸쳐 줄어드는지 지켜봅니다. TTL보다 오래 조용해질 때까지는 기존 대상을 멈추지 않습니다. RFC 8767은 권한 있는 서버에 연결할 수 없는 재귀 리졸버가 TTL이 만료된 데이터로도 계속 응답할 수 있도록 허용하며, 최대 stale 타이머로 1일에서 3일 사이를 제안합니다. 이는 권한 있는 서버에 연결할 수 없을 때만 문제가 되므로, 공급자 장애 중에는 DNS를 변경하지 말아야 하는 근거가 됩니다.
6. 기존 대상이 조용해지면 TTL을 원래 값으로 다시 올립니다. 롤백은 같은 편집을 반대로 적용하는 것이며 적용까지 짧은 TTL 한 주기가 걸립니다. 확인이 끝날 때까지 TTL을 낮게 유지하는 이유가 여기에 있습니다.
7. 변경 캘린더에 두 레코드 값과 각각의 시각을 모두 기록합니다.

기대 결과

변경 후 몇 분 안에 트래픽이 이동하고, 어떤 사용자도 죽은 대상에 접속하지 않으며, 되돌리는 작업은 레코드 편집 한 번과 예측 가능한 최악의 지연 시간으로 끝납니다.

한계와 검증 근거

일부 클라이언트는 TTL을 무시합니다. 장기 연결, 런타임 주소 캐시, 기업용 프록시 등이 그렇고, 이런 경우에는 재시작하거나 자체 만료 시점을 기다려야 합니다. 아직 존재하지 않는 이름에 대한 네거티브 캐싱은 별도의 TTL을 가지며, RFC 2308은 이를 SOA 레코드의 MINIMUM 필드와 SOA 자체 TTL 중 더 작은 값으로 정합니다. 이 절차는 인용된 RFC를 따른 것이며, TTL 계산을 넘어서는 전파 시간에 대해서는 어떠한 주장도 하지 않습니다.