1. 라이브러리
  2. DNS
  3. DNS 설정

업데이트됨 1개월 전

SaaS 애플리케이션을 운영하면서 모든 고객에게 고유한 서브도메인을 제공한다고 상상해보세요: acme.yourapp.com, techcorp.yourapp.com, startup47.yourapp.com. 고객이 10,000명이라면, DNS 레코드도 10,000개를 만들어야 할까요?

하나만 만들면 됩니다.

와일드카드 DNS 레코드는 별표(*)를 사용해서 자체 레코드가 없는 모든 서브도메인을 처리합니다. DNS 존 파일 문법으로는 이렇게 씁니다:

*.example.com.  3600  IN  A  192.0.2.100

이 별표가 모든 것을 받아냅니다. 누군가 anything.example.com을 요청하면, DNS 서버가 확인합니다: anything.example.com에 자체 레코드가 있는가? 없으면? 와일드카드가 응답합니다.

이렇게 생각하면 됩니다

와일드카드는 기본 케이스입니다—switch 문의 default나 조건 체인 끝의 else와 같습니다. 더 구체적인 것이 아무것도 매칭되지 않을 때만 작동합니다.

이렇게 보면, 매칭 규칙이 자연스럽게 이해됩니다:

구체적인 레코드가 항상 우선합니다. *.example.comapp.example.com이 둘 다 있다면, app.example.com 쿼리는 구체적인 레코드를 사용합니다. 와일드카드는 명시적인 설정을 절대 덮어쓰지 않습니다. (default 케이스는 다른 케이스가 매칭되면 실행되지 않는 것과 같습니다.)

와일드카드는 정확히 한 단계만 매칭합니다. *.example.comapp.example.com은 매칭하지만 api.app.example.com은 매칭하지 않습니다. 이는 임의적인 규칙이 아닙니다—조직적 경계를 반영합니다. 서브도메인은 그 소유자가 더 세분화할 수 있고, 상위 도메인이 자동으로 그 하위 서브도메인까지 가져가지 않습니다. *.app.example.com도 잡아야 한다면, 해당 레코드를 따로 만드세요.

와일드카드는 루트 도메인(apex)을 매칭하지 않습니다. *.example.com은 서브도메인을 처리하지만, example.com 자체는 처리하지 않습니다. 루트 도메인은 별도의 A 또는 AAAA 레코드가 필요합니다.

이 계층 구조 덕분에 와일드카드 위에 구체적인 레코드를 층층이 쌓을 수 있습니다. www.example.com은 마케팅 사이트로, api.example.com은 API 서버로 지정하고, 나머지는 *.example.com이 처리하게 하면 됩니다.

왜 중요한가

서브도메인 즉시 생성

와일드카드가 없다면, 새 고객 서브도메인을 만들 때마다 DNS 레코드를 추가하고 전파를 기다려야 합니다. 와일드카드를 사용하면 DNS 계층은 이미 준비된 상태입니다—새 서브도메인은 애플리케이션이 인식하는 순간 바로 작동합니다.

즉석 개발 환경

*.dev.example.com 와일드카드를 사용하면 개발자들이 DNS를 건드리지 않고도 feature-xyz.dev.example.com이나 experiment.dev.example.com 같은 환경을 바로 만들 수 있습니다. 브랜치마다 고유한 서브도메인을 가질 수 있습니다.

사용자 생성 서브도메인

블로그 플랫폼, 포트폴리오 사이트, 웹사이트 빌더는 사용자들이 yourname.platform.com 같은 서브도메인을 가질 수 있게 합니다. 와일드카드는 사용자마다 수동 설정 없이 이것을 가능하게 합니다.

와일드카드 SSL 인증서

와일드카드 DNS와 와일드카드 SSL 인증서는 쌍으로 작동합니다. *.example.com 인증서 하나로 모든 1단계 서브도메인을 보호할 수 있습니다.

