Đảo ngược DNS trong thế giới CIDR


24

Reverse DNS dường như được liên kết chặt chẽ với các ranh giới lớp, CIDR hiện đang là phương thức nào để ủy quyền cho một mạng con? Nếu nhiều phương thức tồn tại cái nào là tốt nhất? Bạn có cần xử lý ủy quyền khác nhau tùy thuộc vào máy chủ DNS (Bind, djbdns, Microsoft DNS, khác) không? Hãy nói rằng tôi có quyền kiểm soát mạng là Lớp B 168.192.in-addr.arpa vui lòng cung cấp các ví dụ cho:

  • Làm thế nào để ủy quyền cho a / 22?
  • Làm thế nào để ủy quyền cho a / 25?

Câu trả lời:


31

Việc ủy ​​nhiệm a / 22 thật dễ dàng, đó là sự ủy nhiệm của 4/24. A / 14 là phái đoàn của 4/16, v.v.

RFC2317 bao gồm các trường hợp đặc biệt với netmask dài hơn / 24. Về cơ bản, không có cách nào siêu sạch để thực hiện việc ủy ​​thác các vùng in-addr.arpa trên bất cứ thứ gì ngoại trừ ranh giới bát giác, nhưng bạn có thể giải quyết vấn đề này. Giả sử tôi muốn ủy quyền cho 172.16.23.16/29, đó sẽ là địa chỉ IP 172.16.23.16 -> 172.16.23.23.

Là chủ sở hữu của vùng 23.16.172.in-addr.arpa, tôi có thể sẽ đặt tệp này trong tệp vùng 23.16.172.rev của mình để ủy thác phạm vi này cho khách hàng của mình:

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.

Vì vậy, bạn có thể thấy rằng tôi đang xác định một khu vực mới (16-29.23.16.172.in-addr.arpa.) Và ủy thác nó cho các máy chủ tên của khách hàng của tôi. Sau đó, tôi đang tạo các CNAME từ các IP để được ủy quyền cho số tương ứng trong vùng mới được ủy quyền.

Là khách hàng mà những người này đã được ủy quyền, tôi sẽ làm một cái gì đó như sau trong tên.conf:

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

Và sau đó trong tệp .rev, tôi sẽ tạo các PTR giống như bất kỳ vùng in-addr.arpa bình thường nào:

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

Đó là một cách sạch sẽ để làm điều đó và nó làm cho khách hàng thông thái hài lòng vì họ có một khu vực in -addr.arpa để đặt PTR vào, v.v. Một cách ngắn hơn để làm điều đó cho khách hàng muốn kiểm soát DNS ngược nhưng không ' Tôi muốn thiết lập toàn bộ khu vực là chỉ ghi lại từng bản ghi CNAME cho các tên tương tự trong khu vực chính của chúng.

Trong trường hợp này, chúng tôi, với tư cách là đại biểu, sẽ có một cái gì đó như thế này trong tệp 23.16.172.rev của chúng tôi:

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.

Vì vậy, nó tương tự như ý tưởng với ý tưởng khác, nhưng thay vì tạo một khu vực mới và ủy thác nó cho khách hàng, bạn đang CNAME các bản ghi để đặt tên trong khu vực chính đã tồn tại của khách hàng.

Khách hàng sẽ có một cái gì đó như thế này trong tệp vùng khách hàng của họ:

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)

Nó chỉ phụ thuộc vào loại khách hàng. Như tôi đã nói, nó chỉ phụ thuộc vào loại khách hàng. Một khách hàng thông thái sẽ thích thiết lập vùng in-addr.arpa của riêng họ và sẽ nghĩ rằng thật kỳ quặc khi có PTR trong vùng tên miền. Một khách hàng không am hiểu sẽ muốn nó "chỉ hoạt động" mà không phải thực hiện thêm một tấn cấu hình.

Có thể có các phương pháp khác, chỉ chi tiết hai phương pháp tôi quen thuộc.


Tôi chỉ nghĩ về tuyên bố của mình về cách / 22 và / 14 là dễ dàng và nghĩ về lý do tại sao điều đó đúng nhưng mọi thứ từ 25 đến 32 đều khó. Tôi chưa thử nghiệm điều này, nhưng tôi đi lang thang nếu bạn có thể ủy thác toàn bộ / 32 cho khách hàng như thế này:

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

Sau đó, về phía khách hàng, bạn bắt toàn bộ / 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)

Và sau đó trong tệp cá nhân, bạn sẽ có một cái gì đó như thế này:

@            IN PTR office.customer.com.

Nhược điểm rõ ràng là một tệp trên / 32 là loại tổng. Nhưng tôi cá là nó sẽ hoạt động.

Tất cả những thứ tôi đã đề cập là DNS thuần túy, nếu bất kỳ máy chủ DNS nào không cho phép bạn làm điều đó bởi vì nó hạn chế toàn bộ chức năng của DNS. Các ví dụ của tôi rõ ràng là sử dụng BIND, nhưng chúng tôi đã thực hiện khía cạnh khách hàng này bằng Windows DNS và BIND. Tôi không thấy lý do nó không hoạt động với bất kỳ máy chủ nào.


1
Có lẽ bạn đang nghĩ về rfc2317 ( tools.ietf.org/html/rfc2317 )
Zoredache


0

BIND có macro $ GENERATE độc quyền để tạo chuỗi các bản ghi PTR, nhưng nó cũng giả sử một thế giới đầy đẳng cấp và sẽ không hữu ích cho bạn. Tôi không biết bất kỳ máy chủ nào khác có hỗ trợ đặc biệt cho các vùng đảo ngược CIDR, mặc dù tôi nghi ngờ rằng có nhu cầu về nó!

PowerDNS có giao diện phụ trợ đẹp mắt cho phép bạn tự viết nếu vấn đề đủ lớn để khiến nó xứng đáng với nỗ lực. Bạn cũng có thể tạo nguyên mẫu bằng cách sử dụng "TubeBackend". Bạn thậm chí có thể thực hiện một số công cụ SQL kỳ diệu thông qua giao diện MySQL / PostgreSQL - đặc biệt là vì Postgres có kiểu dữ liệu "cidr".


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.