[ DNS 및 도메인 ]

정방향 확인 역방향 DNS : 두 조회 방향을 모두 확인합니다.

역방향 DNS 검사의 두 부분을 모두 수행하고 일치, 불일치 및 조회 실패를 정확하게 보고합니다.

EmailAuth 연구팀 제공

[ 핵심사항 ]

  • 전체 전달 주소 집합에서 정규화된 IP 값을 비교합니다.
  • 시간 초과, 부재 및 불일치를 다른 결과로 유지합니다.
  • DNS 일관성은 발신자 인증이나 안전을 보장하지 않습니다.
이 페이지에서

역방향 조회는 IP 주소에 대해 요청된 호스트 이름을 반환합니다. 전달 확인됨 역방향 DNS 그런 다음 해당 호스트 이름이 원래 주소로 다시 확인되는지 확인합니다. 두 번째 단계에서는 일반적인 불일치를 포착하지만 일치 항목을 통해 보낸 사람이 신뢰할 수 있거나 메시지의 보낸 사람 도메인을 사용할 권한이 있는지 확인하지 않습니다.

비교 정의

참고자료: RFC 1912 §2.1, RFC 3596 §2.1, RFC 4291 §2.2.

관찰된 SMTP 소스 주소를 시작 값으로 사용합니다. PTR 레코드를 쿼리합니다. 반환된 각 호스트 이름에 대해 적절한 전달 주소 유형( IPv4 소스의 경우 A, IPv6 소스의 ​​경우 AAAA)을 쿼리합니다. 동등한 텍스트 형식이 동일하게 처리되도록 IPv6 용 IP 구문 분석기를 사용하여 주소 값을 비교합니다.

이 가이드의 진단에서 확인은 반환된 호스트 이름의 전달 주소 중 하나 이상에 원래 IP가 포함되어 있음을 의미합니다. 호스트별 결과와 해당 요약을 보존합니다. 이는 모든 수신자가 동일한 선택 정책을 구현하거나 모든 PTR 결과를 확인한다는 약속이 아니라 명시적으로 정의된 진단 규칙입니다.

실패를 명확하게 유지

참고자료: RFC 1035 §4.1.1, RFC 2181 §10.2.

PTR 응답 없음, 일치하는 주소가 없는 호스트 이름, DNS 시간 초과 및 유효성 검사 실패는 서로 다른 결과입니다. 시간 초과는 기록이 없음을 증명할 수 없습니다. IPv4 A 일치는 IPv6 소스에 대한 확인을 설정하지 않습니다. 모든 결과를 하나의 빨간색 배지로 축소하는 대신 응답 코드와 타이밍을 유지하세요.

호스트 이름에 대해 반환된 첫 번째 주소에서 멈추지 마십시오. 호스트에는 여러 개의 주소가 있을 수 있으며 원래 주소는 집합의 뒷부분에 있을 수 있습니다. 대시보드는 여러 PTR 이름을 자동으로 삭제해서는 안 됩니다. 정확히 무엇이 일치하는지 설명하려면 기본 결과가 필요합니다.

합성 테스트 세트 계산

사례 A는 다음에서 시작됩니다. 192.0.2.25. PTR 반환 smtp.example.com; 그 이름의 A 세트는 192.0.2.24, 192.0.2.25. 원래 주소가 집합의 구성원이므로 예상한 결과가 확인되었습니다. 전체 세트와 동일할 필요는 없습니다.

사례 B는 동일한 PTR 사용하지만 A 세트에는 192.0.2.24. 예상 결과가 일치하지 않습니다. 사례 C는 정방향 조회에서 시간 초과를 수신합니다. 예상 결과가 해결되지 않았으며 불일치가 아닙니다. 사례 D는 다음에서 시작됩니다. 2001:db8::25 타겟의 AAAA 답변은 다음과 같습니다. 2001:0db8:0000:0000:0000:0000:0000:0025. 예상 결과는 둘 다 IPv6 주소로 정규화한 후 확인됩니다.

Fixture Resolver 또는 격리된 영역을 사용하여 이러한 사례를 재현합니다. 각 사례에 대해 소스 IP, PTR 응답, 전달 응답, 쿼리 유형 및 계산된 멤버십 결과를 저장합니다. 간단한 구현은 각 주소를 구문 분석하고 소스가 반환된 세트에 있는지 평가하는 동시에 해당 멤버십 단계 전에 DNS 오류를 처리합니다. 이러한 예상 결과는 생산 수신기가 테스트되었다고 주장하지 않습니다.

불일치의 소유자 측을 수리하십시오.

참고자료: RFC 1035 §3.5, RFC 8767 §4.

PTR 이 잘못된 경우 역방향 운영자와 협력하십시오. 전달 주소가 잘못된 경우 호스트 이름의 권한 있는 DNS 운영자에게 문의하세요. 둘 다 권한에서는 정확하지만 확인자에서는 정확하지 않은 경우 캐싱 또는 서로 다른 견해를 조사하십시오. 순차적 변경이 지속적인 불일치로 잘못 진단되지 않도록 동시에 양방향에 대한 증거를 보관하십시오.

