PTR 레코드: 역방향 DNS 조회

순방향 DNS는 주장이다. 역방향 DNS는 증명이다.

mail.example.com을 조회하면 DNS는 해당 도메인이 203.0.113.42를 가리킨다고 알려준다. 도메인을 가진 사람이라면 누구든 이런 주장을 할 수 있다. 하지만 그 IP 주소를 조회하며 "이 IP를 소유한 호스트네임은 무엇인가?"라고 물으면, 실제 IP 주소 소유자만이 답할 수 있다. PTR 레코드가 바로 그 답을 제공한다. PTR 레코드는 IP 주소를 호스트네임으로 역방향 매핑하는 역방향 조회다.

인터넷에서의 신뢰는 결국 하나의 질문으로 귀결된다. 당신은 당신이 주장하는 자가 맞는가? 이메일 서버는 이를 끊임없이 확인한다. 메일 서버가 203.0.113.42에서 연결하며 example.com의 메일을 발송한다고 주장할 때, 수신 서버는 역방향 조회를 수행한다. PTR 레코드가 그 관계를 확인해 주면, 당신은 무언가를 증명한 것이다. 단순히 도메인 이름을 소유하는 것이 아니라, 실제 네트워크 인프라를 제어한다는 것을.

PTR 레코드의 동작 방식

PTR 레코드는 A 레코드의 거울 이미지다. A 레코드가 "이 호스트네임은 이 IP를 가리킨다"고 말한다면, PTR 레코드는 "이 IP는 이 호스트네임을 가리킨다"고 말한다. 두 레코드는 완전히 다른 곳에 존재한다. A 레코드는 도메인의 DNS 존에 있지만, PTR 레코드는 IP 주소 공간을 소유한 당사자가 관리하는 특수한 역방향 DNS 존에 존재한다.

이러한 분리는 현실을 반영한다. 도메인과 IP 주소는 서로 다른 소유자를 가진다. example.com을 소유할 수 있지만, 203.0.113.42는 소유하지 않는다. 그것은 호스팅 제공업체나 ISP의 소유다. 그들이 자신의 IP 주소에 대한 역방향 DNS 존을 관리하며, 서버에 PTR 레코드를 부여할지 여부도 그들이 결정한다.

역순 주소 형식

PTR 레코드는 이유를 이해하기 전까지는 잘못된 것처럼 보이는 규칙을 사용한다. 203.0.113.42의 PTR 레코드를 조회하려면 42.113.0.203.in-addr.arpa를 쿼리한다. IP 주소가 뒤집혀 있다.

DNS 계층 구조는 왼쪽에서 오른쪽으로, 하위에서 상위로 읽힌다. www.example.com에서 "www"는 "example"보다 하위이고, "example"은 "com"보다 하위다. 역방향 DNS가 동일한 패턴을 따르려면 IP 주소를 뒤집어야 한다. 즉, 42(특정 호스트)가 113.0.203(네트워크) 앞에 온다.

IPv6도 동일한 논리를 따르지만 훨씬 더 길어진다. 각각의 16진수 자리가 별도의 레이블이 된다. 2001:db8::1 주소는 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa가 된다. ip6.arpa 존에 32개의 개별 레이블이 생기는 것이다.

이메일: PTR 레코드가 가장 중요한 곳

메일 서버는 쉽게 신뢰하지 않는다. 서버가 이메일을 전달하기 위해 연결하면, 수신 서버는 즉시 발신 IP 주소에 대한 역방향 조회를 수행한다. 세 가지 결과가 가능하다.

PTR 레코드가 없는 경우. 많은 메일 서버가 연결을 즉시 거부한다. 정상적인 메일 인프라는 역방향 DNS가 설정되어 있다. 역방향 DNS가 없다면 악성코드에 감염된 가정용 컴퓨터나 임시 스팸 운영을 의심하게 된다.

PTR 레코드는 있지만 일치하지 않는 경우. IP의 PTR 레코드가 server47.hostingcompany.com을 가리키는데 example.com의 메일을 발송한다고 주장한다면, 그 불일치는 의심을 불러일으킨다. 통과될 수도 있지만, 추가적인 검토를 받게 된다.

PTR 레코드가 존재하고 검증되는 경우. 최고 기준이다. IP가 mail.example.com을 가리키고, mail.example.com이 다시 IP를 가리킨다. 이 양방향 검증을 FCrDNS(forward-confirmed reverse DNS, 순방향 확인 역방향 DNS)라고 하며, 도메인과 인프라 모두를 제어한다는 것을 증명한다.

