BIND from ports FreeBSD

Два самостоятельных раздела (про View и про поддержку Response Rate Limit) объединены, т.к. имеют один общий момент: BIND для поддержки этих фич надо собирать вручную.

Поясняю. Views поддерживается в версиях BIND начиная с 9.9.6, тогда как в базе FreeBSD 9.3 идет BIND 9.9.5.

Кроме того, во FreeBSD 10.x BIND отсутствует и его надо собирать из портов. Для поддержки rrl в BIND опять же нужно компилировать с опцией поддержки rrl.

Таким образом, BIND надо собирать (из портов).

Пришлось столкнуться со следующим:

  • По умолчанию, BIND живет в /usr/sbin/named и использует конфиг в /etc/namedb/
  • BIND из портов ставится в /usr/local/sbin/named и использует конфиг в /usr/local/etc
  • BIND из портов не глотает из /etc/rc.conf строчку named_conf=“/etc/namedb/named.conf”
  • Как известно, в jail-e BIND не croot-тится
  • rndc работает криво

Соответственно, в /etc/rc.conf пришлось вставлять целый блок:

rc.conf
named_enable="YES"
named_chrootdir=""
named_program="/usr/local/sbin/named"
#named_program="/usr/sbin/named"
named_flags="-c /etc/namedb/named.conf"
#named_conf="/etc/namedb/named.conf"

Но это только первая часть марлезонского балета.

Поишлось сделать еще две вещи:

  1. повесить в /usr/local/etc симлинк на /etc/namedb/rndc.key:
    ln -s /etc/namedb/rndc.key /usr/local/etc/rndc.key

  2. Обновить named и bind-tools в /usr/sbin/ на симлинки из /usr/local/sbin/:

    mkdir /usr/oldnamed
    mv /usr/sbin/named* /usr/oldnamed/; mv /usr/sbin/rndc /usr/oldnamed/
    ln -s /usr/local/sbin/named* /usr/sbin/
    ln -s /usr/local/sbin/rndc /usr/sbin/
    rehash

PS. Zytrax http://www.zytrax.com/books/dns/ch5/ пишет, что есть способ выпрямить эту байду

Zytrax пишет, что надо ставить BIND из портов следующей командой:

cd /usr/ports/dns/bind910
make WITH_PORT_REPLACES_BASE_BIND9=yes install clean

А теперь будем ляпить rrl и view

Views and RRL in BIND

RRL

Для поддержки RRL, в глобальные опции named (блок options) достаточно воткнуть следующие строки:

options {
          rate-limit {
          responses-per-second 5;
          slip 0;
          min-table-size 6;
          };
      };

На стадии отладки можно полюбоваться на работу rrl, поставив опцию log-only yes. Надо иметь в виду, что оно будет писать логи в папку, указанную в опции directory

С учетом сказанного, в конфиге будут присутствовать такие опции:

options {
           directory "/var/named";
           ...
           rate-limit {
              responses-per-second 10;
              log-only yes;
          };
      };

Почитать про Response Rate Limit можно на сайте автора BIND: https://kb.isc.org/article/AA-00994/0

Views

Инструкция нагло стырена с kb.isc.org, где лежит в разделе, доступном только зарегистрированным пользователям (хотя регистрация бесплатная и не требует одобрения модераторов).

Файлы зоны не рассматриваются, в них изменения нет. Другое дело, что для каждого view создается свой конфиг, лежащий в папке, поименованной соответственно названию view.

Таким образм, все нововведения, касающиеся view, отражены в файле named.conf

В оригинале рассмотерны 4 варианта:

1 доверенная подсеть

Подсети “trusted” скармливается особое описание зоны:

named.example01.conf
acl trusted { 192.168.7.0/24; localhost; };
acl guest   { 192.168.8.0/24; };
 
view trusted {
    match-clients { trusted; };
 
    allow-recursion { any; };
 
    zone "myzone.example" {
        type master;
        file "db.myzone.example";
    };
    zone "7.168.192.in-addr.arpa" {
        type master;
        file "db.192.168.7";
    };
};
 
view guest {
    match-clients { guest; };
 
    allow-recursion { any; };
};

Два разных описания одного домена на 1 сервере

named.example02.conf
acl trusted { 192.168.7.0/24; localhost; };
acl guest   { 192.168.8.0/24; };
 
