서브도메인 탈취, 쓰지 않는 DNS 레코드를 정리하는 5단계

서브도메인 탈취는 이미 끝낸 서비스를 가리키는 DNS 레코드를 지우면 대부분 막을 수 있습니다. 이 글에서는 탈취가 생기는 구조와 위험, 쓰지 않는 DNS 레코드를 찾아 정리하는 5단계, 서비스를 끝낼 때 지킬 순서를 정리했습니다.

서브도메인 탈취는 어떻게 생기나

회사 도메인이 example.co.kr 이라면 event.example.co.kr, shop.example.co.kr 처럼 앞에 이름을 붙인 주소가 서브도메인입니다. 이벤트 페이지, 외부 쇼핑몰, 클라우드 저장소, 랜딩페이지 빌더처럼 다른 회사의 서비스를 우리 주소로 보여 주려고 DNS에 CNAME 같은 레코드를 추가하는 경우가 많습니다.

문제는 그 서비스를 해지한 뒤에도 DNS 레코드가 그대로 남아 있을 때입니다. 우리 서브도메인은 여전히 외부 서비스의 이름을 가리키는데, 그 이름의 주인이 비어 있는 상태가 됩니다. Microsoft는 현수 DNS 항목과 하위 도메인 인수 방지 안내에서 이렇게 남은 레코드를 "dangling DNS"라고 부르고, 다른 사람이 같은 이름의 자원을 만들어 우리 서브도메인의 내용을 통제할 수 있다고 설명합니다.

탈취되면 생기는 위험

• 우리 회사 주소에 엉뚱한 광고나 사기 페이지가 열려 회사 신뢰가 떨어집니다.
• 진짜 회사 주소처럼 보이므로 피싱 페이지로 쓰이기 쉽습니다.
• 사이트가 쿠키를 모든 서브도메인에 공유하도록 설정되어 있다면 로그인 정보가 노출될 위험이 커집니다.
• 주소에 보안 인증서까지 발급될 수 있어 방문자는 자물쇠 표시만 보고 안심하게 됩니다.

Mozilla의 MDN 서브도메인 탈취 문서도 같은 위험을 설명하며, 서비스를 끝낼 때는 DNS 레코드부터 지우라고 권합니다. 원인은 해킹 기술보다 정리하지 않은 설정이라는 점이 핵심입니다.

쓰지 않는 DNS 레코드 정리 5단계

작은 회사도 몇 년 운영하다 보면 누가 언제 만들었는지 모르는 레코드가 쌓입니다. 아래 순서로 한 번 정리해 두면 이후에는 바뀐 것만 관리하면 됩니다.

1. DNS 관리 화면 확인: 도메인 등록 업체나 DNS 서비스 관리 화면에서 모든 레코드를 내려받거나 화면을 캡처해 목록으로 만듭니다.
2. 용도 적기: 레코드마다 어떤 서비스에 쓰는지, 누가 요청했는지, 지금도 쓰는지 표에 적습니다. 메일(MX·TXT)과 홈페이지 본 주소처럼 꼭 필요한 레코드는 따로 표시합니다.
3. 연결 대상 확인: 각 서브도메인 주소를 직접 열어 보고, 외부 서비스 관리 화면에 그 주소가 아직 등록되어 있는지 확인합니다. 열리지 않거나 서비스 기본 오류 화면이 나오면 정리 후보입니다.
4. 삭제 또는 수정: 해지한 서비스를 가리키는 레코드는 지우고, 다른 곳으로 옮긴 서비스는 새 주소로 고칩니다. 지우기 전에 원래 값을 기록해 둡니다.
5. 정기 점검 일정 정하기: 분기나 반기마다 같은 표로 다시 확인하고, 담당자와 확인 날짜를 남깁니다.

그림의 3단계에서 판단이 어렵다면 바로 지우지 말고 레코드를 요청한 담당자나 외주 업체에 먼저 묻습니다. 메일 인증용 TXT 레코드처럼 화면으로 확인할 수 없는 레코드를 잘못 지우면 메일 발송에 문제가 생길 수 있습니다.

