Membalikkan DNS di dunia CIDR


24

Reverse DNS tampaknya sangat terkait dengan batasan kelas, metode apa yang ada sekarang bahwa CIDR adalah standar untuk mendelegasikan wewenang untuk subnet? Jika ada banyak metode, mana yang terbaik? Apakah Anda perlu menangani delegasi secara berbeda tergantung pada server DNS (Bind, djbdns, Microsoft DNS, lainnya)? Katakanlah saya memiliki kendali atas jaringan yang merupakan Kelas B 168.192.in-addr.arpa berikan contoh untuk:

  • Bagaimana mendelegasikan wewenang untuk / 22?
  • Bagaimana mendelegasikan wewenang untuk / 25?

Jawaban:


31

Mendelegasikan a / 22 itu mudah, itu adalah delegasi dari 4/24. A / 14 adalah delegasi dari 4 / 16s, dll.

RFC2317 mencakup kasus khusus dengan netmask lebih panjang dari / 24. Pada dasarnya tidak ada cara super bersih untuk melakukan pendelegasian zona in-addr.arpa pada apa pun kecuali batas oktet, tetapi Anda dapat mengatasi ini. Katakanlah saya ingin mendelegasikan 172.16.23.16/29, yang akan menjadi alamat IP 172.16.23.16 -> 172.16.23.23.

Sebagai pemilik zona 23.16.172.in-addr.arpa, saya mungkin akan memasukkan ini ke file zona 23.16.172.rev saya untuk mendelegasikan rentang ini ke pelanggan saya:

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.

Jadi, Anda dapat melihat bahwa saya menetapkan zona baru (16-29.23.16.172.in-addr.arpa.) Dan mendelegasikannya ke server nama pelanggan saya. Lalu saya membuat CNAME dari IP untuk didelegasikan ke nomor yang sesuai di bawah zona yang baru didelegasikan.

Sebagai pelanggan yang telah didelegasikan ini, saya akan melakukan sesuatu seperti yang berikut ini di named.conf:

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

Dan kemudian dalam file .rev, saya hanya akan membuat PTR seperti zona in-addr.arpa normal:

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

Itu semacam cara bersih untuk melakukannya dan itu membuat pelanggan yang cerdas senang karena mereka memiliki zona in-addr.arpa untuk memasukkan PTR, dll. Cara yang lebih singkat untuk melakukannya bagi pelanggan yang ingin mengontrol DNS balik tetapi tidak Saya tidak ingin mengatur seluruh zona hanya untuk CNAME record individual ke nama yang serupa di zona utama mereka.

Dalam hal ini, kami, sebagai delegator, akan memiliki sesuatu seperti ini di file 23.16.172.rev kami:

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.

Jadi, konsepnya mirip dengan gagasan lain, tetapi alih-alih membuat zona baru dan mendelegasikannya kepada pelanggan, Anda CNAMEing catatan ke nama-nama di zona utama pelanggan yang sudah ada.

Pelanggan akan memiliki sesuatu seperti ini di file zona customer.com mereka:

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)

Itu hanya tergantung pada jenis pelanggan. Seperti yang saya katakan, itu tergantung pada jenis pelanggan. Pelanggan yang cerdas akan lebih suka mengatur zona in-addr.arpa mereka sendiri dan akan merasa sangat aneh memiliki PTR di zona nama domain. Pelanggan yang tidak mengerti akan menginginkannya untuk "hanya bekerja" tanpa harus melakukan banyak konfigurasi tambahan.

Kemungkinan ada metode lain, hanya merinci dua yang saya kenal.


Saya hanya memikirkan pernyataan saya tentang bagaimana / 22 dan / 14 itu mudah dan memikirkan mengapa itu benar tetapi apa pun antara 25 dan 32 sulit. Saya belum menguji ini, tapi saya berkeliaran jika Anda bisa mendelegasikan seluruh / 32 ke pelanggan seperti ini:

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

Kemudian, di sisi pelanggan, Anda menangkap seluruh / 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)

Dan kemudian dalam file individual Anda akan memiliki sesuatu seperti ini:

@            IN PTR office.customer.com.

Kelemahan yang jelas adalah bahwa satu file per / 32 adalah jenis kotor. Tapi saya yakin itu akan berhasil.

Semua hal yang saya sebutkan adalah DNS murni, jika ada server DNS tidak membiarkan Anda melakukannya itu karena itu membatasi fungsionalitas penuh DNS. Contoh saya jelas menggunakan BIND, tetapi kami telah melakukan sisi pelanggan menggunakan Windows DNS dan BIND. Saya tidak melihat alasan itu tidak akan berfungsi dengan server mana pun.


1
Anda mungkin berpikir tentang rfc2317 ( tools.ietf.org/html/rfc2317 )
Zoredache


0

BIND memiliki makro $ GENERATE hak milik untuk membuat urutan catatan PTR, tetapi juga mengasumsikan dunia yang berkelas dan tidak akan sangat berguna bagi Anda. Saya tidak tahu ada server lain yang memiliki dukungan khusus untuk zona terbalik CIDR, meskipun saya curiga ada permintaan untuk itu!

PowerDNS memiliki antarmuka backend yang bagus yang memungkinkan Anda menulis sendiri jika masalahnya cukup besar untuk membuatnya sepadan dengan usaha. Anda juga dapat membuat prototipe menggunakan "PipeBackend". Anda bahkan dapat melakukan beberapa hal SQL ajaib melalui antarmuka MySQL / PostgreSQL - terutama karena Postgres memiliki tipe data "cidr".


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.