DNS에 여러 개의 PTR 레코드가 권장되지 않는 이유는 무엇입니까?

나는 종종 읽기 는 DNS 구성에서 여러 PTR 레코드를 사용하지 않는 것이 좋습니다 것이다.

그러나 그 이유는 종종 모호하거나 명백하지 않은 이름입니다.

• "문제를 일으킬 수 있습니다",
• "단일 답변을 기대하는 프로그램에서 버그를 유발할 수 있습니다": 그것은 소프트웨어의 문제입니까?
• "DNS 응답 패킷을 너무 크게 만들 수 있습니다": EDNS로 고정되어 있지 않습니까?

이것이 좋은 이유입니까? 다른 좋은 이유를 알고 있습니까? 이 모든 것이 "레거시 두려움"처럼 보입니다 ...

PTR역 이름 (예 : 대한 기록은 7.2.0.192.in-addr.arpa)를 식별 할 것으로 예상된다 정식 이름 이 IP 주소와 연결되어 있습니다.

네트워크 노드의 게이트웨이 포인터와 전체 주소 노드의 일반 호스트 포인터는 PTR RR을 사용하여 해당 호스트의 기본 도메인 이름을 다시 가리 킵니다.

보낸 사람 : http://tools.ietf.org/html/rfc1035#section-3.5

이러한 기대는 역방향 조회를 수행하는 소프트웨어에 반영됩니다. 종종 이러한 소프트웨어는 특히 단일 이름을 요구하며 해당 이름을 해당 호스트의 정식 이름으로 사용할 수있을 것으로 기대합니다. 여러 개의 이름이 반환되면이 특정 경우에 어떤 이름을 선호하는지 알 수있는 방법이 없기 때문에 무작위로 하나만 사용하는 것이 일반적입니다.

일반적으로 IP 주소와 관련된 정식 이름이 하나 있고 그 이름이 PTR가리켜 야 할 것이기 때문에 여러 이름을 추가하면 일반적으로 거꾸로되지 않지만 (임의의 A/ AAAA레코드가 일치 할 것으로 예상되는 것은 없음 PTR) 가능성이 있습니다. PTR하나 이상의 레코드를 추가하면 어떤 레코드를 사용할지 제어 할 수 없으므로 이상한 결과가 발생할 수 있습니다 .

본질적으로 여러 개의 PTR레코드가있는 경우 실제로 호스트를보다 합법적으로 보이게하지 않고 오히려 반대로 보이게하면 일부 유효성 검사에 실패하거나 무언가를 위반할 위험이 있습니다.

어쩌면 다소 극단적 인 은유로서, 사진과 함께 공항에서 이름이 다른 여권 5 장을 모두 넘겨주는 것은 아마 당신이 단지 하나를 넘겨주는 것처럼받지 못할 것입니다.

RFC는 이러한 PTR 레코드를 처리 할 수있는 제한이나 방법을 강요하지 않기 때문에 예측할 수없는 동작으로 이어집니다. 대부분의 구현은 라운드 로빈을 선택하고 원하는 결과를 얻지 못합니다 (많은 이름을 단일 IP로 완벽하게 일치).

https://supernoc.rogerstelecom.net/pdfs/multiple-ptrs.pdf에 대한 자세한 내용은 여기를 참조 하십시오.

또한 Glibc의 getnameinfo 함수 ( https://sourceware.org/bugzilla/show_bug.cgi?id=5790 ) 에서이 버그를 확인하십시오 . 인터넷에서 무한한 수의 서로 다른 시스템 (이들 중 일부는 매우 오래되고 패치되지 않은 시스템)에서 이것이 일어나지 않도록 어떻게 보장 할 수 있습니까?

경험상, 강화하지 않으려면, 예측할 수없고 예측할 수없는 행동을 피하는 것이 좋습니다. 불행하게도, 단일 IP에 대한 여러 PTR 레코드가 RFC에 관한 한 해당 범주에 속합니다.

PTR이 여러 개인 경우 PTR이 특정 선물 레코드와 일치하도록 어떻게 보장합니까?

메일 서버 상호 작용에서 특히 중요합니다. 대부분의 인바운드 수신 SMTP 서버는 전달이 역방향과 일치하는지 확인합니다.

PTR이 여러 개이며 어떤 PTR이 선택되어 있고 연결에서 제공 한 전달과 일치하는지 보장 할 방법이 없습니다.

완벽한 일치를 보장하는 가장 쉬운 방법은 선행 항목과 일치하는 하나의 PTR을 갖는 것입니다.