widoki bind 9

[LFC]

Co złego jest w poniższym konfie nameda, że nie działa jak trzeba z
bindem 9.x.
Dokładnie to widok external działa dla wszystkich klas adresowych,
natomiast "internal" - nie, a chciałem, żeby na zapytanie o hosty z
sieci wewnętrznej odpowiadał adresami nierutowalnymi
Strefy internal są identycznie skonstruowane, jak external, tyle, że
zawierają adresy niepubliczne.
Bardzo podobny układ działał mi dobrze w bindzie 8,
Przy starcie bind nie meluduje o błędnach w plikach stref.
jest tylko informacja o disablowaniu pustych plików stref
127.in-addr.arpa, 254.169.in-addr.arpa, 2.0.192.in-addr.arpa i kilku
innych, jak mniemam ładowanych przez realizacje polecenia include, nie
ma natomiast żadnych informacji o błędach w plikach stref, czy widoku.
IPV6 mam zdisablowane.
W firmie sa dwie sieci wewn. 192.168.0.0 i 192.168.2.0
Widok internal, jakby nie działał, ponieważ nslookup na zapytanie z
sieci 192.168.0.0 o serwer www (niepubliczne IP) odpowiada błędem,
natomiast dla zapytań z sieci 192.168.2.0 widać odmowę dostępu dla
widoku "external"

options {

listen-on port 53 { any; };

# listen-on-v6 port 53 { ::1; };

directory "/var/named";

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

memstatistics-file "/var/named/data/named_mem_stats.txt";

# allow-query { any; };

# recursion yes;

auth-nxdomain yes;

dnssec-enable yes;

dnssec-validation yes;

dnssec-lookaside auto;



/* Path to ISC DLV key */

bindkeys-file "/etc/named.iscdlv.key";



managed-keys-directory "/var/named/dynamic";

# match-clients { any;};

# allow-query { any; };

};



logging {

channel default_debug {

file "data/named.run";

severity dynamic;

};

};



view "external" {

match-clients { any; };





zone "." IN {

type hint;

file "named.ca";

};



zone "domena.com.pl" IN {

type master;

file "domena.com.pl";

allow-query { any; };

allow-transfer { 194.150.251.2; 193.16.255.2; };

forwarders { 194.150.251.2; 193.16.255.2; };

notify yes;

};



zone "251.150.194.in-addr.arpa" IN {

type master;

file "251.150.194.zone";

allow-query { any; };

allow-transfer { 194.150.251.2; 193.16.255.2; };

forwarders { 194.150.251.2; 193.16.255.2; };

notify yes;

};

include "/etc/named.rfc1912.zones";

include "/etc/named.root.key";

};



view "internal" {

match-clients { 192.168.0.0/24; 192.168.2.0/24; 127.0.0.0/8; };

allow-query { 192.168.0.0/24; 192.168.2.0/24; 127.0.0.0/8; };

allow-transfer { none;};

allow-recursion { 192.168.0.0/24; 192.168.2.0/24; 127.0.0.0/8; };

recursion yes;



zone "." IN {#

type hint;

file "named.ca";

};



zone "domena.com.pl" IN {

type master;

file "mpwikzdw.com.pl.int";

notify no;

};



zone "0.168.192.in-addr.arpa" IN {

type master;

file "0.168.192.zone";

notify no;

};

include "/etc/named.rfc1912.zones";

include "/etc/named.root.key";

};

[karol]

W dniu 27.03.2017 o 07:51, LFC pisze:

> Co złego jest w poniższym konfie nameda, że nie działa jak trzeba z
> bindem 9.x.

Mam ideowo to samo, na bind9.

Mam inną kolejność widoków.

1) widok wewnętrzny
2) widok "all"


U Ciebie jest na odwrót i chyba to powodowało u mnie też jakieś problemy
jak to budowałem.

Dodatkowo ACLki mam globalnie Ty masz per widok.

To jedyne różnice jakie widze.

karol

[LFC]

W dniu 27.03.2017 o 09:01, karol pisze:

W bindzie 8 miałem faktycznie najpierw widok INTERNAL, ale, czy to
byłby powód?
Tobie działają oba widoki?
I jeszcze jedna różnica - strefy dla localhosta w starszym miałem
zdefiniowane ręcznie, tu sa ładowane "odgórnie" przez include.
Rodzi się następne pytanie, co będzie jak wywalimy include i załadujemy
strefy localhosta tradycyjnie?

LFC

[karol]

W dniu 27.03.2017 o 09:44, LFC pisze:
> W dniu 27.03.2017 o 09:01, karol pisze:

> Tobie działają oba widoki?