view trusted {
    match-clients { trusted; };
 
    allow-recursion { any; };
 
    zone "myzone.example" {
        type master;
        file "trusted/db.myzone.example";
    };
    zone "7.168.192.in-addr.arpa" {
        type master;
        file "trusted/db.192.168.7";
    };
};
 
view guest {
    match-clients { guest; };
 
    allow-recursion { any; };
 
    zone "myzone.example" {
        type master;
        file "guest/db.myzone.example";
    };
};

2 сервера с идентичными зонами

DNS Servers are social creatures and like to have company, so the operator of this network has decided that to add a second DNS server.

Thinking about each view as an independent server helps us to remember that we need to make a way for each view on Server 2 to talk to the same view on Server 1. If we don't do anything explicitly to make it happen then both views on Server 2 will be talking to the trusted view on Server 1 because of Server 2's IP address. While we could use set up additional IPs for this, using TSIG keys gives us the most flexibility and doesn't require any OS changes to configure the additional IPs on the servers.

Further information on TSIG

For information on generating and using TSIG see chapter 4 of the BIND 9 Administrator Reference Manual (ARM) appropriate for your version. The ARM for many BIND versions can be found at Software Products:BIND9:Documentation. A copy of the ARM is also included with every BIND 9 source tarball and Windows zip file downloaded from the ISC.

named.example3.server1.conf
key trusted-key {
    algorithm HMAC-MD5;
    secret some-secret;
};
 
key guest-key {
    algorithm HMAC-MD5;
    secret another-secret;
};
 
acl trusted { !key guest-key; key trusted-key; 192.168.7.0/24; localhost; };
acl guest   { !key trusted-key; key guest-key; 192.168.8.0/24; };
 
options {
    notify explicit;
    allow-transfer { none; };
};
 
view trusted {
    match-clients { trusted; };
 
    allow-recursion { any; };
 
    allow-transfer { key trusted-key; };
 
    zone "myzone.example" {
        type master;
        file "trusted/db.myzone.example";
        also-notify { 192.168.7.28 key trusted-key; };
    };
    zone "7.168.192.in-addr.arpa" {
        type master;
        file "trusted/db.192.168.7";
        also-notify { 192.168.7.28 key trusted-key; };
    };
};
 
view guest {
    match-clients { guest; };
 
    allow-recursion { any; };
 
    allow-transfer { key guest-key; };
 
    zone "myzone.example" {
        type master;
        file "guest/db.myzone.example";
        also-notify { 192.168.7.28 key guest-key; };
    };
};
named.example3.server2.conf
key trusted-key {
    algorithm HMAC-MD5;
    secret some-secret;
};
 
key guest-key {
    algorithm HMAC-MD5;
    secret another-secret;
};
 
acl trusted { !key guest-key; key trusted-key; 192.168.7.0/24; localhost; };
acl guest   { !key trusted-key; key guest-key; 192.168.8.0/24; };
 
options {
    notify explicit;
    allow-transfer { none; };
};
 
view trusted {
    match-clients { trusted; };
 
    allow-recursion { any; };
 
    zone "myzone.example" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.myzone.example";
    };
    zone "7.168.192.in-addr.arpa" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.192.168.7";
    };
};
 
view guest {
    match-clients { guest; };
 
    allow-recursion { any; };
 
    zone "myzone.example" {
        type slave;
        masters { 192.168.7.27 key guest-key; };
        file "guest/db.myzone.example";
    };
};

The “!key …” parts of the acls are important to force signed requests to be rejected from inappropriate matches before they have a chance to match on the source IP.

Note that, as written, this example allows anyone, on any network, with the TSIG key to sign regular DNS requests in order to select which view they want their answer from and also to request zone transfers. Depending on who has the key and what their motivation is, this could be considered to be either a serious problem or a nice feature. See Using Access Control Lists (ACLs) with both addresses and keys for more information on how these ACLs could be improved.

Another significant thing that this example demonstrates in the server1 configuration is that many options can be specified in both a “global” options section and inside of views, with the value specified in the view overriding the “global” value.

I've chosen to set the notify option to “explicit”. This disables the default behavior of sending NOTIFY messages to every name server listed in the zone data (except for the master listed in the SOA, which is already exempted) because those NOTIFY messages would be sent unsigned instead of with the proper view identification key.