제한 사항은 DNS 와일드카드와 동일합니다:

  • 서브도메인 한 단계만 커버합니다
  • 루트 도메인은 커버하지 않습니다 (보통 SAN(주체 대체 이름)으로 포함합니다)
  • DNS 기반 검증이 필요합니다—특정 TXT 레코드를 만들어 소유권을 증명해야 합니다

위험성

와일드카드는 강력한 도구입니다. 강력한 만큼 위험도 큽니다.

서브도메인 탈취

가장 큰 위험입니다. 와일드카드 CNAME이 클라우드 제공자를 가리키고 있는데, 서비스를 종료하면서 해당 참조를 정리하지 않으면, 공격자가 그 방치된 리소스를 차지할 수 있습니다. 그러면 공격자가 당신의 서브도메인에서—당신의 도메인 신뢰도와 사용자들의 신뢰를 등에 업고—콘텐츠를 제공하게 됩니다.

해결책: 중요한 서비스에는 구체적인 레코드를 사용하고, 인프라를 정기적으로 점검하세요. 무언가를 종료할 때 DNS 레코드 삭제를 가장 먼저 해야 합니다.

이메일 남용

와일드카드 MX 레코드는 스패머들이 당신 도메인의 임의 서브도메인에서 이메일을 보낼 수 있게 합니다. spam-campaign.yourdomain.com은 도메인 신뢰도를 손상시킵니다. 대부분의 이메일 관리자들은 와일드카드 MX 레코드를 아예 사용하지 않습니다.

인증서 제어

issuewild 속성과 함께 CAA 레코드를 사용해서 도메인에 와일드카드 인증서를 발급할 수 있는 인증 기관(CA)을 지정하세요. 이 설정이 없으면, 공격자가 서브도메인 하나의 제어권을 증명하기만 해도 어떤 CA든 당신의 도메인에 와일드카드 인증서를 발급할 수 있습니다.

증폭 공격

모든 서브도메인 쿼리가 응답을 받기 때문에, DNS 증폭 공격에 악용될 수 있습니다. 와일드카드를 사용할 때는 속도 제한과 DDoS 방어가 더욱 중요해집니다.

와일드카드 사용 시기

와일드카드를 사용하세요:

  • 고객 서브도메인이 있는 멀티테넌트 애플리케이션
  • 개발 및 스테이징 환경
  • 사용자 생성 콘텐츠 플랫폼
  • 동적이고 예측 불가능한 서브도메인이 필요한 모든 상황

구체적인 레코드를 사용하세요:

  • 프로덕션 인프라 (api., www., mail.)
  • 고유한 IP 요구사항이 있는 서비스
  • 보안에 중요한 모든 것

패턴은 이렇습니다: 와일드카드는 나머지 케이스들을 처리하고, 구체적인 레코드는 가장 중요한 것을 처리합니다.

와일드카드 DNS 레코드에 관한 자주 묻는 질문

와일드카드 레코드와 CNAME 레코드는 어떻게 함께 작동하나요?

와일드카드 CNAME 레코드(*.example.com CNAME target.com)는 매칭되는 모든 서브도메인을 다른 도메인으로 연결합니다. 동적 서브도메인을 로드 밸런서나 CDN 엔드포인트로 연결할 때 흔히 사용합니다. 동일한 우선순위 규칙이 적용됩니다—구체적인 레코드가 와일드카드를 재정의합니다.

이메일에 와일드카드 DNS를 사용해야 하나요?

아니요. 와일드카드 MX 레코드는 어떤 서브도메인에서도 이메일을 보낼 수 있게 하며, 스패머들이 이를 악용합니다. 정상적인 메일 도메인에는 구체적인 MX 레코드를 사용하세요.

*.example.com*.app.example.com이 둘 다 있으면 어떻게 되나요?

충돌 없이 공존합니다. foo.example.com 쿼리는 첫 번째 와일드카드와 매칭됩니다. bar.app.example.com 쿼리는 두 번째와 매칭됩니다. 각 와일드카드는 계층의 자신이 속한 단계를 관장합니다.

출처

이 페이지가 도움이 되었나요?

😔
🤨
😃
와일드카드 DNS 레코드 설명 • 라이브러리 • Connected