인터넷 표준에 따라 모든 장치에 역방향 DNS가 필요합니까?

역방향 DNS를 둘러싼 요구 사항이 혼란 스럽습니다! 사람들 은 리버스 DNS가 존재하지 않으면 모든 것이 깨지는 것에 대해 자주 이야기 하며, 그것은 무서운 것처럼 들립니다. 응용 프로그램에 역방향 DNS가 필요하지 않은 경우에도 필수 PTR 레코드 생성을 지원하기 위해 RFC가 자주 인용됩니다.

이러한 RFC 중 일부에는 다음이 포함됩니다.

RFC1912 : 일반적인 DNS 운영 및 구성 오류

인터넷에 연결할 수있는 모든 호스트의 이름이 있어야합니다. ... PTR과 A 레코드가 일치하는지 확인하십시오. 모든 IP 주소에 대해 in-addr.arpa 도메인에 일치하는 PTR 레코드가 있어야합니다. 호스트가 멀티 홈 인 경우 (하나 이상의 IP 주소) 모든 IP 주소에 첫 번째 IP 주소뿐만 아니라 해당 PTR 레코드가 있는지 확인하십시오. 일치하는 PTR 및 A 레코드가 없으면 DNS에 전혀 등록되지 않은 것과 유사한 인터넷 서비스가 손실 될 수 있습니다.

RFC1033 : 도메인 관리자 운영 안내서

호스트 추가

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

그럼에도 불구하고 일부 사람들은 여전히 DNS 관리에 관한 표준에서 PTR 레코드 생성 이 필요 하지 않다고 주장합니다 . 실제 요구 사항은 무엇입니까?

짧은 답변

DNS 작업을 관리하는 표준에 따라 모든 장치에 일치하는 PTR 레코드가 있어야합니까? 아니.

특정 프로토콜의 표준 PTR에는 해당 A또는 AAAA레코드 와 일치하는 레코드가 필요 합니까? 예.

RFC가 적용되지 않는 일부 응용 프로그램의 요구 사항이 동일합니까? 예.

PTR 레코드가 CNAME을 가리킬 수 있습니까? 예. 그러나 CNAME 대상은 해당 장치의 고유 한 이름이어야하며 다른 CNAME은 아니어야합니다. ( RFC 2181§10.2 , RFC1034 §3.6.2 )

필수 PTR 레코드 생성이 모범 사례입니까? 일반적으로 그렇게 믿지만 자체 문제가 있습니다.

긴 답변

이 Q & A는 일반적인 오해를 막기 위해 마련되었습니다.

의 비극적 underquoted 섹션 RFC1796는 여기에 적용

유감스럽게도 RFC로 출판하면 어느 정도의 인식이 가능하다는 오해가 있습니다. 그것은 일반 저널에 출판 된 것 이상이거나 적어도 그 이상이 아닙니다. 실제로 각 RFC는 정보, 실험 또는 표준 트랙 (제안 표준, 초안 표준, 인터넷 표준) 또는 기록과 같은 인터넷 표준화 프로세스와의 관계와 관련하여 상태가 있습니다.

RFC1912는 정보 용입니다. RFC1033은 명확하게 표시되어 있지 않으며 공식적으로 UNKNOWN 으로 지정되어 있습니다 . 이는 너무 오래 되어 어떤 것에 대한 참조로 간주되어서는 안됩니다 . 표준을 정의하지 않으며 공식적으로 표준을 보강하는 데 사용될 수도 없습니다. 표준을 정의하고 있음을 암시하는 맥락에서 인용해서는 안됩니다.

Informational RFC 제안은 좋은 조언과 일반적으로 인정되는 모범 사례로 생각하십시오. 역방향 DNS 권장 사항은 한눈에 이해됩니다.이 지침을 따르면 역방향 DNS가 필요하고 계획되지 않았기 때문에 응용 프로그램이 작동하지 않는 상황에 빠질 위험이 줄어 듭니다. 확실히 DNS 관리자가 필요한 모든 응용 프로그램 / 프로토콜을 알 것으로 기대할 수는 없으며, 슬프게도 해당 레코드를 요청하는 서비스 소유자도 마찬가지입니다.

즉, 매우 우수한 자동화 이외의 필수 PTR 레코드 생성 정책도 오염을 유발합니다.

• 장치가 폐기 될 때 레코드 PTR가 해당 A/ AAAA레코드 와 동기화되지 않는 것은 매우 흔한 일 이므로 PTR시간이 지남에 따라 가짜 데이터가 발생합니다. 이 데이터는 해당 정보를 신뢰할 수있는 것으로 취급하려는 사람들을 오도하기위한 것입니다. 일부 응용 프로그램 소유자는 팬텀 문제의 원인을 찾고있을 때 뛰어 넘기를 열망합니다. IPv6 채택이 더욱 일반화되면서 특히 통신 사업자 크기의 IP 공간을 담당하는 DNS 관리자의 경우 문제는 계속 악화 될 것입니다.
• 동일한 IP 주소에 대해 여러 개의 PTR 레코드를 갖는 것은 무의미하며 정보 RFC의 조언을 준수하면 필연적으로 결과가 발생합니다. 참조 : DNS에서 여러 PTR 레코드를 사용하지 않는 것이 좋습니다 이유는 무엇입니까?

더 나쁜 것은 PTR 레코드가 없거나 부정확 한 PTR 레코드입니까? 표준에 유효한 DNS가 필요하기 때문에 프로토콜이 중단되면 둘 다 나쁘고 실제로 나빠질 수 있습니다 . 그 외에는 모든 사람들이 그 문제에 대해 다른 의견을 가지고 있습니다. 괜찮습니다. 팀과 회사에 가장 적합한 정책과 도구를 자유롭게 구성 할 수 있습니다. 일관성있게 결과를 확장하고 산출 할 수 있도록하십시오. 리버스 DNS는 팀 구성원이 제공 한 시간과 규율만큼 정확할 것입니다.

그러나 PTR 레코드가 없으면 sshd가 중단됩니다!

또한 사실이 아닙니다. 사람들은 종종 PTR 레코드 (NXDOMAIN)가없고 역 DNS가 깨지는 것을 혼동합니다 .

NXDOMAIN정답 확인 역방향 DNS (FCrDNS)가 필요한 서비스와 통신하는 경우에만 응답 하면 문제가 발생합니다. 메일 서버, Kerberos, Oracle 스캔 VIP 등

손상된 역방향 DNS는 NXDOMAIN적시에 응답 을받을 수없는 경우 입니다. 많은 응용 프로그램 (가장 유명 sshd)은 적시에 업스트림 소스로부터 응답을 얻는 데 문제가 있으면 응용 프로그램 내에서 지연을 발생시키는 경우 역방향 DNS 조회를 차단합니다.