Myslím, že říjen celkově bude měsíc oprav a ne jenom regenerace. Po všech stránkách. Občas totiž dojde k situacím, které jsou tak silné, že se zapíší do DNA. No ale co když bude naopak situace tak slabá, že se nezapíše ani do DNS? Včera se díky průběžnému času a relativnímu klidu konečně povedlo opravit jeden z nejvíce palčivých problémů, který by v uplynulých letech své řešení nenašel.
Celkově při návrhu infrastruktury prosazuji, že síť by měla mít jeden velmi výkonný DNS server a dílčí úlohy, kterými je konkrétně myšlena správa AD forestu a lokální domény, by měly obstarávat servery nižší úrovně. Až donedávna myšlenka fungovala velmi dobře, tedy na síti byl jeden hlavní BIND9, který fungoval jako slave pro transfery z řadičů, které byly mastery pro Samba 4 doménu ve smysl DLZ pro samostatné BIND9. To umožnilo hodně odlehčit řadičům vyhodnocování a samy mohly jen forwardovat dotazy nahoru.
Až do do včil, když to přestalo jednoduše fungovat. Po zdlouhavé analýze všeho možného a nudném čtení mám nakonec za to, že se Samba v nějaké verzi rozhodla, že povolení transferu hlavní zóny kamkoliv je bezpečnostní riziko a že to jednoduše zakáže. Vtipné na tom je, že pomocí RSAT nelze přes GUI transfer povolit. A stejně jsem na síti už neměl Windows, natož Windows s RSAT. Tak co s tím?
Práce s DLZ databází je obecně podobná zónovým záznamům v souborech, pro databázi řízenou Sambou si BIND bere konfiguraci typicky z /var/lib/samba/bind-dns/named.conf. Tam je prakticky jen direktiva pro binární ovladač databáze, v tomto okamžiku pro BIND 9.18. Aby bylo možné zónu redefinovat, je nutné ještě přidat search no;, což serveru sdělí, že nebude provádět hledání v databázi, pokud nenajde výsledek v aktuální zóně.
# /var/lib/samba/bind-dns/named.conf:
dlz "samba" {
# BIND 9.18
database "dlopen /usr/lib/aarch64-linux-gnu/samba/bind9/dlz_bind9_18.so";
search no;
}; Pak už tedy stačí danou zónu (resp. všechny AD zóny, co chceme přenášet) jen dodefinovat v hlavní konfiguraci, resp. ideálně v nějakém souboru, co se připojí do hlavní konfigurace. Například následující konfigurace obsahuje hlavní doménu domena.lan a k ní ještě přidružené reverzní záznamy v IPv4 a IPv6, pokud se s nimi pracuje.
zone "domena.lan" {
type master;
dlz "samba";
allow-transfer { "dns-ad"; };
};
zone "_msdcs.domena.lan" {
type master;
dlz "samba";
allow-transfer { "dns-ad"; };
};
zone "1.0.10.in-addr.arpa" {
type master;
dlz "samba";
allow-transfer { "dns-ad"; };
};
zone "c.0.0.0.b.0.0.0.a.0.0.0.e.f.a.c.ip6.arpa" {
type master;
dlz "samba";
allow-transfer { "dns-ad"; };
};
Nutno doplnit, že ACL název dns-ad by měl obsahovat adresy hlavního DNS serveru, který bude pro dané zóny fungovat jako slave – jeho konfigurace bude obsahovat záznamy pro zmíněné zóny nějak takto:
zone "domena.lan" {
type slave;
masters { "dc1"; "dc2"; };
file "/etc/bind/dynamic/domena.lan";
allow-query { "acl-lan"; };
inline-signing yes;
key-directory "/etc/bind/keys";
};
zone "_msdcs.domena.lan" {
type slave;
masters { "dc1"; "dc2"; };
file "/etc/bind/dynamic/_msdcs.domena.lan";
allow-query { "acl-lan"; };
inline-signing yes;
key-directory "/etc/bind/keys";
};
zone "1.0.10.in-addr.arpa" {
type slave;
masters { "dc1"; "dc2"; };
file "/etc/bind/dynamic/1.0.10.in-addr.arpa";
allow-query { "acl-lan"; };
inline-signing yes;
key-directory "/etc/bind/keys";
};
zone "c.0.0.0.b.0.0.0.a.0.0.0.e.f.a.c.ip6.arpa" {
type slave;
masters { "dc1"; "dc2"; };
file "/etc/bind/dynamic/c.0.0.0.b.0.0.0.a.0.0.0.e.f.a.c.ip6.arpa";
allow-query { "acl-lan"; };
inline-signing yes;
key-directory "/etc/bind/keys";
};
No a tím by to mělo být ku spokojenosti zatím vyřešené. Uvidíme, s čím přijde Samba a BIND příště, dost možná pak bude potřeba nastražit jiné technologie. Například teď to, že Google blokuje Hurricane, si vyžaduje taktiku resolvovat služby Googlu pouze po IPv4, ale snadno a magicky to zatím není možné. Ale i to přijde.