문제 상황

app., api., staging., 다음 주에 동료가 새로 만들 무언가까지 — 모든 서브도메인이 DNS를 다시 건드리지 않고도 해석되도록 *.example.com 레코드를 하나 넣었습니다. 미래의 티켓 100건을 아껴줄 지름길처럼 느껴졌죠. 그런데 어느 서브도메인 하나가 해석되지 않거나 엉뚱한 곳으로 가고, 이제 와일드카드가 대체 일을 하긴 하는지 의심스럽습니다.

와일드카드는 거의 확실히 작동합니다. 사람들을 놀라게 하는 건 그게 어떤 이름까지 닿느냐, 그리고 더 자주는 — 다른 레코드를 추가하는 순간 어떤 이름에 조용히 안 닿게 되느냐입니다. DNS 와일드카드는 RFC 4592의 특정 규칙을 따르며, 그중 무엇도 당신이 짐작한 “아래 전부 매칭”이 아닙니다.

와일드카드란 실제로 무엇인가

와일드카드는 맨 왼쪽 레이블이 별표 하나인 평범한 레코드입니다: *.example.com. 자기 레코드가 없는 이름에 대해 네임서버가 응답을 합성하라는 뜻이죠. whatever.example.com을 질의하면 서버는 정확 매칭을 못 찾고, 와일드카드를 보고, 마치 whatever.example.com이 처음부터 그 레코드를 가졌던 것처럼 답합니다.

세 가지 규칙이 지배하며, 이게 거의 모든 와일드카드 사건을 설명합니다.

  1. 별표는 맨 왼쪽 레이블일 때만 와일드카드입니다. *.example.com은 와일드카드입니다. sub.*.example.com은 아닙니다 — 거기서 *는 이름 안의 문자 그대로의 별표이고, 이건 거의 원하는 결과가 아닙니다.
  2. 정확 매칭이 항상 이깁니다. www.example.com에 자기 A 레코드가 있으면 www에 대해 와일드카드는 결코 참조되지 않습니다.
  3. 와일드카드는 자기 부모가 가장 가까운 기존 조상인 이름까지만 닿습니다. 이게 사람을 물어뜯는 규칙이라 따로 다룰 가치가 있습니다.

빈 논터미널(empty non-terminal) 함정

레코드가 딱 하나 있다고 합시다: *.example.com A 203.0.113.10. 지금은 a.example.com, b.example.com, 심지어 a.b.example.com까지 답합니다 — example.com 아래에서 자기 레코드가 없는 이름 무엇이든요.

이제 무관한 레코드를 하나 추가합니다: logs.metrics.example.com A 203.0.113.99.

방금 당신은 metrics.example.com을 트리 안의 노드로 — 빈 논터미널로 — 조용히 만들었습니다. 자기는 레코드가 없지만, 아래에 뭔가 살기 때문에 존재하죠. 그리고 이제 존재하므로, 그 아래 무엇에게든 가장 가까운 조상이 됩니다. 그래서 foo.metrics.example.com은 더 이상 *.example.com에 매칭되지 않습니다. 와일드카드의 부모(example.com)가 foo.metrics.example.com 위의 가장 가까운 노드가 아니게 됐으니까요. 그 이름은 NXDOMAIN을 돌려줍니다.

와일드카드는 바뀌지 않았습니다. 건드린 적도 없죠. 그런데 세 레이블 깊이에 레코드를 하나 추가한 것이 가지 하나를 통째로 그 아래에서 뽑아냈습니다. 이것이 “건드리지도 않았는데 와일드카드가 깨졌다”는 가장 흔한 제보이고, RFC 4592는 이게 설계대로라고 분명히 말합니다 — 와일드카드는 애초에 임의 깊이를 아우르는 만능 규칙이 아니었습니다.

레코드 타입 관점의 따름정리: 와일드카드는 타입별로, 그리고 달리 존재하지 않는 이름에만 참조됩니다. *.example.com MX 레코드는 www.example.com에 이미 A 레코드가 있다면 그 MX를 주지 않습니다 — www는 존재하므로 와일드카드가 결코 적용되지 않죠. 와일드카드 MX는 존에서 완전히 빠진 이름만 덮습니다.

아무도 말 안 하는 SSL 쪽

당신의 DNS 와일드카드와 TLS 와일드카드는 “와일드카드”의 의미를 두고 서로 동의하지 않습니다.

*.example.com 인증서는 정확히 한 레이블을 매칭합니다: api.example.com은 커버되지만 a.b.example.com은 아니고, 맨 apex인 example.com도 아닙니다. 그래서 DNS 와일드카드는 a.b.example.com을 당신 서버로 신나게 해석해주는데, 브라우저는 여전히 인증서 이름 오류를 던질 수 있습니다. 와일드카드 인증서는 한 단계 아래만 검증하니까요. 다단계 서브도메인을 서비스한다면 각 단계마다 자기 와일드카드(*.b.example.com)나 SAN 항목이 필요합니다.

와일드카드가 멀쩡하다고 단정하기 전에 양쪽을 확인하세요: 이름이 무엇으로 해석되는지 확인하고, 그다음 인증서가 그것과 매칭되는 이름을 실제로 담고 있는지 확인합니다.

DechoNet 도구로 확인

  • /util/dns — 특정 서브도메인과 지어낸 이름(does-not-exist-123.example.com)을 각각 질의하세요. 지어낸 이름이 와일드카드 값을 돌려주면 와일드카드는 살아 있습니다. 실제 서브도메인이 NXDOMAIN을 돌려주면 합성을 깨뜨린 중간 노드를 찾으세요.
  • /util/ssl — 서비스되는 인증서가 실제로 쓰는 깊이와 매칭되는 이름을 담고 있는지 확인하세요 — *.example.com 인증서는 두 레이블 깊이 호스트를 검증하지 못합니다.

설정·안전 체크리스트

  • 이름/호스트 칸에는 *만 입력하세요(DNS 패널이 존을 붙여줍니다) — *.example.com을 넣으면 대부분의 패널이 *.example.com.example.com으로 만들어버립니다.
  • 실제로 필요한 타입을 고르세요: 만능 IP엔 * A/AAAA, 나열되지 않은 모든 서브도메인을 플랫폼 호스트명으로 보내려면 * CNAME.
  • 정확 레코드가 이긴다는 걸 기억하세요: 자기 레코드가 있는 서브도메인은 와일드카드를 무시하고, 깊은 레코드 하나가 가지 하나를 빈 논터미널로 만들어 고립시킬 수 있습니다.
  • 인증서를 깊이에 맞추세요 — *.example.com 인증서는 한 레이블만, apex도 두 단계 깊이도 아닙니다.
  • 서드파티 서비스로 향하는 와일드카드 CNAME은 탈취 표면으로 다루세요: 모든 가능한 서브도메인을 그 제공자로 보내므로, 대상이 언젠가 해제되면 당신의 네임스페이스 전체가 선점 가능해집니다. 와일드카드는 좁게 한정하고, 서비스가 사라지면 제거하세요.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.