메일이 배달될지 말지를 결정하는데, 어떤 표준도 실제로는 요구하지 않으며, 설정하고 싶어도 종종 직접 설정할 수 없는 DNS 레코드가 있다. 역방향 레코드 — PTR — 이다. 이것이 조용히 이메일의 문지기 노릇을 하는 방식은 인터넷에서 가장 기묘한, 우연히 짊어진 짐 중 하나다.
대부분은 어렵게 만난다. 메일 서버를 세웠고, 다 맞아 보인다 — MX 레코드, SPF, DKIM, 유효한 인증서. 그런데도 메시지가 스팸함에 떨어지거나 문턱에서 “client host rejected: cannot find your reverse hostname” 같은 말로 반송된다. 레코드를 빠뜨린 게 아니다. 내가 책임자인 줄도 몰랐던 레코드를, 어쩌면 통제권조차 없는 레코드를 빠뜨린 것이다.
정방향 DNS는 한 방향, 역방향은 반대 방향
보통의 DNS는 “이 이름의 주소는 무엇인가?”에 답한다. example.com을 물으면 93.184.216.34 같은 주소를 돌려준다. 역방향 DNS는 정반대를 묻는다: “이 주소에 속한 이름은 무엇인가?” IP를 주면 호스트명을 돌려준다.
영리하면서 조금 황당한 부분은 그 저장 방식이다. 별도의 역방향 데이터베이스는 없다 — 전부 그냥 DNS, 같은 트리, 같은 질의 기계다. IPv4 주소를 조회하려면 옥텟을 뒤집고 .in-addr.arpa를 붙여 PTR 레코드를 묻는다. 그래서 93.184.216.34는 34.216.184.93.in-addr.arpa 질의가 된다. 뒤집는 이유는, DNS 이름은 오른쪽으로 갈수록 더 넓어지고(www.example.com은 왼쪽으로 읽을수록 좁아진다) IP 주소는 왼쪽으로 갈수록 더 좁아지기 때문이다. 옥텟을 뒤집으면 주소가 DNS 계층에 깔끔히 들어맞고, 각 네트워크가 여느 존처럼 위임된다. IPv6도 ip6.arpa 아래서 같은 일을 하는데, 다만 32개 16진 니블을 전부 뒤집어야 해서 아무도 두 번은 타이핑하지 않을 질의 문자열이 나온다.
여기 사람들을 놀래키는 함정이 있다: 정방향과 역방향 DNS는 전혀 다른 주체가 통제한다. example.com은 내가 소유하니 정방향 레코드는 내가 통제한다. 그러나 IP의 역방향 존은 IP 블록을 소유한 자 — 내 ISP나 호스팅 제공업체 — 의 것이다. 빌려 쓰는 주소의 PTR을 내가 게시할 수는 없다. 그들에게 요청하거나, 그들이 열어 준 제어판을 써야 한다. /24보다 작은 할당에는 RFC 2317 무클래스 위임이라는 별도 장치까지 있어, 주소 대역 일부의 역방향 통제권을 넘겨받는다. 요점은 그대로다: 역방향 레코드는, 내가 관리하는 다른 모든 것과 소유권 경계 반대편에 산다.
진짜 중요한 검사: FCrDNS
PTR 레코드 하나만으로는 거의 아무것도 증명하지 못한다. IP 블록 소유자가 원하는 어떤 이름으로든 가리킬 수 있기 때문이다. 내 서버의 역방향을 mail.google.com으로 설정하면 조회는 충실히 그 값을 돌려준다. 그래서 등장하는 것이 정방향 확인 역방향 DNS — FCrDNS, 다른 이름으로 iprev, full-circle, double-reverse DNS다.
발상은 고리를 닫는 것이다:
- IP를 가져온다. PTR 레코드를 조회한다. 호스트명을 얻는다.
- 그 호스트명을 가져온다. A(또는 AAAA) 레코드를 조회한다. IP 목록을 얻는다.
- 원래 IP가 그 목록에 있는지 확인한다.
고리가 닫히면 FCrDNS 유효다. 이게 의미를 갖는 이유가 바로 앞의 소유권 분리다. 위조하려면 역방향 존(= IP 블록 통제)과 내가 가리키는 정방향 존을 모두 통제해야 한다. PTR을 mail.google.com으로 설정해 봐야 소용없다 — 그 이름에 대한 구글의 A 레코드에 내 IP가 없으니 정방향 확인이 실패한다. 강력한 암호학은 아니다 — 양 끝을 같은 주체가 통제한다는 값싼 증명일 뿐인데, 그게 쓰레기의 상당수를 걸러내기엔 충분한 것으로 드러났다.
RFC 1912는 이를 1996년에 적어 두었고, 그 조언은 평이해서 거의 정겹다: “PTR과 A 레코드가 일치하도록 하라.” 정보성(Informational) RFC다. 무엇도 요구하지 않으며, 요구할 수도 없다. 이름 붙은 메커니즘으로서의 공식 거처는 iprev로, Authentication-Results 작업(RFC 8601)에서 인증 방법으로 정의된다. 그런데 빠진 걸 보라: SMTP 표준인 RFC 5321 어디에도 서버가 유효한 역방향 DNS를 가져야 한다는 말은 없다. 이 체제 전체가 모범 사례이자 관행이다.
관행이 어떻게 벽이 됐나
관행이지만, 큰 수신자들은 법처럼 강제한다.
메일 서버는 FCrDNS를 스팸 신호로 가장 먼저 쓴 축에 들고, 그 논리는 탄탄하다. 정상 메일 서버는 의도적으로 구성된 기계라, 운영자가 몇 분이면 일치하는 PTR을 마련할 수 있다. 가정용 회선에 앉은 스팸 살포 봇넷 노드는 203-0-113-44.dyn.example-isp.net 같은 역방향 이름 — 일반적이고, 한눈에 동적이며, 자기가 주장하는 무엇과도 안 맞는 — 을 갖는다. 그래서 수신자들은 PTR이 없거나 일반적으로 보이는 IP의 연결을, 종종 본문이 전송되기도 전에 거부하기 시작했다. Postfix는 이를 reject_unknown_client_hostname으로 제공한다: 해석 가능하고 정방향 확인되는 역방향 이름이 없으면, 대화도 없다.
주요 제공업체는 모두 이를 내장한다. 구글의 발신자 지침은 모든 발신 IP가 일치하는 PTR 레코드를 가질 것을 못박고, IPv6에는 더 엄격하다 — 제대로 된 역방향 DNS 없이 v6로 보내면 Gmail은 곧장 거부한다. Outlook과 Yahoo도 검사한다. 그 누구도 어떤 표준에 의해 의무가 지워진 게 아니다. 20여 년이 지난 지금도, 깨끗한 역방향 레코드의 부재가 ‘이 호스트는 메일 보낼 자격이 없다’는 가장 믿을 만한 신호이기에 그렇게 할 뿐이다.
그래서 정말로 기묘한 상황이 빚어진다. 레코드는 의무가 아니다. 가장 강한 동사가 “~해야 한다(should)“인 정보성 RFC의 관할이다. 그런데도 인터넷의 핵심 기능 하나의 단단한 전제 조건이 됐다 — ‘PTR 없음’이, 실제 표준이 정의하는 DMARC 정책 누락보다 더 치명적인 이메일 전달 문제가 될 정도로.
여기서 얻을 것
메일을 보내는 무언가를 운영한다면, RFC가 기술적으로 뭐라 하든 역방향 DNS는 선택이 아니다. 작동 방식에서 세 가지가 따라온다.
통제권이 없을 수 있으니 일찍 확인하라. PTR은 IP 소유자에게 있다. VPS나 전용 호스트에는 보통 패널에 그 항목이 있고, 공유·클라우드 환경에서는 요청을 넣어야 하거나, 아예 막힐 수도 있다 — 이미 깨끗한 역방향 DNS를 가진 IP를 쓰는 제공업체를 통해 보내라는 실질적 근거다.
고리를 닫아라. 같은 IP로 되돌아오지 않는 호스트명을 가리키는 PTR은, 오설정으로 읽혀 PTR이 아예 없는 것보다 더 나쁠 수 있다. 역방향을 실재하는 호스트명으로 설정하고, 그 호스트명에 IP를 담은 정방향 레코드를 주고, 이상적으로는 서버가 HELO에서 알리는 이름과 같게 하라. 셋이 일치하는 것 — 그게 엄격한 수신자가 조용히 확인하는 것이다.
그리고 내가 통제하는 레코드는 다 완벽한데 메일이 영문 모르게 거부된다면, 통제 못 할지도 모르는 그 하나를 확인하라. 역방향 레코드는 인터넷에서 가장 잊기 쉬운 것이다 — 바로, 내 메일 정체성에서 유일하게 남의 울타리 너머에 사는 조각이기 때문이다.