서비스를 끝낼 때 지킬 순서

탈취를 막는 가장 확실한 방법은 처음부터 레코드가 남지 않게 하는 것입니다. MDN은 서비스를 만들 때는 외부 서비스에 주소를 먼저 등록하고 DNS를 마지막에 추가하며, 끝낼 때는 반대로 DNS 레코드를 먼저 지우라고 안내합니다. 아래 표는 시작과 종료 때 순서를 비교한 것입니다.

구분	먼저 할 일	나중에 할 일
서비스 시작	외부 서비스에 우리 서브도메인 등록	DNS에 연결 레코드 추가
서비스 종료	DNS에서 연결 레코드 삭제	외부 서비스 해지·삭제
업체 변경	새 서비스 준비와 주소 등록	레코드를 새 주소로 수정 후 옛 서비스 해지

이벤트 페이지나 캠페인 사이트처럼 기간이 정해진 서비스는 만들 때부터 종료 날짜와 레코드 삭제 담당자를 정해 두면 잊어버리는 일을 줄일 수 있습니다. DNS 설정 화면에 들어가는 계정 자체를 지키는 방법은 DNS 관리 계정 보안에서 따로 다룹니다.

서브도메인 점검 체크리스트

정리를 마친 뒤에는 아래 항목을 정기 점검표에 넣어 두면 됩니다.

• DNS 레코드 목록에 레코드마다 용도와 담당자가 적혀 있다.
• 해지한 외부 서비스를 가리키는 CNAME 레코드가 없다.
• 모든 서브도메인을 열었을 때 우리 회사 화면이나 의도한 안내가 나온다.
• 외주 업체가 만든 레코드는 계약이 끝날 때 함께 정리했다.
• 사용하지 않는 MX 레코드가 엉뚱한 메일 서버를 가리키지 않는다.
• 도메인 연장과 DNS 관리 계정의 명의가 회사로 되어 있다.

마지막 항목처럼 도메인 명의와 연장 관리가 흔들리면 서브도메인보다 더 큰 문제가 생깁니다. 도메인 자체를 지키는 방법은 도메인 만료와 탈취 예방, 연장·잠금·명의 관리 6가지에 정리했습니다.

디코랩이 돕는 방식

디코랩은 운영 중인 사이트의 취약점을 점검하고 결과에 맞춰 조치 방향을 안내합니다. 서브도메인과 DNS 설정이 정리되어 있지 않다면 점검 범위에 함께 넣어 상담할 수 있습니다. 점검 서비스의 내용은 웹사이트 취약점 점검 서비스에서 확인할 수 있습니다.

자주 묻는 질문

서브도메인을 하나도 안 쓰면 걱정하지 않아도 되나요?

직접 만든 적이 없어도 예전 제작 업체나 직원이 추가한 레코드가 남아 있을 수 있습니다. DNS 관리 화면에서 실제 목록을 한 번 확인해 보는 것이 좋습니다.

레코드를 지우면 바로 반영되나요?

DNS 레코드에는 저장 유지 시간(TTL)이 있어서 바뀐 내용이 모든 곳에 퍼지기까지 시간이 걸릴 수 있습니다. 지운 뒤 하루 정도 지나 다시 주소를 열어 확인합니다.

이미 이상한 페이지가 열린다면 어떻게 하나요?

화면을 캡처해 기록을 남긴 뒤 해당 레코드를 바로 지우거나 우리 서비스로 바꿉니다. 로그인 쿠키가 공유되는 구조였다면 관리자 비밀번호도 바꾸고, 피해가 의심되면 KISA 118 상담을 받으세요.

와일드카드 레코드도 위험한가요?

모든 서브도메인을 한 곳으로 보내는 와일드카드 레코드는 그 대상이 사라지면 영향 범위가 넓어집니다. 꼭 필요한 경우에만 쓰고, 대상 서비스를 끝낼 때 함께 정리합니다.

DNS 레코드가 너무 많아 어디서부터 볼지 모르겠다면 도메인과 사용 중인 서비스를 적어 디코랩 프로젝트 문의로 보내 주세요.