CIDR 세계에서 역 DNS

리버스 DNS는 클래스 경계와 밀접한 관련이있는 것 같습니다. CIDR이 서브넷에 대한 권한을 위임하는 표준이기 때문에 현재 어떤 방법이 있습니까? 여러 방법이있는 경우 어떤 방법이 가장 좋습니까? DNS 서버 (Bind, djbdns, Microsoft DNS 등)에 따라 위임을 다르게 처리해야합니까? 클래스 B 168.192.in-addr.arpa 인 네트워크를 제어 할 수 있다고 가정 해 보겠습니다.

• / 22의 권한을 위임하는 방법?
• / 25의 권한을 위임하는 방법?

/ 22의 위임은 쉽습니다. 4/24의 위임입니다. / 14는 4/16 등의 위임입니다.

RFC2317 은 / 24보다 긴 넷 마스크로 특수한 경우를 다룹니다. 기본적으로 옥텟 경계 이외의 영역에서 in-addr.arpa 영역을 위임 할 수있는 확실한 방법은 없지만이 문제를 해결할 수 있습니다. IP 주소 172.16.23.16-> 172.16.23.23이 될 172.16.23.16/29를 위임한다고 가정 해 봅시다.

23.16.172.in-addr.arpa 영역의 소유자로서이 범위를 내 고객에게 위임하기 위해 23.16.172.rev 영역 파일에 넣을 수 있습니다.

16-29              IN NS  ns1.customer.com
16-29              IN NS  ns2.customer.com
16                 IN CNAME    16.16-29.23.16.172.in-addr.arpa.
17                 IN CNAME    17.16-29.23.16.172.in-addr.arpa.
18                 IN CNAME    18.16-29.23.16.172.in-addr.arpa.
19                 IN CNAME    19.16-29.23.16.172.in-addr.arpa.
20                 IN CNAME    20.16-29.23.16.172.in-addr.arpa.
21                 IN CNAME    21.16-29.23.16.172.in-addr.arpa.
22                 IN CNAME    22.16-29.23.16.172.in-addr.arpa.
23                 IN CNAME    23.16-29.23.16.172.in-addr.arpa.

따라서 새 영역 (16-29.23.16.172.in-addr.arpa.)을 정의하고이를 고객의 이름 서버에 위임하고 있음을 알 수 있습니다. 그런 다음 IP에서 CNAME을 생성하여 새로 위임 된 영역에서 해당 번호로 위임합니다.

위임 된 고객으로서 named.conf에서 다음과 같은 작업을 수행합니다.

zone "16-29.23.16.172.in-addr.arpa" { 
    type master;
    file "masters/16-29.23.16.172.rev";
};

그런 다음 .rev 파일에서 일반적인 in-addr.arpa 영역과 같은 PTR을 만듭니다.

17                 IN PTR office.customer.com.
18                 IN PTR www.customer.com.
(etc)

이는 깔끔한 방법이며 PTR을 넣을 수있는 in-addr.arpa 영역이 있기 때문에 정통한 고객을 만족시킵니다. 역 DNS를 제어하고 싶지만 ' 전체 영역을 설정하지 않으려면 주 영역에서 유사한 이름으로 CNAME 개별 레코드 만 작성하면됩니다.

이 경우 위임자 인 23.16.172.rev 파일에 다음과 같은 내용이 있습니다.

16                 IN CNAME    16.customer.com.
17                 IN CNAME    17.customer.com.
18                 IN CNAME    18.customer.com.
19                 IN CNAME    19.customer.com.
20                 IN CNAME    20.customer.com.
21                 IN CNAME    21.customer.com.
22                 IN CNAME    22.customer.com.
23                 IN CNAME    23.customer.com.

따라서 다른 아이디어와 개념은 비슷하지만 새 영역을 만들어 고객에게 위임하는 대신 레코드를 고객의 기존 주 영역에있는 이름으로 CNAME합니다.

고객은 customer.com 영역 파일에 다음과 같은 내용이 있습니다.

office             IN A   172.16.23.17
17                 IN PTR office.customer.com.
www                IN A   172.16.23.18
18                 IN PTR www.customer.com.
(etc)

고객 유형에 따라 다릅니다. 내가 말했듯이, 그것은 단지 고객 유형에 달려 있습니다. 정통한 고객은 자신의 in-addr.arpa 영역을 설정하는 것을 선호하며 도메인 이름 영역에 PTR이있는 것이 매우 이상하다고 생각할 것입니다. 정통하지 않은 고객은 많은 추가 구성없이 "작동"을 원할 것입니다.

내가 익숙한 두 가지를 자세히 설명하는 다른 방법이있을 수 있습니다.

나는 / 22와 / 14가 쉬운 방법에 대한 진술과 그것이 왜 사실인지에 대해 생각하고 있었지만 25와 32 사이의 것은 어렵다. 나는 이것을 테스트하지 않았지만 다음과 같이 / 32 전체를 고객에게 위임 할 수 있다면 방황한다.

16                 IN NS ns1.customer.com.
17                 IN NS ns1.customer.com.
(etc)

그런 다음 고객 측에서 / 32 전체를 잡습니다.

zone "16.23.16.172.in-addr.arpa" { type master; file "masters/16.23.16.172.rev"; };
zone "17.23.16.172.in-addr.arpa" { type master; file "masters/17.23.16.172.rev"; };
(etc)

그리고 개별 파일에는 다음과 같은 것이 있습니다.

@            IN PTR office.customer.com.

명백한 단점은 / 32 당 하나의 파일이 거칠다는 것입니다. 그러나 나는 그것이 효과가있을 것이라고 내기했다.

내가 언급 한 모든 것은 순수한 DNS입니다 .DNS 서버에서 허용하지 않으면 DNS의 전체 기능을 제한하기 때문입니다. 내 예제는 분명히 BIND를 사용하지만 Windows DNS 및 BIND를 사용하여 고객 측을 수행했습니다. 서버에서 작동하지 않는 이유를 알 수 없습니다.

그렇습니다 . 아주 잘 읽은 RFC 2317 이 바로 그 길입니다.

또한 내 기사 (프랑스어).

BIND는 일련의 PTR 레코드를 생성하기위한 독점적 인 $ GENERATE 매크로를 가지고 있지만, 그것은 또한 세계를 가정하고 당신에게별로 유용하지 않을 것입니다. CIDR 리버스 존을 특별히 지원하는 다른 서버는 모르겠지만 수요가 있다고 생각합니다!

PowerDNS는 훌륭한 백엔드 인터페이스를 갖추고있어 문제가 충분히 큰 경우 직접 작성할 수 있습니다. "PipeBackend"를 사용하여 프로토 타입을 만들 수도 있습니다. MySQL / PostgreSQL 인터페이스를 통해 마법 같은 SQL 작업을 수행 할 수도 있습니다. 특히 Postgres에 "cidr"데이터 형식이 있기 때문입니다.

http://aa.net.uk/kb-domains-reversedns.html (약 절반 정도)은 ISP가 역방향 DNS를 수행하는 방법을 설명합니다. 나는 당신이 그것을하는 방법이 못생긴 것 같아요.