빠른 답변
방어적 도메인을 메인 사이트로 어떻게 리디렉션하나요?
각 방어적 도메인과 www 이름을 영구 301 리디렉션으로 메인 사이트의 HTTPS 주소에 연결한 다음 curl -I로 결과를 확인하십시오. Wardmint는 모든 도메인에 무료 URL 포워딩을 포함하므로, 연 $128.94의 6개 확장자 기본 세트는 포워딩을 포함해 확장자당 평균 $21.49입니다.
방어적 도메인을 메인 사이트로 보내는 방법
| 산정 방식 | 이용 방법 | 서버 필요 | 방어적 이름의 HTTPS | 적합한 경우 |
|---|---|---|---|---|
| 등록기관의 URL 포워딩 | 등록기관의 서비스가 리디렉션으로 응답 | 아니요 | 서비스에 따라 다르므로 테스트하십시오 | 대부분의 방어적 도메인 |
| 자체 웹 서버에서 리디렉션 | 서버 규칙이 메인 사이트로 301을 반환 | 예 | 예, 직접 관리하는 인증서 필요 | 완전한 제어가 필요한 도메인 |
| DNS만 사용(호스트로 A 또는 CNAME) | 이름이 호스트를 가리키고 호스트가 리디렉션 | 예, 호스트에서 | 예, 호스트가 인증서를 발급하는 경우 | 이미 많은 이름을 제공하는 호스트 |
| 리디렉션 없음, 이메일 없이 주차 | 이름이 아무것으로도 해석되지 않고 메일도 보내지 않음 | 아니요 | 해당 없음 | 보유만 하려는 이름 |
방어적 도메인을 왜 굳이 리디렉션해야 하나요?
리디렉션은 오타를 실제 사이트 방문으로 바꾸고, 이름이 빈 자리로 남지 않게 합니다. 사용자는 주소를 잘못 입력하거나, 부주의하게 쓴 링크를 따라가거나, 검색을 통해 변형에 도달합니다. 변형이 내 것이고 응답하면 사용자는 공식 사이트에 도착합니다.
리디렉션하는 도메인은 신뢰에도 도움이 됩니다. 오류 페이지를 보여 주는 방어적 이름은 버려진 것처럼 보이고, 버려진 유사 도메인은 사용자에게 설명하기 어렵습니다. 항상 공식 사이트에 도착하는 이름은 그 주소가 내 것임을 사용자에게 알려 줍니다.
리디렉션은 작업의 웹 쪽 절반입니다. 메일 쪽 절반은 별도의 레코드 모음이며 미사용 도메인의 이메일 사칭을 막는 방법에서 다룹니다. Wardmint는 전체 방어 접근법을 타이포스쿼팅으로부터 브랜드를 보호하는 방법에서 설명합니다.
어떤 리디렉션 유형을 사용해야 하나요?
영구 리디렉션을 사용하십시오: 상태 301 Moved Permanently 또는 308 Permanent Redirect. 둘 다 HTTP 의미를 정의하는 RFC 9110에 있으며, 둘 다 클라이언트에게 리소스가 이제 Location 헤더의 주소에 있음을 알려 줍니다.
영구 리디렉션은 관계가 오래 지속되도록 의도된 방어용 도메인에 적합합니다. 임시 리디렉션(302 또는 307)은 클라이언트가 이전 주소를 계속 확인하도록 하므로, 캠페인 페이지에는 맞지만 상시 변형에는 맞지 않습니다. 항상 사용자를 최종 주소, 즉 기준 메인 사이트의 HTTPS 주소로 한 단계에 보내십시오. 리디렉션이 두세 번 이어지면 공격자가 끼어들 곳이 늘고 사용자가 느려집니다.
메인 페이지 또는 존재하는 페이지로 보내십시오. 지갑 연결이나 서명을 요청하는 페이지로는 방어용 도메인을 절대 리디렉션하지 마십시오. 오타는 거래가 아니라 정보 페이지에서 끝나야 합니다. Wardmint는 클라이언트 영역에서 무료 URL 포워딩 및 이메일 포워딩를 제공합니다.
리디렉션만 하는 도메인에 HTTPS가 중요한 이유는 무엇인가요?
일반 HTTP로 전송된 리디렉션은 도중에 변조될 수 있기 때문입니다. 변형을 입력한 사용자는 먼저 HTTP 버전에 도달할 수 있습니다. 그 HTTP 응답이 리디렉션이라면 네트워크 경로상의 누구든 Location 헤더를 바꿀 수 있으므로, 안전한 설계는 방어적 이름에 대한 유효한 인증서와 함께 HTTPS로 응답하는 것입니다.
이는 CAA 레코드에 영향을 줍니다. 리디렉션하는 방어적 도메인에는 인증서가 필요하므로 CAA 집합이 이를 발급하는 기관을 허용해야 하고, 아무것도 제공하지 않는 주차된 도메인은 발급을 금지할 수 있습니다. 구문은 CAA 레코드 설정 방법에 있습니다. 서비스를 통해 포워딩한다면 서비스마다 지원이 다르므로 의존하기 전에 HTTPS 이름을 테스트하십시오.
2026년 11월 12일 Wardmint의 조사에 따르면, .com, .net, .org, .io, .xyz, .app 기본 세트는 도메인 6개에 연 $128.94로 평균 개당 $21.49이며, 6개 모두 포워딩은 무료입니다.
여섯 단계로 방어적 도메인을 리디렉션하는 방법
목적지 선택
www 사용 여부를 포함하여 메인 사이트의 정확한 HTTPS 주소를 고르고, 모든 방어적 이름에 그 주소를 사용하십시오.
포워딩 설정
고객 영역에서 도메인의 URL 포워딩을 목적지로 설정하십시오. 도메인의 www 이름에도 반복하십시오.
영구 리디렉션 사용
서비스에서 선택할 수 있다면 영구 리디렉션(301)을 선택하십시오. 자체 서버에서 리디렉션한다면 Location 헤더와 함께 301을 반환하십시오.
인증서 확인
방어적 이름을 HTTPS로 열어 리디렉션 전에 브라우저가 경고를 표시하지 않는지 확인하십시오.
curl로 테스트
도메인과 www 이름의 http 및 https 버전에 curl -I를 실행하고 상태와 Location 헤더를 읽으십시오.
이메일 없음 레코드 추가
null MX, SPF, DMARC 레코드를 게시하여 리디렉션하는 도메인이 메일 사칭에 쓰이지 않게 하십시오.
curl -sI http://example-variant.com | head -n 5
curl -sI https://example-variant.com | head -n 5
curl -sI https://www.example-variant.com | head -n 5어떤 실수가 방어적 리디렉션을 망가뜨리나요?
흔한 실수는 www 이름 누락, 리디렉션 연쇄, 잊어버린 만료입니다. 많은 사용자가 www를 입력하므로 www 없는 이름과 www 이름 모두 포워딩하십시오. 두 번째 방어적 도메인을 거치지 말고 최종 주소로 바로 리디렉션하십시오.
세 번째 실수는 도메인이 만료되게 두는 것입니다. 만료된 방어적 이름은 다른 사람이 등록할 수 있고, 한때 사용자를 보호하던 리디렉션이 함정이 됩니다. 도메인 만료를 막는 방법에 설명된 대로 잔액에서 자동 갱신을 켜고 잔액을 유지하십시오.
마지막으로, 메인 주소가 바뀌면 모두 업데이트할 수 있도록 모든 방어적 도메인과 그 목적지의 목록을 유지하십시오. 예산이 포함된 목록 작성 방법은 브랜드의 방어적 도메인 목록 작성 방법에 있습니다.
방어적 도메인 리디렉션에 관한 질문
방어적 도메인에는 301과 302 중 어느 것이 나은가요?
관계가 영구적이므로 301이 낫습니다. 302는 이동이 임시라고 클라이언트에 알리므로 짧은 캠페인에 맞습니다.
방어적 도메인마다 호스팅이 필요한가요?
아니요. 등록기관의 URL 포워딩은 서버 없이 응답합니다. 응답을 직접 제어해야 할 때만 자체 서버를 사용하십시오.
방어적 도메인은 홈페이지로 리디렉션해야 하나요, 특정 페이지로 해야 하나요?
홈페이지나 안내 페이지로 보내십시오. 지갑 연결이나 서명을 요구하는 페이지는 피하십시오.
Wardmint는 URL 포워딩에 요금을 부과하나요?
아니요. 모든 도메인에 무료 URL 포워딩이 포함되며, 이메일 없음 DNS 템플릿과 함께 사용할 수 있습니다.
방어적 이름에 웹 트래픽이 전혀 없기를 원하면 어떻게 하나요?
웹 서비스 없이 주차해 두고 이메일 없음 레코드를 게시하십시오. 발급을 금지하는 CAA 레코드도 고려하십시오.
요약
- 방어적 도메인은 한 번의 영구 리디렉션으로 사용자를 실제 사이트에 도착시켜야 합니다.
- 정식 메인 사이트의 HTTPS 주소로 301(또는 308)을 사용하십시오.
- www 없는 이름과 www 이름을 모두 리디렉션하십시오.
- 리디렉션하는 도메인에는 인증서가 필요하고, 주차된 도메인은 CAA로 발급을 금지할 수 있습니다.
- http, https, www에 curl -I로 테스트하십시오.
- Wardmint의 URL 포워딩은 무료이며, 기본 세트는 확장자당 평균 $21.49입니다.
- 이메일 없음 레코드를 추가하고 자동 갱신을 켜 두십시오.
출처 (2)
- RFC 9110: HTTP Semantics — IETF / RFC Editor (2026-11-12 확인)
- RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record — IETF / RFC Editor (2026-11-12 확인)