DMARC 잘 걸어놨는데 왜 스푸핑이 뚫리지
이메일 도메인을 운영해 본 분이라면 SPF, DKIM, DMARC라는 단어를 한 번쯤 들어보셨을 거예요. 회사 도메인을 사칭한 가짜 메일(스푸핑)을 막으려고 거는 인증 장치들이죠. 그중 DMARC에는 비교적 최근에 추가된 'np'라는 태그가 있는데요. 이걸 켜두면 오히려 특정 상황에서 방어가 조용히 무력화될 수 있다는 지적이 나왔어요. 그 범인이 뜻밖에도 보안을 강화하려고 켜는 DNSSEC이라는 게 이 이야기의 반전 포인트예요.
먼저 DMARC와 np 태그가 뭐냐면
DMARC는 SPF와 DKIM이라는 두 인증 위에 얹는 '정책 층'이에요. '내 도메인을 사칭한 메일이 오면 어떻게 처리해라(그냥 통과 / 격리 / 거부)'를 도메인 주인이 선언해 두는 규칙이죠. DNS의 TXT 레코드에 적어둡니다.
여기서 태그가 몇 가지 있어요. p는 도메인 본체(example.com)에 대한 정책, sp는 하위 도메인(subdomain, 예: mail.example.com)에 대한 정책이에요. 그리고 새로 생긴 np는 '존재하지 않는' 하위 도메인에 대한 정책이고요.
이게 왜 필요하냐면, 공격자들이 종종 invoice.example.com이나 login.example.com처럼 회사가 실제로 만든 적도 없는 그럴듯한 하위 도메인을 지어내서 사칭 메일을 보내거든요. np=reject로 걸어두면 '우리가 만들지도 않은 하위 도메인에서 온 메일은 전부 거부해'라고 못을 박을 수 있어요. 아주 강력한 방어죠.
문제는 '존재하지 않음'을 어떻게 판단하느냐예요
메일을 받는 서버는 어떤 하위 도메인이 '존재하지 않는다'는 걸 어떻게 알까요? 방법은 간단해요. 그 이름을 DNS에 물어보고 NXDOMAIN이라는 응답(그런 이름 없음, 응답 코드 3)이 오면 '아, 존재하지 않는 도메인이구나' 하고 판단해요. 그러면 np 정책을 적용하는 거죠.
바로 여기서 DNSSEC과 충돌이 생겨요. DNSSEC은 DNS 응답이 위조되지 않았음을 서명으로 증명하는 보안 기술인데요. 문제는 '존재하지 않는 이름'에 대해 매번 서명을 만드는 게 서버 입장에서 비용이 크다는 거예요. 그래서 클라우드플레어(Cloudflare)나 PowerDNS 같은 곳은 '컴팩트한 부재 증명(compact denial of existence)', 흔히 '블랙 라이(black lies)'라고 부르는 기법을 써요.
이게 뭐냐면, 존재하지 않는 이름을 물어봐도 NXDOMAIN 대신 NOERROR(정상 응답, 그런데 해당 타입의 레코드는 없음)를 돌려주는 거예요. 미리 서명해 둔 응답으로 '이 이름은 있긴 한데 이 타입 레코드가 없어'라고 둘러대는 식이죠. 서버 부담을 줄이는 영리한 최적화지만, 밖에서 보면 '존재하지 않는 이름'과 '존재하지만 레코드만 없는 이름'이 구분이 안 돼요.
그래서 무슨 일이 벌어지냐면
메일 받는 서버는 NXDOMAIN을 기대하고 물어봤는데 NOERROR가 오니까, '어? 이 하위 도메인 존재하네?'라고 착각해요. 그러면 강력한 np 정책을 적용하지 않고, 대신 더 느슨할 수 있는 sp나 기본 정책으로 넘어가 버려요. 결과적으로 우리가 애써 걸어둔 '존재하지 않는 하위 도메인 거부'가 조용히 풀려버리는 거죠. 보안을 강화하려고 켠 DNSSEC이 다른 보안 기능의 발목을 잡는 아이러니한 상황이에요.
업계 맥락
DMARC는 지금 'DMARCbis'라는 이름으로 표준이 정리되는 중이고, np 태그도 그 과정에서 다듬어지고 있어요. 반면 컴팩트 부재 증명은 대규모 DNS 사업자들이 성능 때문에 널리 쓰는 방식이고요. 즉 이건 어느 한쪽이 버그를 낸 게 아니라, 서로 다른 표준이 각자 합리적인 가정을 하다가 만나는 지점에서 생긴 틈이에요. 이메일 보안 생태계(SPF, DKIM, MTA-STS, BIMI 등)가 DNS 위에 층층이 쌓여 있다 보니 이런 미묘한 상호작용이 종종 튀어나옵니다.
한국 개발자에게
회사 메일 도메인을 관리하면서 클라우드플레어 DNS에 DNSSEC을 켜두고 np=reject도 걸어둔 분이라면, 그 방어가 실제로는 작동 안 하고 있을 수 있어요. 확인은 어렵지 않아요. 터미널에서 존재하지 않는 하위 도메인을 dig 명령으로 조회했을 때 NXDOMAIN이 오는지 NOERROR가 오는지 보면 됩니다. NOERROR가 온다면 np가 무력화되는 환경인 거죠. 이럴 땐 np에만 의존하지 말고 p와 sp 정책 자체를 튼튼하게(reject 또는 quarantine) 걸어두는 편이 안전해요.
마무리
한 줄로 정리하면, '보안 기능 두 개를 켰다고 두 배로 안전해지는 게 아니다'예요. 각자의 전제가 부딪히면 오히려 구멍이 생기기도 하니까요. 여러분 도메인은 지금 존재하지 않는 하위 도메인을 물었을 때 NXDOMAIN을 돌려주고 있나요, 아니면 NOERROR를 돌려주고 있나요?
🔗 출처: Hacker News