대규모 도메인 포트폴리오의 DNS 변경 모니터링

지역별 사이트가 수십 개인 기업, 방대한 감시 목록을 추적하는 보안팀, 고객 인프라를 관리하는 에이전시처럼 많은 도메인을 책임지는 팀은 개별 점검으로는 감당할 수 없는 문제에 부딪힙니다. 각 도메인을 주기적으로 수동 재확인하는 일은 너무 번거로워 결국 꾸준히 이루어지지 않게 되고, 어떤 변경이 마땅히 알아챘어야 할 시점보다 오래 방치되고 나서야 문제가 드러납니다.

실제로 지켜봐야 할 신호

지속 가능하게 만들기

실용적인 해법은 사람이 기억해서 해야 하는 일이 아니라 자체 일정으로 실행되는 작업으로 점검을 바꾸는 것입니다. 전체 포트폴리오를 일정한 간격(매시간, 매일 등 의미 있는 변경이 일어나는 빈도에 맞는 주기)으로 다시 조회하고 지난번과 달라진 부분만 보여 주는 반복 작업을 두면, 쉽게 건너뛰는 수작업이 수동적인 안전망으로 바뀝니다. 여기에 CSV나 JSON으로 내보낼 수 있는 결과를 더하면 실행 결과를 이전 결과와 비교하기 쉬워져, 긴 목록을 눈으로 훑지 않고도 변동을 자동으로 포착할 수 있습니다.

이 방식이 잡아내는 특정 위험: 대규모의 댕글링 DNS

대규모 도메인 포트폴리오에는 코드베이스에 죽은 코드가 쌓이듯 오래된 서브도메인이 쌓입니다. 마케팅 캠페인의 랜딩 페이지 서브도메인, 폐기된 스테이징 환경, 갱신되지 않은 SaaS 체험판을 가리키는 CNAME 같은 것들입니다. 이런 서브도메인이 가리키던 서비스를 다른 사람이 차지할 수 있게 되면 각각이 서브도메인 탈취의 표적이 될 수 있습니다. 예약 실행되는 포트폴리오 전체 모니터링은 공격자보다 먼저 이런 변동을 잡아낼 수 있는 몇 안 되는 실용적 방법입니다. 예전에는 문제없이 확인되던 서브도메인이 이제 오류를 내거나 낯선 제공업체로 확인된다면, 다시 한번 살펴볼 만한 바로 그 신호입니다.

조직에서는 누가 이를 맡게 되는가

포트폴리오 전체의 DNS 모니터링은 흔히 팀 사이의 빈틈에 놓입니다. 인프라팀은 자신이 운영하는 서비스에 연결된 도메인을 소유하고, 마케팅이나 그로스팀은 인프라팀을 꼭 거치지 않고 캠페인 서브도메인을 만들며, 보안팀은 변경 권한 없이 이 모든 것을 볼 수 있기를 원합니다. 현실적인 방법은 모니터링 작업 자체를 보안팀이나 플랫폼 엔지니어링 팀이 소유하고 일정에 따라 실행하는 공유 읽기 전용 서비스로 보고, 실제로 변경된 도메인을 가진 팀으로 알림을 보내는 것입니다. 아무도 전체 소유 현황을 최신 상태로 파악하지 못하는 포트폴리오를 어느 한 팀이 수동으로 다시 확인해 주리라 기대하는 것보다 낫습니다.

추측이 아니라 목록에서 시작하기

흔히 건너뛰는 단계가 바로 감시할 가치가 있는 도메인의 실제 목록을 만드는 일입니다. 레지스트라와 DNS 제공업체의 대시보드는 한 계정에 속한 모든 도메인을 보여 주지만, 대규모 조직에는 인수합병, 캠페인, 중앙에서 추적하지 않은 팀 단위 구매를 거치며 수년간 쌓인 도메인이 여러 레지스트라와 제공업체에 흩어져 있는 경우가 많습니다. 불완전하더라도 전체 목록을 한 번 모아 지속적인 모니터링의 기준 목록으로 삼는 것이, 누군가 우연히 기억하던 일부 도메인만 지켜보는 기술적으로 정교한 모니터링 환경보다 더 가치가 있습니다.