서버 IP 를 바꾸기 이틀 전에, DNS 이전 TTL 점검 목록

이 목록은 레코드를 바꾸는 날이 아니라 그 이틀 전에 폅니다

DNS 이전에서 생기는 사고는 대개 명령을 잘못 쳐서가 아닙니다. 순서가 틀려서 납니다. 레코드 값은 정확히 넣었는데, 그 값이 퍼지는 속도를 계산하지 않은 거죠.

리졸버는 한 번 받은 답을 TTL 초만큼 들고 있다가 그 뒤에야 다시 묻습니다. 그 사이 권한 서버에서 값을 바꿔도 리졸버는 모릅니다. 옛 답을 들고 있는 동안에는 옛 서버로 사람을 보냅니다.

그래서 이 목록을 펴는 시점은 서버 이전, 호스팅 변경, 네임서버 이전, 로드밸런서 교체처럼 이름이 가리키는 곳이 바뀌는 작업의 일정을 잡는 날입니다. 이틀이라고 쓴 이유는 아래 위임 TTL 항목에서 나옵니다.

항목 대부분은 dig 한 줄이면 끝납니다. 다만 결과를 보고 기다려야 하는 시간이 생기니, 작업 당일에 처음 보면 늦습니다.

레코드를 바꾸는 건 일 초면 끝나지만, 옛 답이 사라지는 데는 옛 TTL 만큼 걸립니다.

지금 걸린 TTL 을 먼저 읽어야 낮출 시점이 나옵니다

첫 확인은 현재 레코드의 TTL 입니다. dig 출력에서 이름 바로 뒤에 붙은 숫자가 초 단위 TTL 입니다. 300 이면 오 분, 86400 이면 하루입니다.

이때 어디에 묻느냐에 따라 숫자가 달라집니다. 동네 리졸버에 물으면 캐시에 남은 시간이 나와서 매번 줄어든 값이 보입니다. 원래 설정값을 보려면 그 도메인의 권한 네임서버에 직접 물어야 합니다.

TTL 을 낮추는 건 이전 작업의 준비 운동입니다. 그런데 여기서 흔히 놓치는 게 하나 있습니다. TTL 을 3600 에서 60 으로 내려도, 이미 3600 짜리 답을 받아 간 리졸버는 그 한 시간을 다 채운 뒤에야 새 TTL 을 받습니다. 그러니 낮춘 다음 적어도 옛 TTL 만큼은 기다렸다가 진짜 값을 바꿔야 합니다.

Cloudflare 를 쓴다면 한 가지를 더 봅니다. 프록시를 켠 레코드는 TTL 이 Auto, 곧 300초로 고정이라 손댈 수 없습니다. 프록시를 끈 DNS 전용 레코드는 일반 요금제에서 60초부터 하루 사이로 고릅니다.

# 권한 네임서버부터 찾는다
dig +short example.com NS

# 그 서버에 직접 물어 설정된 TTL 을 본다 (두 번째 칸이 TTL)
dig +noall +answer @alex.ns.cloudflare.com example.com A
# example.com.  3600  IN  A  203.0.113.10

리졸버가 아니라 권한 서버에 물어야 원래 TTL 이 보입니다

새로 만들 이름은 미리 조회해 보지 않는 게 낫습니다

이전 작업에서는 api2 나 new 같은 새 서브도메인을 만드는 일이 잦습니다. 레코드를 만들기 전에 확인 삼아 그 이름을 조회해 보면, 리졸버는 그런 이름이 없다는 답을 캐시에 넣습니다.

이 없다는 답에도 수명이 있습니다. 네거티브 캐시의 TTL 은 그 존 SOA 레코드의 MINIMUM 칸과 SOA 자체의 TTL 중 작은 쪽으로 정해집니다. 이 값이 한 시간이면, 방금 레코드를 만들었어도 그 리졸버에서는 한 시간 동안 이름이 없다고 나옵니다.

그래서 SOA 의 마지막 숫자와 SOA 의 TTL 을 미리 확인해 둡니다. 둘 중 작은 값이 새 이름을 만든 뒤 최악으로 기다려야 할 시간입니다. 가장 깔끔한 건 레코드를 먼저 만들고 그다음에 조회하는 순서를 지키는 겁니다.

dig +noall +answer example.com SOA
# example.com. 1800 IN SOA ns.example. hostmaster.example. 2416587357 10000 2400 604800 1800
#               ^ SOA 의 TTL                                              맨 끝이 MINIMUM ^
# 네거티브 캐시는 둘 중 작은 값만큼 남는다

없는 이름을 먼저 물으면 그 '없음' 이 SOA 기준만큼 캐시에 남습니다

네임서버를 옮기는 날에는 내가 못 줄이는 TTL 이 있습니다

