🚀 go-pugleaf

On 2014-02-25, Andrzej W. <awa_wp.a_to_wytnij> wrote:
> Witam,
>
> Czy istnieje jakiś prosty i logiczny sposób by replikować binda9 z
> wieloma widokami na slavea posiadającego tylko jeden adres IP?
> Najlepiej jak by master też miał tylko jedno IP?

Możesz próbować na różnych portach. Nie wiem tylko czy nie będzie ci
potrzebna druga instancja BIND-a, bo ACL-ki mogą nie umieć rozróżniać
portów.

-- 
Secunia non olet.
Stanislaw Klekot

W dniu 2014-02-25 23:43, Stachu 'Dozzie' K. pisze:
> On 2014-02-25, Andrzej W. <awa_wp.a_to_wytnij> wrote:
>> Witam,
>>
>> Czy istnieje jakiś prosty i logiczny sposób by replikować binda9 z
>> wieloma widokami na slavea posiadającego tylko jeden adres IP?
>> Najlepiej jak by master też miał tylko jedno IP?
>
> Możesz próbować na różnych portach. Nie wiem tylko czy nie będzie ci
> potrzebna druga instancja BIND-a, bo ACL-ki mogą nie umieć rozróżniać
> portów.
>

ACLki nie rozróżniają portów. Widoki podobno wymyślili by nie stawiać 
wielu instancji BINDa i jak mam wiele instancji to widoki niepotrzebne.
Ale znowu instancje muszą być przypięte do oddzielnych IP a konfiguracja 
z widokami może pracować na jednym....
Brak definicji portu w ACLach i możliwości zdefiniowania operatora 
logicznego między ACLami czyni widoki nieprzydatne jeśli chcemy mieć 
serwer z replikacją.
Albo czegoś nie zauważyłem w dokumentacji.

-- 
AWa

Andrzej W. wrote:
> Ale znowu instancje muszą być przypięte do oddzielnych IP a konfiguracja 
> z widokami może pracować na jednym....

Skąd taki wniosek? Mam konfigurację Bind-a, gdzie serwer słucha na wielu
adresach (3? lub więcej).

Dnia 26.02.2014 ein <ein@no.spam> napisał/a:
> Andrzej W. wrote:
>> Ale znowu instancje muszą być przypięte do oddzielnych IP a konfiguracja 
>> z widokami może pracować na jednym....
>
> Skąd taki wniosek? Mam konfigurację Bind-a, gdzie serwer słucha na wielu
> adresach (3? lub więcej).

Osobne instancje MUSZA byc na oddzielnych parach ip/port.
Z widokami MOZE pracowac na jednym.

Dobrze napisal :)

Andrzej W. <awa_wp.a_to_wytnij.@wp.pl> wrote:
> Witam,
> 
> Czy istnieje jakiś prosty i logiczny sposób by replikować binda9 z
> wieloma widokami na slavea posiadającego tylko jeden adres IP?
> Najlepiej jak by master też miał tylko jedno IP?
 
Jest to możliwe do zrealizowania z użyciem mechanizmu TSIG. Do każdego
widoku dodajesz dyrektywę server z opcją keys zawierająca odpowiedni
klucz.

Lukasz Olesiejuk wrote:
> Dnia 26.02.2014 ein <ein@no.spam> napisał/a:
>> Andrzej W. wrote:
>>> Ale znowu instancje muszą być przypięte do oddzielnych IP a konfiguracja 
>>> z widokami może pracować na jednym....
>>
>> Skąd taki wniosek? Mam konfigurację Bind-a, gdzie serwer słucha na wielu
>> adresach (3? lub więcej).
> 
> Osobne instancje MUSZA byc na oddzielnych parach ip/port.
> Z widokami MOZE pracowac na jednym.
> 
> Dobrze napisal :)

Ta, teraz zrozumiałem o co autorowi chodzi, przepraszam za zamieszanie.

