BIND çalıştıran ve tek bir ağ geçidi üzerinden internete bağlı olan bir DNS sunucusuna sahip bir dahili ağım var. "Example.com" alan adım harici bir DNS sağlayıcısı tarafından yönetiliyor. Bu etki alanındaki "Host1.example.com" ve "Host2.example.com" gibi bazı girdilerin yanı sıra "example.com" üst düzey girdisi, ağ geçidinin genel IP adresini gösterir.
Dahili ağda bulunan ana bilgisayarların ağ geçidi yerine dahili IP adreslerine "Host1.example.com", "Host2.example.com" ve "example.com" sorunlarını çözmesini istiyorum. "Otherhost.example.com" gibi diğer ana bilgisayarlar yine de harici DNS sağlayıcısı tarafından çözülmelidir.
"Host1.example.com" ve "Host2.example.com" için BIND iki tek girişli bölge tanımlayarak, Host1 ve Host2 girişleri için bunu başardı. Ancak, "example.com" için bir bölge eklersem, bu etki alanına ilişkin tüm sorgular yerel DNS sunucum tarafından çözülür ve ör. "otherhost.example.com" sorgulanırsa hata oluşur.
BIND'ı bir etki alanının yalnızca bazı girdilerini geçersiz kılacak ve geri kalanını özyinelemeli olarak çözümleyecek şekilde yapılandırmak mümkün mü?
En iyi yöntem, Bind 9.8.1 veya daha yeni sürümdeki yanıt ilkesi bölgesidir. Rasgele bölgelerdeki tek kayıtları geçersiz kılmanıza izin verir (ve bunun için tam bir alt alan oluşturmanıza gerek yoktur, yalnızca değiştirmek istediğiniz tek kayıt), CNAME'leri, vb. Geçersiz kılmanıza olanak tanır. Unbound gibi diğer çözümler CNAME'leri geçersiz kılamaz .
https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html
DÜZENLEME: O zaman bunu düzgün yapalım. Yukarıda bağlantılı öğreticiye dayanarak yaptığım işlemleri belgeleyeceğim.
İşletim sistemim Raspberry Pi için Raspbian 4.4, ancak teknik Debian ve Ubuntu'da herhangi bir değişiklik olmadan veya diğer platformlarda minimum değişikliklerle çalışmalıdır.
Bind yapılandırma dosyalarınızın sisteminizde tutulduğu yere gidin - işte /etc/bind
. Orada aşağıdaki içeriğe sahip db.rpz
Adlı bir dosya oluşturun:
$TTL 60
@ IN SOA localhost. root.localhost. (
2015112501 ; serial
1h ; refresh
30m ; retry
1w ; expiry
30m) ; minimum
IN NS localhost.
localhost A 127.0.0.1
www.some-website.com A 127.0.0.1
www.other-website.com CNAME fake-hostname.com.
Bu ne işe yarıyor?
www.some-website.com
IP adresini sahte adresle 127.0.0.1
geçersiz kılar ve bu site için tüm trafiği geri döngü adresine gönderirwww.other-website.com
için fake-hostname.com
adlı başka bir siteye trafik gönderirBir Bind bölge dosyasına girebilecek her şeyi burada kullanabilirsiniz.
Bu değişiklikleri etkinleştirmek için birkaç adım daha var:
named.conf.local
Dosyasını düzenleyin ve bu bölümü ekleyin:
zone "rpz" {
type master;
file "/etc/bind/db.rpz";
};
Yukarıda bağlantılı öğretici, zone "rpz" { }
Ürününe daha fazla öğe eklemenizi söyler, ancak bu basit kurulumlarda gerekli değildir - burada gösterdiğim, yerel çözümleyicinizde çalışması için minimumdur.
named.conf.options
Öğesini düzenleyin ve options { }
Bölümünde bir yere response-policy
Seçeneğini ekleyin:
options {
// bunch
// of
// stuff
// please
// ignore
response-policy { zone "rpz"; };
}
Şimdi Bind'i yeniden başlatın:
service bind9 restart
Bu kadar. Ad sunucusu şimdi bu kayıtları geçersiz kılmaya başlamalıdır.
Değişiklik yapmanız gerekiyorsa, db.rpz
Dosyasını düzenleyin ve ardından Bind uygulamasını yeniden başlatın.
Bonus: DNS sorgularını syslog'a kaydetmek istiyorsanız, işlemlere göz kulak olabilir, named.conf.local
Düzenleyin ve bu ifadeleri içeren bir logging
bölümü olduğundan emin olun:
logging {
// stuff
// already
// there
channel my_syslog {
syslog daemon;
severity info;
};
category queries { my_syslog; };
};
Bind'ı yeniden başlatın ve hepsi bu.
Bind çalışan makinede test edin:
Dig @127.0.0.1 www.other-website.com. any
Dig'i farklı bir makinede çalıştırırsanız sadece @ 127.0.0.1 yerine @ the-ip-address-of-Bind sunucusunu kullanın
Bu tekniği, üzerinde çalıştığım bir web sitesi için CNAME'yi geçersiz kılmak için büyük bir başarıyla kullandım ve yeni test ettiğim yeni bir AWS yük dengeleyicisine gönderdim. Bind'i çalıştırmak için bir Raspberry Pi kullanıldı ve RPi de bir WiFi yönlendirici olarak çalışacak şekilde yapılandırıldı - bu yüzden RPi üzerinde çalışan SSID'ye aygıtlar bağlayarak test için gereken DNS geçersiz kılmalarını alırdım.
nbound özyinelemeli DNS sunucusu, tek tek kaynak kayıtlarını geçersiz kılabilir.
manuel , örn .: local-zone
Ve local-data
Yapılandırma ayarlarına bakın.
local-zone: "example.com." transparent
local-data: "foo.example.com. IN A 192.168.1.1"
local-zone
Ayarındaki transparent
ayarı, local-data
İle sağlanmayan adlar için normal özyinelemeli aramalar yapmasını söyler.
Tweaking çözünürlüğü ile bazı zekice şeyler yapmanıza izin veren "dnsmasq" içine bakmak isteyebilirsiniz.
Aradığınız şey Webopedia ile tanımlanan bölünmüş DNS'dir:
Bölünmüş bir DNS altyapısında, aynı etki alanı için biri iç ağ tarafından kullanılacak, diğeri dış ağ tarafından kullanılan iki bölge oluşturursunuz. Bölünmüş DNS, ad ana bilgisayarları için ad çözümlemesi için bir iç etki alanı adı sunucusuna, dış ana bilgisayarlar ise ad çözümlemesi için bir dış etki alanı adı sunucusuna yönlendirilir.
Temel olarak, harici bölge dosyanızın bir kopyasını oluşturup dahili DNS sunucunuza kopyalamanız, ardından özellikle dahili ağınız için gereken kayıtları değiştirmeniz veya eklemeniz gerekir. Bu oldukça yaygın bir kurulumdur, ancak "harici" kayıtları iki DNS sunucusu arasında senkronize tutmak acı verici olabilir. Genel sunucuda bir kayıt oluşturursanız veya değiştirirseniz, özel sunucuda da oluşturulması veya değiştirilmesi gerekir.
Bu, hangi DNS sunucusu uygulamasını kullandığınızdan bağımsız olarak uygulanabilir. Çoğu kurulumda, harici ağa hizmet veren bir DNS sunucunuz ve dahili ağa hizmet veren başka bir DNS sunucunuz olacaktır. BIND ile, muhtemelen diğer uygulamalar gibi, adlandırılmış.conf dosyasının bölge bölümündeki "allow-query" deyimini kullanarak aynı sunucuda bölgenin her iki sürümüne de sahip olabilirsiniz.
BIND üzerinde başka bir olasılık (ve bunu hiç denemedim), dahili DNS sunucusunda example.com etki alanınızı yalnızca dahili olarak kullandığınız kayıtlarla ayarlamak olacaktır. Ardından, "ilk" bağımsız değişkeni ile bir "ileri" ifadesi ayarlayın ("ileticiler" ile birlikte). Teorik olarak, bu, dış DNS sunucusundan ("ileticiler" de ayarlandığı gibi, dahili kayıtlarınıza sahip olmayacak ve bir hata yanıtı döndürecek bir yanıt isteyecektir. Daha sonra, dahili sunucu bir cevap için kendisine bakacaktır. emin olabilirsiniz, ama bu bir düşünce.
BIND'de istenen ana bilgisayar adını kullanarak bir bölge tanımlayarak bu sonuçlara ulaşıyorum. Sadece birkaç ana bilgisayar geçersiz kılmak istiyorsanız, yaklaşım gayet iyi.
Benim bölge beyanım şöyle:
zone "override.example.com" {
type master;
notify no;
file "zone-config/override.example.com";
};
Bölge tanımım şöyle:
$TTL 4H
@ IN SOA ns.override.example.com. root.override.example.com. (
2009072215 ; Serial
3600 ; Refresh
600 ; Retry
604800 ; Expire
3600 ) ; Minimum
;
NS ns
IN NS ns.override.example.com.
IN A 192.168.1.100
ns IN A 192.168.1.100
Öyleyse intranet DNS ve ISS DNS'de example.com'u sorgularsam aynı IP'yi alırım ancak override.example.com'u sorgularsam intranet DNS (birincil) erişilebilir durumdaysa farklı sonuçlar elde ederim.
Dnsmasq kullanımı bunu kolaylaştırır. http://www.thekelleys.org.uk/dnsmasq/doc.html dns sunucusu gibi davranır ancak yerel dns sunucusundan yanıtlar alır. Bölge dosyaları ile uğraşmadan tek etki alanı kayıtlarını geçersiz kılabilmeniz iyi bir şey
Aslında bunu yapmak için belki biraz farklı olsa bile başka bir yol var. Aynı duruma sahibim, harici ve dahili olarak kullanılan bir alanım var ve harici statik ve dinamik ana bilgisayarlarım var. Gerçekten acı veren tek şey dış dinamik olanlar. Çözüm muhtemelen en zarif değil, küçük bir komut dosyasıyla uygulanabilir. Çoğunlukla dinamik DNS sağlayıcımın API'sı ile kendi dinamik DNS komut dosyamı yapıyorum, bu komut dosyasını cron tarafından her 5 dakikada bir çalıştırıyorum:
1) harici IP adresimi al. değişti mi Çıkış yok.
2) değiştirilmiş IP, dyndns sağlayıcısının arama API'sı, yeni IP adresi ile,
3) Harici IP ile db.alanadim.com'u kullanın
4) bağlama yeniden başlatın.
Ev ağım için çok güvenilir bir şekilde çalışıyor
Zaten doğru yoldasınız.
Dahili DNS sunucularınızda, "example.com" un hemen altındaki her istisna Ana Bilgisayar için bir bölge tanımlamanız gerekir. Bu istisnaları en aza indirmek için, tüm dahili makinelere "hosta.internal.example.com" adını vermek yaygın bir uygulamadır, DNS sunucusu çoğu sorguyu harici DNS sunucularına gönderir, ancak "internal.example.com" bölgesi için yetkilidir. (Küçük bir işlemi geçtikten sonra, genellikle istemcilerin yönlendirildiği birkaç DNS sunucusu ve bu sunucuların "internal.example.com" için yönlendirildiği ayrı bir yetkili DNS vardır.)
Genellikle, yalnızca bir Ana Bilgisayara hem harici hem de dahili olarak erişilebilir olması gerektiğinde, tanımladığınız istisnalar oluşturulur. O zaman bile dışarıdan "Host1.example.com" ve içeriden "Host1.internal.example.com" kullanmak isteyebilirsiniz. Dahili ana makineler, "internal.example.com" içindeki adları arayacak şekilde yapılandırılır. Bir sunucunun sertifikasının sunucuyu "Host1.example.com" olarak tanımlaması gibi zaten yaptıklarınızın uygun olduğu durumlar vardır; bu durumda istemcilerin bağlandığı ad olmasını istersiniz.