2024년 2월부터 Google과 Yahoo는 대량 이메일 발송자에게 FCrDNS를 요구한다¹. 이것은 선택 사항이 아니다. FCrDNS가 올바르게 설정되지 않은 IP에서 발송된 메시지는 거부되거나 스팸으로 분류된다.

FCrDNS: 양방향 검증

FCrDNS는 양방향이 일치해야 한다. IP 203.0.113.42는 mail.example.com을 가리키는 PTR 레코드를 가져야 하고, mail.example.com은 다시 203.0.113.42를 가리키는 A 레코드를 가져야 한다.

이 양방향 확인은 특정 종류의 남용을 막는다. 누군가 자신이 제어하지 않는 호스트네임을 가리키는 PTR 레코드를 설정할 수 있지만, 도메인을 소유하지 않고서는 그 호스트네임이 다시 자신을 가리키게 만들 수 없다. FCrDNS 검증은 IP 주소(PTR 설정용)와 도메인(A 레코드 설정용) 모두의 소유권을 요구한다.

PTR 레코드 제어권

대부분의 경우 그렇지 않다. PTR 레코드는 IP 주소를 소유한 당사자가 관리하며, 대부분의 경우 IP를 소유하는 것이 아니라 임대한다.

• 클라우드 제공업체(AWS, Google Cloud, Azure)는 일반적으로 인스턴스의 PTR 레코드를 설정하는 인터페이스를 제공한다
• 전용 서버 제공업체는 보통 관리 패널을 통해 역방향 DNS를 설정할 수 있다
• ISP는 기업 계정에 PTR 설정을 허용할 수 있지만, 가정용 연결에는 거의 이 옵션이 없다

대부분의 제공업체는 역방향 매핑을 허용하기 전에 호스트네임이 이미 자신의 IP로 확인되는지 검증한다.

이메일 외의 활용

PTR 레코드는 이메일 검증 외에도 다양한 목적으로 사용된다.

로깅과 모니터링. IP 주소가 호스트네임으로 변환될 때 시스템 로그가 훨씬 읽기 쉬워진다. 로그에서 mail.example.com을 보면 203.0.113.42와 달리 즉각적인 맥락을 파악할 수 있다.

보안 검증. 네트워크 모니터링 도구는 역방향 DNS를 사용해 연결 시스템을 식별한다. 침입 탐지 시스템은 PTR 레코드가 없거나 의심스러운 IP에서의 연결에 경고를 발생시킨다.

문제 해결. 네트워크 문제를 진단할 때 역방향 조회는 문제가 되는 IP 주소를 소유한 조직을 파악하는 데 도움이 된다. PTR 레코드는 책임 있는 호스팅 제공업체나 네트워크 운영자를 드러내는 경우가 많다.

PTR 레코드에 대한 자주 묻는 질문

도메인 등록 기관을 통해 PTR 레코드를 설정할 수 없는 이유는 무엇인가요?

PTR 레코드는 도메인 소유자가 아닌 IP 주소 소유자가 관리하는 역방향 DNS 존에 있다. 도메인 등록 기관은 도메인의 순방향 DNS를 관리하지만, 서버 IP의 역방향 DNS 존은 호스팅 제공업체나 ISP에 속한다. IP 주소를 할당한 당사자를 통해 PTR 레코드를 설정하라.

메일 서버를 운영하지 않는다면 PTR 레코드가 필요한가요?

꼭 필요하지는 않지만, 좋은 관행이다. PTR 레코드는 로깅, 문제 해결, 전반적인 네트워크 관리에 도움이 된다. 일부 서비스는 보안 조치의 일환으로 역방향 DNS 확인을 수행한다. 올바르게 설정된 PTR 레코드는 정상적인 인프라를 나타낸다.

PTR 레코드가 있어도 이메일이 스팸으로 표시되는 이유는 무엇인가요?

PTR 레코드를 보유하는 것은 필요 조건이지만 충분 조건은 아니다. 레코드가 발송 도메인에 맞는 호스트네임을 가리켜야 하고, 그 호스트네임은 다시 IP로 확인되어야 한다(FCrDNS). 이메일 전달 가능성은 SPF, DKIM, DMARC 레코드, IP 평판, 이메일 내용에도 의존한다. PTR은 퍼즐의 한 조각일 뿐이다.

출처