[공지] KT Public DNS 사용 환경에서의 SPAMHAUS RBL 오동작 관련 안내

안녕하세요.

사용자의 눈높이에 맞춘 이메일보안 지킴이 지란지니입니다.

이번 공지는 RBL 기능과 관련된 중요 안내입니다. 
세계적인 스팸 차단 기관인 SPAMHAUS는 2025년 9월, 한국의 KT 공용 DNS(168.126.63.1)를 경유한 RBL 조회에 대해 응답을 차단하는 정책 변경을 공식 예고하였으며, 해당 정책은 2026년 1월~2월부터 실제로 적용되기 시작하였습니다.

해당 환경에서는 아래와 같은 증상이 발생합니다.

• 정상 메일이 RBL 판정으로 오차단되는 현상
• RBL 차단 대상 메일이 전혀 필터링되지 않는 현상

본 공지는 원인 분석 및 조치 절차를 안내하기 위해 작성되었습니다. 
KT Public DNS를 사용 중인 환경이라면 아래 내용을 검토하여 조치하시기 바랍니다.

[SPAMHAUS 공식 공지]
https://www.spamhaus.org/resource-hub/email-security/query-the-legacy-dnsbls-via-korea-telecom/

발생 원인

RBL(RealTime Blocking List)은 메일 수신 시 발신 서버 IP를 DNS 쿼리 방식으로 실시간 조회하여 스팸 등재 여부를 판정하는 메커니즘입니다.

* RBL 상세 설명 : RBL(RealTime Blocking List) 이란?

SPAMHAUS가 전 세계 RBL 조회 트래픽을 분석한 결과, KT 공용 DNS(168.126.63.1)를 통한 쿼리가 임계치를 초과하는 수준으로 집중되고 있는 것으로 확인되었습니다. 이는 해당 DNS가 국내 서버 환경에서 기본 값으로 광범위하게 사용되어 온 데 따른 결과로 보입니다.

이에 따라 SPAMHAUS는 특정 Resolver로의 트래픽 집중 현상이 서비스 안정성 및 정책에 부합하지 않는다고 판단하여, KT DNS를 경유한 RBL 조회 요청에 대해 비정상 응답(오류 코드)을 반환하는 정책을 적용하였습니다.

현재 KT Public DNS(168.126.63.1)를 통해 RBL 조회를 수행할 경우, 아래와 같은 오류가 발생하고 있습니다.
이로 인해 제품 버전에 따라 정상 메일이 RBL에 의해 과탐지되어 차단되거나, 반대로 RBL 차단 기능이 정상적으로 동작하지 않는 현상이 발생할 수 있습니다.

조회 결과

조치 대상 환경

아래 DNS가 설정된 서버는 즉시 변경이 필요합니다.

권장 대체 DNS

Q1. 서버 DNS를 확인한 결과 KT가 아닌 내부 구축형 DNS로 설정되어 있음에도, 모든 메일이 RBL로 차단되고 있습니다.

A. 내부 DNS 서버의 포워더(Forwarder)가 KT DNS(168.126.63.1)로 구성되어 있을 가능성이 높습니다.

SPAMHAUS는 RBL 조회 쿼리의 최종 재귀 질의 서버(Recursive Resolver)를 기준으로 차단 여부를 판정합니다. 내부 DNS를 경유하더라도 해당 DNS의 포워더가 KT DNS로 설정된 경우, SPAMHAUS 입장에서는 KT DNS를 최종 Resolver로 인식합니다.

이 경우 내부 DNS의 포워더를 LGU+ 또는 SKB DNS로 변경하시기 바랍니다. 단, 내부 구축형 DNS는 스팸스나이퍼 외에도 다수의 내부 서비스가 공용으로 사용하는 인프라이므로, 포워더 변경은 DNS 운영 담당 조직과 영향 범위를 사전에 검토한 후 진행하시기 바랍니다.

Q2. DNS를 LGU+ 또는 SKB DNS로 변경할 경우, 스팸스나이퍼 서비스 재시작이 필요합니까?

A. 서비스 재시작은 불필요합니다.

Linux 환경에서 DNS 설정은 /etc/resolv.conf의 nameserver 항목을 수정하는 방식으로 변경합니다. 해당 파일은 수정 즉시 OS 레벨에서 반영되므로, 서비스 재시작이나 서버 재부팅 없이 변경된 DNS로 동작합니다.

