CDN이 주소를 바꾸면 VPN 도메인 규칙이 깨진다

한 번의 조회에서 가져온 주소를 라우팅 규칙에 복사하면 사이트가 되고, 일주일 뒤에는 안 된다. 규칙에서 달라진 것은 없다. 서비스가 다른 에지 주소로 옮겨 갔거나, 클라이언트가 다른 호스트 이름을 확인했거나, 세션이 IPv6로 전환된 것이다. 앞에 놓인 결정은 이름 기반 규칙과 명시적 범위 중 어느 것이 이 서비스에 맞는 도구인가이며, 세 가지 조건이 그것을 정한다. 안정적인 것은 둘 중 하나뿐이므로 아래에서는 이름과 주소를 분리한다.

한 번의 조회가 목록이 아닌 이유

콘텐츠 전송 네트워크는 확인자, 지역, 그 순간에 맞춰 고른 주소로 응답한다. 다른 네트워크에서 두 번 물으면 다른 답을 받을 수 있다. 한 번만 묻고 그 답을 서비스의 주소 목록으로 취급하면, 쓴 규칙은 규칙이 아니라 스냅숏이 된다. DNS 응답을 설정으로 다루는 문제의 전부가 그것이다.

두 번째 틈이 있다. 눈에 보이는 호스트 이름 하나가 애플리케이션 전체를 덮는 경우는 드물며, 로그인, 미디어, API 트래픽은 흔히 별도 이름을 쓴다. 주소 표시줄의 호스트 이름으로 만든 규칙은 페이지를 덮고도 동영상을 놓칠 수 있으며, 이는 라우팅 오류가 아니라 부분 실패로 읽힌다.

세 번째 틈은 주소 계열이다. v4만을 위한 규칙은 클라이언트가 선호할 수 있는 AAAA 레코드에 대해 아무것도 말하지 않는다.

도메인 규칙과 범위를 가르는 세 가지 조건

첫째, 서비스가 소유하고 문서화할 수 있는 안정적인 프리픽스 집합을 공개하는가? 공개한다면 명시적 범위는 정직하고 저렴하다. 공개하지 않는다면 도메인 규칙만이 서비스를 따라갈 수 있는 방법이다.

둘째, 클라이언트의 도메인 방식은 갱신되는가? 연결할 때 한 번 확인하고 다시는 갱신하지 않는 규칙은 더 나은 브랜딩을 입은 스냅숏이다. 셋째, 그 방식이 하위 도메인과 두 주소 계열을 모두 덮는가, 아니면 입력한 이름만 덮는가?

이 셋에 답하면 선택은 대개 분명하다. 짐작은 시험에서는 되고 운영에서는 실패하는 규칙을 만든다.

페이지가 아니라 세션을 시험하라

페이지를 불러온 뒤 로그인하고, 재생을 시작하고, 파일을 업로드하는 중요한 동작을 수행한다. 각각은 다른 호스트에 닿을 수 있고, 실패하는 것은 규칙이 놓친 쪽이다.

페이지가 보여 주는 것이 아니라 세션이 실제로 접속하는 대상을 나열한다:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

한 확인자에서는 되고 다른 확인자에서는 실패하는 규칙은 터널이 아니라 CDN의 응답에 대해 말해 주므로, 비교하는 동안 확인자를 눈에 보이게 두라. 짧은 TTL은 기록한 응답에 유효 기간이 있다는 뜻이기도 하다.

각 방식이 실제로 덮는 범위

두 방식은 설정 화면에서는 맞바꿀 수 있어 보이지만 속으로는 다르게 동작한다.

커널 주소 경로는 프리픽스를 대조한다. 호스트 이름이 무엇인지 알지 못하므로 주소를 바꾸는 서비스를 따라갈 수 없다. 도메인 규칙은 이름을 확인해 결과를 라우팅하며, 서비스를 따라가지만 확인자, 갱신 동작, 하위 도메인에 대한 클라이언트의 처리에 의존하므로, 이름을 따르는 규칙은 클라이언트가 실제로 쓰는 확인자로 시험해야 한다.

어느 쪽도 다른 쪽의 상위 집합이 아니며, 그래서 메모 없이 섞으면 나중에 혼란이 생긴다.

서비스가 바뀐 뒤 다시 확인하라

클라이언트 업데이트나 서비스 변경 뒤에 같은 세션 시험을 다시 실행한다. 이전에 동작하던 주소 목록은 그 기간의 증거이지 서비스 인프라의 영구 목록이 아니다.

어느 방식이 어느 호스트 이름을 덮는지, 마지막으로 확인한 날짜와 함께 적어 둔다.

그 메모가 지킬 수 있는 규칙과 아무도 손대지 못하는 규칙의 차이다. 서비스가 자체 프리픽스 목록을 공개한다면 그것을 쓰고 날짜를 밝힌다. 공개하지 않는다면 그렇게 적고, 도메인 규칙을 갱신 동작과 나란히 적어 둔다.