W dniu 2014-02-26 18:15, aaa@h1.pl pisze:
> Andrzej W. <awa_wp.a_to_wytnij.@wp.pl> wrote:
>> Witam,
>>
>> Czy istnieje jakiś prosty i logiczny sposób by replikować binda9 z
>> wieloma widokami na slavea posiadającego tylko jeden adres IP?
>> Najlepiej jak by master też miał tylko jedno IP?
>
> Jest to możliwe do zrealizowania z użyciem mechanizmu TSIG. Do każdego
> widoku dodajesz dyrektywę server z opcją keys zawierająca odpowiedni
> klucz.
>

Też tak myślałem, ale nie wymyśliłem.
Zrealizowałeś to, czy Ci się tylko tak wydaje?
Jakiś przykład jak to master ma zaprezentować odpowiedni widok slavowi w 
zależności od tego jakim to kluczem on się przedstawi?

-- 
AWa.

Andrzej W. <awa_wp.a_to_wytnij.@wp.pl> wrote:
> W dniu 2014-02-26 18:15, aaa@h1.pl pisze:
>> Jest to możliwe do zrealizowania z użyciem mechanizmu TSIG. Do każdego
>> widoku dodajesz dyrektywę server z opcją keys zawierająca odpowiedni
>> klucz.
>>
> 
> Też tak myślałem, ale nie wymyśliłem.
> Zrealizowałeś to, czy Ci się tylko tak wydaje?
> Jakiś przykład jak to master ma zaprezentować odpowiedni widok slavowi w 
> zależności od tego jakim to kluczem on się przedstawi?
 
Zrealizowałem trochę inną konfigurację, obydwa serwery DNS mają po dwa
adresy IP ale transfery wszystkich widoków odbywają się przez sieć lokalną.

Tak mniej więcej to wygląda:

slave 192.168.1.100 
master 192.168.1.200

Ciekwe i nieoczywiste jest to, że "match clients" musi zawierać
dyrektywę !key external; Bez tego wpisu nie działa u mnie transfer
widoku external. W przypadku z pojedynczym adresem IP zapewne nie będzie
potrzebna dyrektywa also-notify.

konfiguracja wspólna:

acl internals {
	127.0.0.0/8;
	192.168.1.0/24;
};

key "internal" {
	algorithm hmac-md5;
	secret "..."
};

key "external" {
    algorithm hmac-md5;
	secret "..."
};

master:

view "internal" {
	match-clients { !key external; internals; };
	server 192.168.1.100 { keys internal; };
	recursion yes;

	also-notify { 192.168.1.100; };

	zone "example.org" {
		type master;
		file "example.org.internal";
		notify yes;
		allow-transfer { key internal; };
	};
};

view "external" {
	match-clients { key external; any; };
	server 192.168.1.100 { keys external; };
	recursion no;

	also-notify { 192.168.1.100; };

	zone "example.org" {
		type master;
		file "example.org.external";
		notify yes;
		allow-transfer { key external; };
	};
};

slave:

view "internal" {
	match-clients { !key external; internals; };
	server 192.168.1.200 { keys internal; };
	recursion yes;

	zone "example.org" {
		type slave;
		file "example.org.internal";
		masters { 192.168.1.200; };
		allow-notify { key internal; };
	};
};

view "external" {
	match-clients { key external; any; };
	server 192.168.1.200 { keys external; };
	recursion no;

	zone "example.org" {
		type slave;
		file "example.org.external";
		masters { 192.168.1.200; };
		allow-notify { key external; };
	};
};

Dzięki, wygląda na to, że powinno to działać.
To, że bez "!key external" w "match clients" nie działa jak należy to 
akurat naturalne. Master przedstawia pierwszy pasujący widok, a bez tego 
pasuje zawsze widok internal bo Slave ma ip z acl internals.
Jak się w tym w ogóle łapiesz, internals, internal, internal, external, 
external, te same nazwy na zupełnie różne rzeczy?