마지막으로 실제 SMTP 경로를 테스트하고 수신자 응답을 유지합니다. 전달 확인은 DNS 데이터의 일관성 속성입니다. 공격자는 일치하는 정방향 및 역방향 레코드를 작동할 수 있으며 합법적인 공급자는 여전히 손상된 구성을 가질 수 있습니다. 인증 및 남용 제어 대신에 발견 항목을 함께 사용하십시오.

증거 범위를 명시적으로 유지하세요.

확인, 불일치, 미해결, 확인 등 네 가지 합성 사례는 주소 멤버십 및 정규화만으로 확인할 수 있습니다. 로컬 계산은 PTR 또는 정방향 조회를 수행하지 않으며, 수신자를 실행하거나 평판을 측정하지 않습니다.

[ 테이크아웃 ]

전체 전달 주소 집합에서 정규화된 IP 값을 비교합니다. 시간 초과, 부재 및 불일치를 다른 결과로 유지합니다. DNS 일관성은 발신자 인증이나 안전을 보장하지 않습니다.

[ 역할별 ]

이것이 당신에게 의미하는 바

실용적인 다음 단계를 위해 역할을 선택하세요.

IT/메일 관리자

주소 멤버십을 신중하게 계산하세요.

반환된 전체 주소 집합과 정규화된 IP 값에 따라 명시된 진단 결과가 결정됩니다.

다음 단계

  1. 반환된 모든 주소를 평가합니다.
  2. 비교하기 전에 IP 값을 정규화합니다.
  3. 오류를 불일치와 분리하여 유지하세요.

CISO/SecOps

평판 결론을 피하십시오

악의적인 인프라에도 일관된 정방향 및 역방향 데이터가 존재할 수 있습니다.

다음 단계

  1. 확인을 제한된 일관성 신호로 취급하십시오.
  2. 두 조회 방향 모두에 대한 증거를 검토합니다.
  3. 독립적으로 인증을 확인하세요.

창립자 / 비기술자

양측의 소유권 해결

역방향 및 순방향 불일치로 인해 두 서비스 소유자 간의 조정이 필요할 수 있습니다.

다음 단계

  1. 해결되지 않은 사례에 두 DNS 소유자를 모두 할당합니다.
  2. 명확한 결과 정의가 필요합니다.
  3. 한 번의 확인으로 안전에 대한 주장을 피하십시오.

[ 자주 묻는 질문 ]

자주 묻는 질문

PTR 만으로는 전달 확인이 가능한가요?

아니요. 반환된 호스트 이름을 확인하고 주소를 비교해야 합니다.

RFC 1912 §2.1

전달 응답에는 주소가 하나만 포함되어야 합니까?

아니요. 원본 소스는 이 진단에 설정된 관련 주소에 있어야 합니다.

처음 반환된 주소가 다른 경우에는 어떻게 되나요?

전체 세트를 확인하세요. 답변 순서는 불일치의 증거가 아닙니다.

시간 초과는 호스트 이름이 일치하지 않는다는 것을 의미합니까?

이는 검사가 해결되지 않았음을 의미합니다. 누락된 증거를 불일치로 대체하지 마십시오.

A 결과로 IPv6 소스를 확인할 수 있습니까?

아니요. 해당 IPv6 소스에 관련 AAAA 주소를 사용하세요.

RFC 3596 §2.1

다르게 압축된 IPv6 문자열은 항상 다릅니까?

아니요. 비교하기 전에 구문 분석하고 정규화하세요.

RFC 4291 §2.2

확인을 통해 보낸 사람이 안전하다는 것을 증명할 수 있나요?

아니요. 이는 선의의 의도나 도메인 인증이 아닌 DNS 일관성을 설정합니다.

불일치를 해결하는 사람은 누구입니까?

어떤 레코드가 잘못된지에 따라 PTR 운영자 또는 정방향 영역 운영자입니다.

[ 출처 ]

출처

  1. RFC 1035

    섹션 §3.5 · §4.1.1

  2. RFC 1912

    섹션 §2.1

  3. RFC 2181

    섹션 §10.2

  4. RFC 3596

    섹션 §2.1

  5. RFC 8767

    섹션 §4

  6. RFC 4291

    섹션 §2.2

[ 어휘 ]

어휘

전달 확인
이 가이드에서는 하나 이상의 PTR 대상에 원본 소스 IP가 포함된 관련 전달 주소 세트가 있습니다. 이는 보편적인 수신기 규칙이 아닌 정의된 진단입니다.
정규화된 IP 값
동등한 IPv6 텍스트 형식을 동일한 주소로 처리하는 구문 분석된 주소 값입니다.

RFC 4291 §2.2

기업 출처

최고의 금융 기관과 정부가 필요한 이유 이메일 보안 대시보드를 폐기했습니다.

기존 이메일 인증 플랫폼은 대시보드를 판매하고 엔지니어에게 작업을 요청합니다. 위험이 높은 환경에서 수동 감독은 시행 지연, 구성 드리프트 및 모니터링되지 않는 섀도우 도메인을 의미합니다.

EmailAuth 는 에이전트 이메일 출처 플랫폼입니다. 우리 대리인은 집행합니다 p=reject, 제3자 발신자를 정렬하고 도메인을 전체로 이동하세요. RFC 9989 인간 참여형 감사 기능을 갖춘 새로운 DMARC 표준을 준수합니다.

정부 대기업 1등급 금융기관

SaaS · 전용 테넌시 · Air-Gapped 온프레미스 · BYOK 암호화

기술 자료