Tak działają dwa widoki w zależności od tego z jakiego adresu IP pytają.
Wszystkie strefy mam na include
named.conf:
=======
acl internals { 127.0.0.0/8; 192.168.1.0/24; 192.168.20.0/24; };
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

named.conf.default-zone
==========
view "wifi" {

match-clients { 192.168.20.0/24; };

zone "domena.local" IN {
type master;
file "/etc/bind/domena_wifi.local.db";
};

};


view "all" {

zone "." {
type hint;
file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};

zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/rev.0.168.192.in-addr.arpa";
};

zone "domena.local" IN {
type master;
file "/etc/bind/domena.local.db";
};

#include "/etc/bind/spywaredomains.zones";

};


Zmień kolejność widoków
U Mnie bind9 1:9.9.5.dfsg-3ubuntu0.13 .

[LFC]

W dniu 27.03.2017 o 09:01, karol pisze:

Chyba, że jest tak, jak z regułami iptables - kolejność jest ważna,
czyli sprawdza widok pierwszy na liście jeżeli pasują kryteria to
odpowiada. Jeżeli nie, to sprawdza drugi widok.
To by częsciowo usprawiedliwiało zachowanie binda, ale nie wyjaśnia
odmów dla sieci 192.168.2.0, bo teoretycznie w obu widokach powinien jej
odpowiedzieć. W bindzie 8 nie było z tym żadnych problemów

LFC

[karol]

W dniu 27.03.2017 o 10:37, LFC pisze:
> W dniu 27.03.2017 o 09:01, karol pisze:

>
> Chyba, że jest tak, jak z regułami iptables - kolejność jest ważna,
> czyli sprawdza widok pierwszy na liście jeżeli pasują kryteria to
> odpowiada. Jeżeli nie, to sprawdza drugi widok.
> To by częsciowo usprawiedliwiało zachowanie binda, ale nie wyjaśnia
> odmów dla sieci 192.168.2.0, bo teoretycznie w obu widokach powinien jej
> odpowiedzieć. W bindzie 8 nie było z tym żadnych problemów
>

Ustaw ACL na starcie konfiguracji
karol

[LFC]

W dniu 27.03.2017 o 10:43, karol pisze:

>
>
> Ustaw ACL na starcie konfiguracji
> karol
>

Nie potrzeba. Przestawiłem kolejność widoków i jest DOBRZE.
Wygląda na to, że tu jest tak z jak z regułami iptables - jak napotka
pierwszą regułę która odpowiada kryteriom to realizuje i nie sprawdza
następnych w kolejce.

Dzięki za odzew, bo to mnie naprowadziło na właściwą koncepcję.

LFC

[LFC]

W dniu 27.03.2017 o 10:43, karol pisze:

> W dniu 27.03.2017 o 10:37, LFC pisze:
>> W dniu 27.03.2017 o 09:01, karol pisze:
>

>
>

> Ustaw ACL na starcie konfiguracji
> karol
>

Jeszcze jedno pomocnicze pytanie - o położenie plików stref w kontekście
bezpieczeństwa.
Ja mam je w katalogu /var/named, zgodnie z zapisem z czystego named.conf
Czy to jest OK w tym kontekście?

LFC

[PawelS cbrbob(at)wbcd(dot)pl]

LFC pisze:
> W dniu 27.03.2017 o 10:43, karol pisze:
>> W dniu 27.03.2017 o 10:37, LFC pisze:
>>> W dniu 27.03.2017 o 09:01, karol pisze:
>>
>
>>
>>
>> Ustaw ACL na starcie konfiguracji
>> karol
>>
>
> Jeszcze jedno pomocnicze pytanie - o położenie plików stref w kontekście
> bezpieczeństwa.
> Ja mam je w katalogu /var/named, zgodnie z zapisem z czystego named.conf
> Czy to jest OK w tym kontekście?

Czytać uważnie poniższą linijkę!
To jest tylko moje własne zdanie na ten temat.

Całą konfigurację bind mam w /etc/named
/etc/named/named.conf i widoki tutaj reszta w include,
rndckey, logging, options, zone dla widoków,
wszystko powinno mieć ownera root:named,
root może modyfikować, grupa może czytać, reszta nic nie musi,
zwłaszcza plik zawierający rndckey nie powinien być dla innych dostępny,

W katalogu /var/named, który to jest workdir,
mam m.in. katalog /var/named/slave, gdzie bind może zapisywać zone,
dla których jest slave, do /etc/named nie powinien tego zapisywać.

Tak jak wspomniałem to jest moje zdanie na powyższy temat,
położenia plików konfiguracyjnych (nie tylko stref)
w kontekście bezpieczeństwa.
Nie mniej jednak chętnie poznam inne zdanie opinie
i przekonania na dobrej, bezpiecznej konfiguracji bind.

> LFC