W dniu 2014-02-28 09:33, aaa@h1.pl pisze:
> Andrzej W. <awa_wp.a_to_wytnij.@wp.pl> wrote:
>> W dniu 2014-02-26 18:15, aaa@h1.pl pisze:
>>> Jest to możliwe do zrealizowania z użyciem mechanizmu TSIG. Do każdego
>>> widoku dodajesz dyrektywę server z opcją keys zawierająca odpowiedni
>>> klucz.
>>>
>>
>> Też tak myślałem, ale nie wymyśliłem.
>> Zrealizowałeś to, czy Ci się tylko tak wydaje?
>> Jakiś przykład jak to master ma zaprezentować odpowiedni widok slavowi w
>> zależności od tego jakim to kluczem on się przedstawi?
>
> Zrealizowałem trochę inną konfigurację, obydwa serwery DNS mają po dwa
> adresy IP ale transfery wszystkich widoków odbywają się przez sieć lokalną.
>
> Tak mniej więcej to wygląda:
>
> slave 192.168.1.100
> master 192.168.1.200
>
> Ciekwe i nieoczywiste jest to, że "match clients" musi zawierać
> dyrektywę !key external; Bez tego wpisu nie działa u mnie transfer
> widoku external. W przypadku z pojedynczym adresem IP zapewne nie będzie
> potrzebna dyrektywa also-notify.
>
> konfiguracja wspólna:
>
> acl internals {
> 	127.0.0.0/8;
> 	192.168.1.0/24;
> };
>
> key "internal" {
> 	algorithm hmac-md5;
> 	secret "..."
> };
>
> key "external" {
>      algorithm hmac-md5;
> 	secret "..."
> };
>
> master:
>
> view "internal" {
> 	match-clients { !key external; internals; };
> 	server 192.168.1.100 { keys internal; };
> 	recursion yes;
>
> 	also-notify { 192.168.1.100; };
>
> 	zone "example.org" {
> 		type master;
> 		file "example.org.internal";
> 		notify yes;
> 		allow-transfer { key internal; };
> 	};
> };
>
> view "external" {
> 	match-clients { key external; any; };
> 	server 192.168.1.100 { keys external; };
> 	recursion no;
>
> 	also-notify { 192.168.1.100; };
>
> 	zone "example.org" {
> 		type master;
> 		file "example.org.external";
> 		notify yes;
> 		allow-transfer { key external; };
> 	};
> };
>
> slave:
>
> view "internal" {
> 	match-clients { !key external; internals; };
> 	server 192.168.1.200 { keys internal; };
> 	recursion yes;
>
> 	zone "example.org" {
> 		type slave;
> 		file "example.org.internal";
> 		masters { 192.168.1.200; };
> 		allow-notify { key internal; };
> 	};
> };
>
> view "external" {
> 	match-clients { key external; any; };
> 	server 192.168.1.200 { keys external; };
> 	recursion no;
>
> 	zone "example.org" {
> 		type slave;
> 		file "example.org.external";
> 		masters { 192.168.1.200; };
> 		allow-notify { key external; };
> 	};
> };
>

Andrzej W. <awa_wp.a_to_wytnij.@wp.pl> wrote:
> Dzięki, wygląda na to, że powinno to działać.
> To, że bez "!key external" w "match clients" nie działa jak należy to 
> akurat naturalne. Master przedstawia pierwszy pasujący widok, a bez tego 
> pasuje zawsze widok internal bo Slave ma ip z acl internals.

Tak podejrzewałem.

> Jak się w tym w ogóle łapiesz, internals, internal, internal, external, 
> external, te same nazwy na zupełnie różne rzeczy?

Konfiguracja nie jest bardzo skomplikowana więc jakoś to ogarniam, ale
masz rację, muszę trochę to uporządkować.

pozdrawiam