Ters DNS, sınıf sınırlarına güçlü bir şekilde bağlı görünüyor, CIDR'nin bir alt ağ için yetki verme yetkisi standart olduğu için şu anda hangi yöntemler var? Birden fazla yöntem varsa hangisi en iyisidir? DNS sunucusuna (Bind, djbdns, Microsoft DNS, diğer) bağlı olarak yetki vermeyi farklı bir şekilde mi ele almanız gerekiyor? Diyelim ki B sınıfı 168.192.in-addr.arpa olan bir ağın kontrolünü elimde tutuyorum:
Yanıtlar:
A / 22'yi seçmek kolaydır, 4 / 24'lerin temsilcisidir. A / 14, 4 / 16'ların, vb. Delegasyonudur.
RFC2317 , / 24'ten daha uzun bir ağ maskesine sahip özel durumları kapsar. Temelde, oktet sınırlarının dışında hiçbir yerde inaddr.arpa bölgelerinin delegasyonunu yapmanın süper temiz bir yolu yoktur, ancak bunun üzerinde çalışabilirsiniz. Diyelim ki 172.16.23.16 -> 172.16.23.23 IP adresleri olacak 172.16.23.16/29.
23.16.172.in-addr.arpa bölgesinin sahibi olarak, bu aralığı müşterime devretmek için 23.16.172.rev bölge dosyama koyabilirim:
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.
Böylece, yeni bir bölge tanımladığımı (16-29.23.16.172.in-addr.arpa.) Ve onu müşterimin isim sunucularına devrettiğimi görebilirsiniz. Sonra IP'lerden yeni atanan bölge altındaki ilgili numaraya atanacak CNAME'ler oluşturuyorum.
Bunların delege edildiği müşteri olarak, named.conf dosyasında aşağıdaki gibi bir şey yapardım:
zone "16-29.23.16.172.in-addr.arpa" {
type master;
file "masters/16-29.23.16.172.rev";
};
Ve sonra .rev dosyasında, PTR'leri normal in-addr.arpa bölgeleri gibi yapardım:
17 IN PTR office.customer.com.
18 IN PTR www.customer.com.
(etc)
Bu, bunu yapmanın en temiz yolu ve meraklı müşteriyi mutlu ediyor çünkü PTR'leri koymak için bir inadadr.arpa bölgesi var. Tersine DNS'i kontrol etmek isteyen ancak yapmak istemeyen müşteriler için yapmanın daha kısa bir yolu. Bütün bir bölgeyi ayarlamak istemeniz, sadece kendi bölgelerindeki benzer isimlerdeki bireysel kayıtları CNAME yapmaktır.
Bu durumda, temsilciler olarak, 23.16.172.rev dosyamızda böyle bir şey olurdu:
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.
Yani kavram olarak diğer fikre benziyor, ancak yeni bir bölge oluşturmak ve onu müşteriye devretmek yerine, kayıtları müşterinin zaten var olan ana bölgesinde isimlerle CNAMEing.
Müşterinin customer.com bölge dosyasında buna benzer bir şey olur:
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)
Bu sadece müşterinin türüne bağlıdır. Dediğim gibi, sadece müşteri türüne bağlı. Becerikli bir müşteri kendi inaddr.arpa bölgesini kurmayı tercih edecek ve etki alanı adı bölgesinde PTR'lerin bulunmasının çok garip olduğunu düşünecek. Konforlu olmayan bir müşteri, bir ton ekstra yapılandırma yapmak zorunda kalmadan “sadece çalışmasını” isteyecektir.
Muhtemelen diğer yöntemler var, sadece aşina olduğum ikisini ayrıntılandırıyorum.
Sadece / 22 ve / 14'ün nasıl kolay olduğu ve bunun neden doğru olduğu hakkında düşüncelerimi düşünüyordum ama 25 ile 32 arasındaki her şey zor. Bunu test etmedim, ancak tüm / 32’yi müşteriye bu şekilde devredebilirseniz dolaşırım:
16 IN NS ns1.customer.com.
17 IN NS ns1.customer.com.
(etc)
Ardından, müşteri tarafında, tüm / 32'yi yakalarsınız:
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)
Sonra bireysel dosyada şöyle bir şey olurdu:
@ IN PTR office.customer.com.
Açık olan dezavantajı, / 32 başına bir dosya tür brüt olmasıdır. Ama bahse girerim işe yarar.
Bahsettiğim her şey saf DNS, eğer herhangi bir DNS sunucusu yapmanıza izin vermediyse, bunun nedeni DNS'nin tüm işlevlerini kısıtlamasıdır. Örneklerim açıkça BIND kullanıyor, ancak bunun müşteri tarafını Windows DNS ve BIND kullanarak yaptık. Herhangi bir sunucuyla çalışmamasının bir sebebini görmüyorum.
Evet, RFC 2317 , çok iyi bir okuma, gitmenin yolu.
Ayrıca, benim yazı (Fransızca).
BIND, PTR kayıtlarının dizilerini oluşturmak için özel $ GENERATE makrosuna sahiptir, ancak aynı zamanda klas bir dünya olduğunu varsayar ve sizin için çok faydalı olmaz. CIDR ters bölgeleri için özel desteği olan başka sunucular bilmiyorum, ancak bunun için bir talep olduğundan şüpheliyim!
PowerDNS, problemin çabaya değecek kadar büyük olması durumunda, kendinize yazmanıza izin verecek hoş bir arka uç arayüzüne sahiptir. "PipeBackend" kullanarak prototip de oluşturabilirsiniz. MySQL / PostgreSQL arayüzleri üzerinden bazı sihirli SQL işlerini bile yapabilirsiniz - özellikle Postgres bir "cidr" veri tipine sahip olduğundan.
http://aa.net.uk/kb-domains-reversedns.html (yaklaşık yarıya kadar), ISS'min ters DNS'lerini nasıl yaptığını açıklar. Yaptığın her şekilde cehennem kadar çirkin olacağından şüpheleniyorum.