거의 모든 존에서 만나게 되는 레코드
와일드카드 DNS 레코드란? 용도와 위험
와일드카드 DNS 레코드는 별표(asterisk) 레이블을 사용해 존에 더 구체적인 레코드가 없는 이름에 대한 응답을 제공합니다. 애플리케이션이 많은 테넌트 서브도메인을 받거나 서비스가 의도적으로 폭넓은 호스트 이름을 처리할 때 유용할 수 있습니다. 와일드카드는 모든 명시적 레코드를 덮어쓰는 보편적인 규칙이 아니며, 그 동작은 DNS 이름의 존재 여부와 요청한 레코드 유형에 따라 달라집니다. 또한 오타가 있거나 의도하지 않은 서브도메인이 분명하게 실패하지 않고 어딘가로 확인되게 만들어 뜻밖의 결과를 낳을 수 있습니다. 애플리케이션과 보안 모델이 그런 폭넓은 범위를 염두에 두고 설계된 경우에만 사용하세요.
와일드카드 일치가 동작하는 방식
와일드카드 레이블은 특정 이름 수준에서 별표로 표기하며, 흔히 *.example.com 형태입니다. 더 가까운 일치 데이터가 없을 때 그 지점 아래의 특정 이름에 대한 데이터를 제공할 수 있습니다. 파일 시스템의 와일드카드처럼 모든 깊이의 모든 하위 이름이 자동으로 생성된다는 뜻은 아닙니다. 기존 이름, 위임, 빈 중간 노드(empty non-terminal)가 결과에 영향을 줍니다. 레코드 유형도 중요합니다. 와일드카드 A 레코드가 모든 서브도메인에 대한 모든 MX, TXT, AAAA 레코드를 자동으로 만들어 주지는 않습니다. 와일드카드 하나가 모든 DNS 동작을 포괄한다고 가정하지 말고, 애플리케이션이 기대하는 이름과 레코드 유형을 직접 테스트하세요.
| 구성 선택 | 예상되는 효과 |
|---|---|
| 이름에 대한 명시적 레코드 | 해당 이름에 설정된 데이터를 제공 |
| 상위에 있는 와일드카드 | 해당하는 미설정 이름에 응답할 수 있음 |
| 와일드카드 A만 있는 경우 | 와일드카드 이메일이나 TXT 정책을 의미하지 않음 |
| 일치하는 레코드 없음 | 존 상태에 따라 데이터 없음 또는 이름 오류를 반환할 수 있음 |
대표적인 사용 사례는 고객마다 서브도메인을 받고 그런 이름이 모두 같은 애플리케이션 엣지로 라우팅되는 멀티 테넌트 호스팅입니다. 그러면 애플리케이션이 호스트 이름을 살펴 어느 테넌트나 사이트를 제공할지 결정합니다. DNS는 요청을 엔드포인트로 보내는 일만 하며, 요청된 테넌트가 존재하는지 또는 요청자가 접근할 수 있는지는 검증하지 않습니다. 애플리케이션이 자체 라우팅 및 권한 부여 규칙을 시행해야 합니다. 알 수 없는 서브도메인이 기본 사이트로 넘어간다면, 그 기본 사이트가 관리 도구, 디버그 콘텐츠, 다른 고객의 데이터를 노출하지 않도록 하세요.
운영 및 보안상의 고려 사항
와일드카드는 오타가 있는 이름도 확인될 수 있기 때문에 테스트 중에 오타를 숨길 수 있습니다. 또한 인증서 자동화가 게시할 의도가 없던 이름까지 요청하게 만들 수도 있습니다. 이메일 관련 와일드카드는 특별한 주의가 필요합니다. 와일드카드 주소 레코드를 의도적인 메일 정책으로 착각해서는 안 되며, 캐치올 메일 동작은 DNS만으로 만들어지는 것이 아니라 메일 시스템에 속합니다. 와일드카드를 도입하기 전에 명시적인 이름과 위임된 서브도메인을 파악하세요. 누가 그 동작을 소유하는지, 수신 애플리케이션이 예상치 못한 호스트 이름을 어떻게 처리하는지 문서화하세요.
- 애플리케이션이 처리할 준비가 된 이름에만 와일드카드 레코드를 사용하세요.
- 라우팅이나 정책이 별도로 필요한 서비스에는 명시적인 레코드를 유지하세요.
- 예상되는 테넌트 이름뿐 아니라 알 수 없는 서브도메인과 형식이 잘못된 서브도메인도 테스트하세요.
- 와일드카드 DNS를 접근 제어나 테넌트 권한 부여로 취급하지 마세요.
- 배포 전에 인증서, 이메일, 모니터링에 미치는 영향을 검토하세요.
와일드카드 응답 문제 해결
예상치 못한 서브도메인이 확인된다면 해당 수준에 와일드카드가 있는지 존을 점검하고, 더 구체적인 레코드나 위임이 있는지 확인하세요. 정확한 이름과 레코드 유형을 질의한 뒤 와일드카드 대상과 비교하세요. 와일드카드가 적용되지 않는 것 같다면, 기존 노드가 DNS 트리의 해당 가지에서 와일드카드 합성에 영향을 주는지 살펴보세요. 제공업체 인터페이스는 이런 세부 사항을 추상화할 수 있으므로, 서비스가 와일드카드 레코드를 어떻게 구현하는지 확인하세요. 와일드카드를 제거하거나 변경한 뒤에는 캐시가 만료되도록 시간을 두고, 이전에 예상했던 이름과 이제 실패해야 하는 이름을 모두 테스트하세요.
와일드카드는 호스트 이름 목록 관리를 건너뛰는 지름길이 아니라 용도가 분명한 도구입니다. 제품이 의도적으로 가변적인 이름 공간을 제공하고 애플리케이션이 안전하고 명시적으로 호스트를 라우팅할 때 가장 잘 동작합니다. 기본 배경은 DNS 레코드 유형 설명과 CNAME이 하는 일을 참고하세요. 공개 DNS 조회로는 선택한 이름에 대해 리졸버가 무엇을 반환하는지 확인할 수 있고, 애플리케이션 테스트로는 엔드포인트가 그 이름을 올바르게 처리하는지 확인할 수 있습니다.
예상한 이름과 예상하지 못한 이름을 모두 테스트하세요
와일드카드 배포는 정상으로 알려진 테넌트 이름 하나만이 아니라 여러 이름으로 테스트해야 합니다. 처리되어야 하는 이름, 명시적으로 재정의해야 하는 이름, 존재하지 않아야 하는 임의의 이름을 확인하세요. 그런 다음 DNS 응답과 애플리케이션의 응답을 모두 점검하세요. 와일드카드는 알 수 없는 레이블을 서비스로 라우팅할 수 있지만, 애플리케이션은 의도치 않은 기본 계정을 만들거나 설정을 노출하지 않고 안전한 not-found 응답을 반환해야 합니다. DNS 트리 구조가 어떤 와일드카드 데이터가 적용되는지를 바꿀 수 있으므로, 명시적 레코드와 위임을 추가한 뒤에도 테스트를 반복하세요. 새로 확인되는 서브도메인이 예상된 것인지 설정상의 뜻밖의 결과인지 이후 운영자가 알 수 있도록 의도한 이름 패턴을 문서화하세요.
도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.
관련 글
CNAME은 주소가 아닌 이름의 별칭
www.example.com
CNAME 레코드
cdn.provider.net
대상 호스트 이름
192.0.2.10
A 레코드, 최종 응답
CNAME 체인 이해하기: 별칭을 따라 IP까지 추적하기
CNAME 레코드가 별칭 체인을 만드는 방식, 리졸버가 A와 AAAA 주소에 도달하는 과정, 체인이 끊어졌을 때 확인할 사항을 알아봅니다.
이메일이 메일 서버를 찾는 과정
발신자
you@gmail.com
MX 조회
메일을 받는 곳은?
메일 서버
우선순위 10 먼저
받은편지함
전달됨
우선순위 값이 낮을수록 먼저 사용되고, 높은 값은 백업입니다
MX 레코드 설명: 이메일이 목적지를 찾는 방법
MX 레코드는 도메인의 이메일을 처리하는 메일 서버가 어디인지 인터넷에 알려 줍니다. A 레코드와 구조가 다른 이유도 함께 살펴봅니다.
“DNS 서버”라는 이름을 공유하는 세 계층
스텁 리졸버
내 기기 자체
재귀 리졸버
ISP, 라우터, 1.1.1.1
권한 네임서버
도메인 자체의 DNS
재귀 리졸버와 권한 네임서버의 차이
‘DNS 서버’라는 말에는 전혀 다른 두 가지 역할이 섞여 있습니다. 질문을 대신 해 주는 재귀 리졸버와 답을 가진 권한 서버입니다.