Q3. 이중화(HA) 구성으로 서버가 2대 운영 중입니다. 1대에서만 변경하여도 됩니까?

A. 이중화 구성 여부와 관계없이 모든 서버에서 개별적으로 변경하여야 합니다.

/etc/resolv.conf는 서버별 로컬 파일로 관리되며, 이중화 구성을 하더라도 서버 간 자동 동기화 대상이 아닙니다. 1대만 변경할 경우 나머지 서버는 기존 KT DNS를 계속 참조하게 됩니다. 각 서버에 개별 접속하여 동일하게 적용하시기 바랍니다.

Q4. DNS 변경 전 서버에서 반드시 사전 확인하여야 할 사항이 있습니까?

A. DNS 변경 전, 변경 대상 DNS 주소에 대한 방화벽의 DNS 트래픽 허용 정책(TCP/UDP 53)을 반드시 점검하시기 바랍니다.

DNS 쿼리는 TCP 및 UDP 포트 53을 사용합니다. 특히 아래 두 레코드 유형에 대한 검증이 필수입니다.

① A 레코드 조회 (UDP 53) nslookup으로 특정 도메인의 IP 조회가 정상 응답되는지 확인합니다. A 레코드, PTR 레코드 등 일반적인 조회는 UDP 방식으로 처리됩니다.

② TXT 레코드 조회 (TCP 53) ← 반드시 확인 SPF, DKIM, DMARC 검사에 사용하는 TXT 레코드는 레코드 크기로 인해 TCP 53으로 자동 전환(TC bit)되어 조회됩니다. nslookup 결과에서 명령어 직후 TCP mode. 문구가 출력되어야 TCP 53 통신이 정상적으로 허용된 상태입니다. 해당 문구가 출력되지 않는 경우 방화벽의 TCP 53 포트에 대한 TCP/UDP 트래픽 허용 정책을 점검하시기 바랍니다.

Q5. DNS를 변경하고 쿼리도 정상 확인하였으나, 일부 메일이 지연 수신되는 현상이 발생하고 있습니다.

A. 1차 DNS로의 TCP 53 통신이 원활하지 않아, 실질적으로 2차 DNS로 폴백(fallback)되어 조회되고 있을 가능성이 높습니다.

nslookup 실행 후 출력되는 Server 및 Address 항목을 확인하시기 바랍니다. 1차로 설정한 DNS 주소가 아닌 다른 주소가 출력된다면, 2차 DNS로 폴백이 발생하고 있는 상태입니다.

이 경우 스팸스나이퍼가 SPF/DKIM/DMARC 검사를 위해 TXT 레코드를 조회하는 과정에서 1차 DNS로의 TCP 53 통신 실패 후 재시도 타임아웃이 누적되어 수신 지연으로 이어집니다. Q4의 TCP 53 트래픽 허용 정책을 재점검하시기 바랍니다.

Q6. Google DNS(8.8.8.8)로 변경하였으나, RBL 차단 메일이 1건도 발생하지 않습니다.

A. Google DNS(8.8.8.8)는 SPAMHAUS의 RBL 조회 쿼리에 대해 NXDOMAIN 대신 의도적으로 정상(NOERROR) 응답을 반환하도록 구성되어 있습니다.

이는 Google이 공용 DNS 서비스의 중립성 유지를 위해 특정 DNS와는 연동을 지원하지 않기로 한 정책 결정이며, SPAMHAUS 공식 문서에도 명시된 사항입니다. 결과적으로 Google DNS 환경에서는 발신 IP가 SPAMHAUS에 등재되어 있더라도 차단 판정이 내려지지 않아 RBL 기능이 무력화됩니다.

RBL 기능의 정상 동작을 위해서는 Google DNS(8.8.8.8) 사용을 지양하고 LGU+ 또는 SKB DNS로 변경하시기 바랍니다.

조치 요약 체크리스트

본 공지 내용과 관련하여 추가 문의 사항이 있으신 경우 지란지교시큐리티 기술지원센터로 문의하여 주시기 바랍니다.

본 문서는 SPAMHAUS 공식 정책 변경 내용 및 운영 환경 분석을 바탕으로 작성되었으며, 추가 변경 사항 확인 시 업데이트될 수 있습니다.