☰

클래스 없는 역방향 맵 위임은 "dig -x"와 함께 작동하지 않습니다. 어떤 영향을 미치나요?

tag-icon • tag-icon domain-name-system bind dns-zone
클래스 없는 역방향 맵 위임은 "dig -x"와 함께 작동하지 않습니다. 어떤 영향을 미치나요?

인터넷Zytrax.com, 내가 배운 곳클래스 없는 역지도 위임dig -x <ip address>, 이 위임 방법(CNAMES 사용)을 사용하는 경우에는 작동하지 않는다고 말합니다 .

예를 들어:

이것은 작동하지 않습니다: dig -x 192.168.23.66

그리고 이것은 작동할 것으로 예상됩니다: dig 66.64/27.168.192.IN-ADDR.ARPA

그리고 약간 수정하면 작동합니다(위임된 서버를 지정하고 PTR 레코드를 원함). dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA

튜토리얼에 설명된 대로 작동하는 것 같습니다.

유사한 위임을 설정했는데 위에서 설명한 대로 작동합니다. dig -x위임된 범위의 IP 주소를 사용하면 위임 네임 서버는 누가 권한을 가지고 있는지 알려줍니다. 클래스 없는 네트워크가 위임된 서버는 세 번째 명령( ) 66.64/27.168.192.IN-ADDR.ARPA.으로만 작동합니다. dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA.

괜찮고 안전한가요?

dig -x(혹은 nslookup)로는 안되는데, 안되는게 더 있는지 궁금합니다. 확인자가 문제 없이 이러한 IP 주소를 확인할 수 있습니까? 예를 들어, 이 위임 방법을 사용하면 이메일 서버가 문제 없이 역조회를 수행할 수 있습니까? 사용하지 말아야 할 이유가 있나요?

나의 예(약간 수정됨):

dig @ns1.example.com -x 192.168.134.1

;; ANSWER SECTION:
1.134.168.192.in-addr.arpa. 60  IN  CNAME   1.0-127.134.168.192.in-addr.arpa.
;; AUTHORITY SECTION:
0-127.192.113.134.in-addr.arpa. 10 IN   NS      ns2.example.com.


dig @ns2.example.com PTR 1.0-127.192.168.134.in-addr.arpa.

;; ANSWER SECTION:
1.0-127.192.168.192.in-addr.arpa. 10 IN PTR     1st_super.example.com.

왜 작동하지 않았나요?

위임한 존의 이름이 잘못되어 두 번째 질의에서 잘못된 이름을 사용하여 답변을 받았습니다(두 실수가 부분적으로 상쇄됨).

틀렸음(반전되지 않음):

0-127.192.168.134.in-addr.arpa.

다음과 같았어야 합니다:

0-127.134.168.192.in-addr.arpa.

이 오류가 수정되고 위임 서버가 위임 영역의 슬레이브가 되어 dig -x <ipaddress>작동합니다.

답변1

TL;DR

당신이RFC2317-style classless in-addr.arpa 위임의 경우, IP 주소의 역매핑을 사용하여 하위 위임에 대한 권한 있는 네임서버를 직접 쿼리할 수 없는 것은 완전히 정상입니다. 정말 중요한 것은 확인자 서버가 역방향 이름(예 : 사용자 환경/사용 사례와 관련된 모든 IP 주소 및 확인자 서버 조합)
을 조회할 수 있다는 것입니다 .dig -x 192.0.2.1 @8.8.8.8

RFC2317 설명

RFC2317이 일종의 해결 방법을 제공하는 전반적인 문제는 IPv4 주소에서 DNS의 역방향 이름으로의 규칙 기반 매핑(예: 192.0.2.1-> 1.2.0.192.in-addr.arpa)이 클래스 없는 위임보다 먼저 발생하고 가능한 위임 지점을 /0, /8, 16, /24, 에 효과적으로 잠그는 방식입니다 /32. (각 레이블에서만 위임할 수 있으며 매핑은 단순히 IPv4 주소의 각 옥텟을 레이블로 만들기 위해 역순으로 정의됩니다.)
매핑은 좀 ​​더 세분화된 명명 체계에 매핑하여 다르게 정의해야 했을 것입니다. 실제로 /27위임과 같은 것을 허용합니다.

RFC2317은 근본적인 상황을 변경하지 않으며 실제로 어떤 방식으로든 프로토콜을 변경하지 않습니다.
그것이 하는 일은 계급 없는 위임이 불가능하다는 한계를 해결하기 위해 인간 운영자가 사용할 수 있는 계획을 제안하는 것뿐입니다.

그 계획은 다음과 같이 요약될 수 있습니다.

  1. 명명 규칙에 따라 실제 역방향 영역의 일부 이름 집합에 대한 별칭(레코드 추가)을 정의하고 CNAME이를 새 이름에 매핑합니다.새 네임스페이스
    (새 네임스페이스는 실제로어느그러나 RFC2317에서는 설명이 포함된 이름을 사용하고 새 네임스페이스를 기존 영역의 하위 항목으로 사용하도록 제안합니다 in-addr.arpa.
  2. 이에 해당하는 영역을 위임합니다.새 네임스페이스필요에 따라

결과적으로 조회를 요청한 확인자 서버는 1.2.0.192.in-addr.arpa정상적으로 해당 작업을 수행하고 실제로 찾고 있던 레코드 CNAME대신 해당 레코드를 실행하게 됩니다. 그런 다음 기존 RFC2317에 대한 지식이 없어도 새 네임스페이스로 간단히 들어가며 , RFC2317에서 제안한 대로 설정한 경우 해당 새 이름에서 사용할 수 있는 a를 찾습니다 .PTR
CNAMEPTR

2.0.192.in-addr.arpa.예를 들어 다음이 포함된 영역이 있는 경우 ns1.other.example.:

1.2.0.192.in-addr.arpa. IN CNAME 1.0/27.2.0.192.in-addr.arpa.
0/27.2.0.192.in-addr.arpa. IN NS ns7.example.com.

실제 역 이름( 1.2.0.192.in-addr.arpa.)에 대한 조회 프로세스의 결과는 이고 CNAME, 확인자는 CNAME어디로 가는지 따라가며 정상적으로 처리합니다.

이 예에서는 로 연결되고 영역 에 1.0/27.2.0.192.in-addr.arpa.대한 위임도 있으므로 확인자는 에 대한 조회 프로세스를 계속할 수 있습니다.0/27.2.0.192.in-addr.arpa.ns7.example.com.새 이름그러면 다 잘 될 거예요.

반면에 쿼리를 보내면 해당 쿼리에 1.2.0.192.in-addr.arpa.대해 ns7.example.com.아무것도 알 수 없습니다.
ns7.example.com. 하지 않습니다해당 주소에 대한 역방향 영역이 있으면 실제 역방향 영역이 이러한 별칭으로 참조하는 느슨하게 관련된 영역만 있습니다.

RFC2317 스타일 위임이 작동하는지 확인하려면 먼저 실제 확인자가 이름 조회에 성공하는지 확인하면 됩니다.
그러나 세부 사항을 자세히 살펴보면 실제 역방향 영역의 네임서버가 무엇으로 응답하는지( CNAME이 경우 a여야 함) 확인하고 표준 이름( CNAME"대상")이 위임된 위치를 확인한 다음 해당 네임서버가 응답하는지 확인합니다. 레코드 에 지정된 정식 이름을 위해 의도된 대로입니다 CNAME.

관련 정보