A 레코드만 바꾸는 이전과 네임서버 자체를 다른 업체로 옮기는 이전은 기다리는 시간이 다릅니다. 네임서버 위임 정보는 내 존이 아니라 상위 존, 이를테면 .com 서버에 들어 있기 때문입니다.

.com 서버가 돌려주는 위임 NS 레코드의 TTL 은 172800초, 이틀입니다. 이 값은 등록 대행사에서 네임서버를 바꿔도 내가 줄일 수 없습니다. 이 글 제목에 이틀이 들어간 이유가 이겁니다.

그래서 네임서버 이전에서는 옛 네임서버와 새 네임서버가 최소 이틀 동안 같은 레코드를 내주도록 겹쳐 둬야 합니다. 옛 업체 계정을 바로 해지하면 아직 옛 위임을 들고 있는 리졸버가 갈 곳을 잃습니다.

# 상위 존(.com) 서버에 재귀 없이 직접 묻는다
dig +norecurse @a.gtld-servers.net example.com NS
# ;; AUTHORITY SECTION:
# example.com.  172800  IN  NS  alex.ns.cloudflare.com.

# 옛·새 네임서버가 같은 값을 주는지 나란히 비교
for ns in old-ns1.example.net alex.ns.cloudflare.com; do
  echo "== $ns"; dig +short @"$ns" example.com A
done

위임 TTL 은 상위 존이 정합니다. 겹쳐 두는 기간을 여기에 맞춥니다

A 레코드만 옮기면 메일과 인증서가 따라오지 않습니다

새 업체로 존을 옮길 때 눈에 보이는 웹사이트 레코드만 다시 만들고 끝내기 쉽습니다. 그러면 MX 가 빠져 메일이 사라지고, SPF·DKIM 같은 TXT 가 빠져 보낸 메일이 스팸함으로 갑니다. 이건 웹 화면으로는 전혀 티가 나지 않습니다.

인증서 쪽에서는 CAA 레코드가 함정입니다. CAA 가 있으면 인증기관은 그 목록에 자기가 없을 때 인증서를 내주면 안 됩니다. 새 서버에서 다른 인증기관을 쓰기로 했는데 옛 CAA 를 그대로 옮겨 오면, 발급 요청이 거절됩니다.

CAA 는 요청한 이름에 없으면 상위 이름으로 올라가며 찾습니다. www 에는 CAA 를 안 넣었어도 루트 도메인에 있으면 그게 적용됩니다. 그러니 서브도메인만 보지 말고 루트까지 올라가서 확인해야 합니다.

가장 확실한 방법은 옮기기 전에 옛 존에서 레코드 종류별로 전부 뽑아 두고, 옮긴 뒤 새 네임서버에 같은 질문을 던져 한 줄씩 대조하는 겁니다.

# 옛·새 권한 서버에 같은 질문을 던져 결과를 비교한다
for t in A AAAA MX TXT CAA; do
  for ns in old-ns1.example.net alex.ns.cloudflare.com; do
    printf '%s %-5s %s\n' "$ns" "$t" "$(dig +short @$ns example.com $t | sort | tr '\n' ' ')"
  done
done

웹 레코드만 맞고 MX·TXT·CAA 가 다르면 메일과 인증서가 조용히 깨집니다

CAA 가 새 인증기관을 막고 있으면 인증서 갱신이 실패하는데, 그건 이전하고 한참 뒤에야 드러납니다.

이 정도면 통과라고 볼 수 있는 상태

작업 당일에 레코드를 바꾸기 전, 아래가 모두 맞으면 진행해도 됩니다. 바꿀 레코드의 TTL 이 이미 낮은 값이고, 낮춘 시각에서 옛 TTL 만큼 시간이 지났습니다. 새로 만들 이름은 아직 아무도 조회하지 않았거나, 조회했더라도 SOA 기준 시간이 지났습니다.

네임서버까지 옮기는 경우라면 옛 네임서버와 새 네임서버가 모든 레코드 종류에서 같은 값을 내주고, 그 상태를 이틀 이상 유지할 계획이 서 있어야 합니다.

마지막으로 옛 서버를 끄는 시점입니다. 값을 바꾼 뒤 적어도 바꾸기 전 TTL 만큼, 여유 있게 그 몇 배를 더 살려 두고 접속 로그로 옛 서버에 아직 사람이 오는지 봅니다. 요청이 끊긴 걸 확인한 다음에 끄면 됩니다.

조치 후 확인할 것

DNS 이전은 바꾸는 작업보다 기다리는 작업에 가깝습니다. 언제 무엇을 바꾸고 얼마나 기다릴지를 TTL 숫자로 미리 계산해 두면, 당일에는 값 하나 고치고 로그만 지켜보면 됩니다.