2 сервера с общими зонами

Since the last example, the network operator has decided that they're going to create DDNS records for their guest clients in a set of new zones. While this information will mostly be used by systesm on the trusted network, the operator would like to allow the guest clients to see their own dynamically-created DNS records, which means making the same zones available in both views..

The key to making this work is to once again think about the views as independent servers and so to create an explicit relationship between the two views. We continue to use keys to make sure that the NOTIFY messages and transfer requests get sent to the correct view, where the key used matches the view that we want to receive the message.

named.example4.server1.conf
key trusted-key {
    algorithm HMAC-MD5;
    secret some-secret;
};
 
key guest-key {
    algorithm HMAC-MD5;
    secret another-secret;
};
 
key update-key {
    algorithm HMAC-MD5;
    secret yet-another-secret;
};
 
acl trusted { !key guest-key; key trusted-key; 192.168.7.0/24; localhost; };
acl guest   { !key trusted-key; key guest-key; 192.168.8.0/24; };
 
options {
    notify explicit;
};
 
view trusted {
    match-clients { trusted; };
 
    allow-recursion { any; };
 
    allow-transfer { key trusted-key; };
 
    allow-update { key update-key; };
 
    zone "myzone.example" {
        type master;
        file "trusted/db.myzone.example";
        also-notify { 192.168.7.28 key trusted-key; };
    };
    zone "7.168.192.in-addr.arpa" {
        type master;
        file "trusted/db.192.168.7";
        also-notify { 192.168.7.28 key trusted-key; };
    };
    zone "guests.example" {
        type master;
        file "trusted/db.guest.example";
        also-notify {
            192.168.7.28 key trusted-key;
            127.0.0.1    key guest-key;
        };
    };
    zone "8.168.192.in-addr.arpa" {
        type master;
        file "trusted/db.192.168.8";
        also-notify {
            192.168.7.28 key trusted-key;
            127.0.0.1    key guest-key;
        };
    };
};
 
view guest {
    match-clients { guest; };
 
    allow-recursion { any; };
 
    allow-transfer { key guest-key; };
 
    zone "myzone.example" {
        type master;
        file "guest/db.myzone.example";
        also-notify { 192.168.7.28 key guest-key; };
    };
    zone "guests.example" {
        type slave;
        masters { 127.0.0.1 key trusted-key; };
        file "guest/db.guest.example";
        also-notify { 192.168.7.28 key guest-key; };
    };
    zone "8.168.192.in-addr.arpa" {
        type slave;
        masters { 127.0.0.1 key trusted-key; };
        file "guest/db.192.168.8";
        also-notify { 192.168.7.28 key guest-key; };
    };
};
named.example4.server2.conf
key trusted-key {
    algorithm HMAC-MD5;
    secret some-secret;
};
 
key guest-key {
    algorithm HMAC-MD5;
    secret another-secret;
};
 
acl trusted { !key guest-key; key trusted-key; 192.168.7.0/24; localhost; };
acl guest   { !key trusted-key; key guest-key; 192.168.8.0/24; };
 
view trusted {
    match-clients { trusted; };
 
    allow-recursion { any; };
 
    zone "myzone.example" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.myzone.example";
    };
    zone "7.168.192.in-addr.arpa" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.192.168.7";
    };
    zone "guests.example" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.guest.example";
    };
    zone "8.168.192.in-addr.arpa" {
        type slave;
        masters { 192.168.7.27 key trusted-key; };
        file "trusted/db.192.168.8";
    };
};
 
view guest {
    match-clients { guest; };
 
    allow-recursion { any; };
 
    zone "myzone.example" {
        type slave;
        masters { 192.168.7.27 key guest-key; };
        file "guest/db.myzone.example";
    };
    zone "guests.example" {
        type slave;
        masters { 192.168.7.27 key guest-key; };
        file "guest/db.guest.example";
    };
    zone "8.168.192.in-addr.arpa" {
        type slave;
        masters { 192.168.7.27 key guest-key; };
        file "guest/db.192.168.8";
    };
};
unix/bind/named_view_rrl.txt · Last modified: 2015/02/02 21:10 by rybario
About this template
CC Attribution-Share Alike 4.0 International
Powered by PHP Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0 Valid HTML5