
내가 이해한다면RFC1912섹션 2.1이 올바르게 적용되면 다음 규칙이 PTR 레코드에 적용됩니다.
1) 모든 작동 IP에는 PTR 레코드가 있어야 합니다.
2) PTR과 A 레코드가 일치해야 합니다(일반적으로 확인되지는 않지만).
이제 작동하는 IP(내 경우에는 IPv6)가 있고 올바른 PTR 레코드를 설정하고 싶지만(내 ISP가 수행할 수 있는 작업) IP가 설정하지 않는 경우 어떻게 해야 합니까?~ 아니다A 또는 AAAA 레코드가 있나요? 서버가 아닌 자체 도메인 없이 인터넷에 연결된 클라이언트일 뿐입니다(그러나~ 아니다NAT 뒤에는 여기서 IPv6에 대해 이야기하고 있습니다.)
작동하는 IP가 있으므로 PTR 레코드가 정의되어 있어야 하지만(1), 무엇을 가리켜야 합니까(2)?
답변1
댓글에 다음과 같이 작성하셨습니다.
A나 AAAA 레코드가 없습니다. 호스트 이름이 전혀 없는 클라이언트만 있을 뿐입니다. 그러나 이는 여전히 작동하는 IP 주소이며 표준에 따라 PTR 레코드가 있어야 합니다.
먼저,RFC 1912, "일반적인 DNS 작동 및 구성 오류"는정보 제공.즉, 정보와 안내를 제공하지만표준을 지정하거나 요구 사항을 성문화하려고 시도하지 않습니다.RFC의 다른 범주에는 작업 수행 방법에 대한 실제 요구 사항이 있습니다. 예를 들어, HTTP/1.1 서버를 작성한 다음 응답 코드 301에 지정된 것 이외의 의미를 부여할 수 없습니다.RFC 2616 섹션 10.3.2; 그렇게 한다면 HTTP/1.1을 구현하는 것이 아니라 아마도 HTTP/1.1을 따라 패턴화된 다른 것을 구현하는 것입니다.
RFC 1912는 RFC 1912보다 약 1년 더 오래되었으므로RFC 2119("요구 사항 수준을 나타 내기 위해 RFC에 사용되는 핵심 단어") 후자를 RFC 1912에 구체적으로 적용할 수는 없지만 RFC 2119는 여전히 다음을 제공할 수 있습니다.어느 정도의 지도"해야 한다", "해야 한다" 등과 같은 용어를 해석하는 방법에 대해 알아보세요. 특히 RFC 2119에서는 다음과 같이 해석해야 한다고 명시하고 있습니다.
해야 하다이 단어 또는 "필수" 또는 "SHALL"이라는 용어는 정의가 사양의 절대 요구 사항임을 의미합니다.
해야 한다이 단어 또는 형용사 "권장"은 특정 상황에서 특정 항목을 무시할 타당한 이유가 있을 수 있지만 다른 과정을 선택하기 전에 전체 의미를 이해하고 신중하게 평가해야 함을 의미합니다.
RFC 1912, 섹션 2.1에는 부분적으로 다음과 같이 명시되어 있습니다(필자가 강조함).
인터넷에 연결할 수 있는 모든 호스트~해야 한다이름이 있어요. 이로 인한 결과는 점점 더 분명해지고 있습니다. 인터넷에서 사용할 수 있는 많은 서비스는 귀하가 DNS에 올바르게 등록되지 않은 경우 귀하와 대화할 수 없습니다.
확실하게 하다PTR과 A 레코드가 일치합니다. 모든 IP 주소에 대해~해야 한다in-addr.arpa 도메인에서 일치하는 PTR 레코드여야 합니다. 만약에호스트가 멀티홈입니다(둘 이상의 IP 주소).확실하게 하다모든 IP 주소에는 해당 PTR 레코드가 있습니다(첫 번째 주소뿐만 아니라). 일치하는 PTR 및 A 레코드가 없으면 DNS에 전혀 등록되지 않는 것과 유사한 인터넷 서비스 손실이 발생할 수 있습니다. 또한 PTR 레코드~ 해야 하다CNAME에 의해 정의된 별칭이 아닌 유효한 A 레코드를 다시 가리킵니다.
첫째, 첫 번째 진술은 "해야 한다"인데, 이는 이것이 절대적인 요구 사항이 아니라는 것을 즉시 의미합니다. 요건일 수도 있어요어떤 특정한 경우에는이것이 언급된 이유이지만 일반적인 경우에는 필수 사항이 아닙니다.
"확인"으로 시작하는 두 번째 단락을 사용하여 관리자에게 더 강력한 요구 사항을 적용하겠습니다. 다음 문장이 다시 말합니다.~해야 한다, 아니다~ 해야 하다또는 그 변형.
여기서 결론은 두 가지입니다.
- IP 주소에 매핑되는 전역적으로 고유한 호스트 이름이 필요하지 않은 경우 DNS에 호스트 이름을 추가할 필요가 없습니다. (어떤 서비스도 노출하지 않고 원하는 서비스를 사용하는 데 문제가 없는 클라이언트 전용 시스템이라면 적어도 당분간은 그럴 필요가 없습니다.)
- DNS에 IP 주소에 매핑되는 호스트 이름이 없으면 IP 주소에 대한 PTR 레코드가 가리키는 것이 없으므로 IP 주소에 대한 PTR 레코드를 추가하거나 추가할 수 없습니다. (이는 PTR 레코드가 해당 주소 레코드가 있는 호스트 이름을 가리켜야 한다는 요구 사항에 따른 것입니다.)
여담이지만 실제로는 호스트, IP 주소, DNS 이름 간에 일대일 매핑이 필요하지 않습니다. 예를 들어, 저는 3개의 고유한 IP 주소가 있고 직접 주소 레코드와 CNAME을 통해 서로 다른 IP 주소를 가리키는 여러 이름이 있는 서버 호스트를 담당하고 있지만 해당 IP 주소 중 하나만 올바른 역방향 이름( 문제의 IP 주소로 다시 상응하는 전달 매핑).
답변2
어떤 기록을 만들어야 하는지에 대한 엄격한 규칙은 없습니다. 동일한 IP 주소를 가리키는 A 및/또는 AAAA 레코드가 많을 수도 있고 없을 수도 있습니다. 주소에 대한 역방향(PTR) 레코드가 있을 수도 있고 없을 수도 있습니다. 실제 규칙이 없기 때문에 이러한 경우에 대해 유효하거나 유효하지 않은 것은 없습니다.
그러나 특정 기대가 있습니다. 그 중 하나는 메일 서버를 실행하는 경우 메일 서버가 다른 메일 서버에 연결하는 데 사용하는 IP 주소에는 해당 IP 주소에 대한 A 또는 AAAA 레코드가 있는 호스트 이름을 가리키는 PTR 레코드가 있어야 한다는 것입니다.
예를 살펴보겠습니다:
- 메일 서버에 IPv4 주소가 있습니다
192.0.2.1
1.2.0.192.in-addr.arpa
blabla.example.com을 가리키는 PTR 레코드가 있습니다.- blabla.example.com에 다음을 가리키는 A 레코드가 있습니다.
192.0.2.1
이렇게 하면 이름이 가짜인 경우 도메인 소유자가 자신의 영역 내에 올바른 A 레코드를 생성하지 않았기 때문에 PTR 레코드를 도메인 기반 평판 기반 필터링에 사용할 수 있습니다.
이 확인 전략으로 인해 PTR 레코드가 A 또는 AAAA 레코드와 일치하지 않으면 '신뢰'가 낮아집니다. 누구나 다음을 가리키는 PTR 레코드를 만들 수 있지만 something.important.google.com
해당 이름이 실제로 존재하는 경우 Google만이 해당 이름에 일치하는 A/AAAA 레코드를 만들 수 있습니다. A/AAAA 레코드가 존재하지 않는다고 해서 해당 주소가 Google에서 온 것이 아니라는 것을 증명할 수는 없지만 이를 확인하는 것도 아닙니다.
이러한 모든 레코드에도 동일하게 적용됩니다. 일치하는 A/AAAA 및 PTR 레코드를 생성하는 것이 일반적이지만 필수 사항은 아닙니다. 일치하는 기록을 적용하는 것은 대부분 해당 IP 주소에서 메일을 수신하는 서버입니다.
RFC1912는 인터넷 표준이 아닌 일반적인 관행을 설명하는 정보 제공용 RFC입니다. 귀하의 PTR 기록은 기술적으로 귀하가 원하는 곳 어디든 가리킬 수 있지만, 귀하의 것이 아닌 도메인 이름을 가리킨다면 이는 매너에 어긋나는 일입니다. PTR 레코드를 정말로 갖고 싶지만 일치하는 A/AAAA 레코드를 생성하고 싶지 않다면(이유는 알 수 없지만 괜찮습니다) 자신의 도메인 중 하나에 존재하지 않는 이름을 가리키도록 하십시오. 자신의 도메인이 없다면 도메인을 갖고 있는 사람에게 자신의 도메인을 알려줄 수 있는지 물어보세요.
답변3
RFC1912는 오래되고 정보 제공용입니다. 표준으로 발전한 적이 없으므로 구현할 필요가 없으므로 일반적으로 아무도 신경 쓰지 않습니다. 메일 서버와 보안 FTP 서버를 제외하고 대부분의 사람들이 대부분의 경우 해당 조언을 무시한다는 것을 알게 될 것입니다. 또한 AAAA 레코드도 다루지 않습니다.
결론적으로, 걱정할 필요가 없습니다.