Двухвостый DNS сервер с BIND9

Этот учебник показывает, как настроить DNS сервер BIND9 для обслуживания внутренней и внешней сети одновременно с различным набором информации. Для достижения этой цели используется новая функция BIND9, называемая view. В качестве учебного пособия он проведет вас через весь процесс настройки, но требуется начальное знание BIND и DNS, существует множество документов, которые охватывают эту информацию в Интернете.

Продолжайте читать на оригинальном сайте или скачайте PDF.

Содержание

• 1 Проблема
• 2 Начальная конфигурация
• 3 Внутренние и внешние
• 4 Безопасность
• 5 Конфигурационные файлы - 5.1 /etc/bind/named.conf.local
• 5.2 /etc/bind/externals/db.example.com
• 5.3 /etc/bind/internals/db.example.com
• Библиография

1 Проблема

Это типичная проблема в растущих организациях, что им нужно решить две проблемы одновременно:

• Иметь DNS сервер для внутренней сети компании, потому что давно уже было слишком много компьютеров, чтобы запомнить их IP 1 и даже слишком много компьютеров, чтобы поддерживать набор файлов хостов 2.
• Иметь DNS сервер для внешних серверов, для внешних клиентов и т.д.

Решение этих проблем становится еще большей проблемой, когда растущая организация не может предоставить больше ресурсов, чем один DNS сервер 3. Это большая проблема, потому что если вы просто настроите свой сервер со всеми вашими именами, публичными и частными, вы в конечном итоге загрязните Интернет частными адресами, что очень плохо, а также покажете миру часть топологии вашей внутренней сети. Чего вы не хотите, чтобы возможный злоумышленник/взломщик имел.

Другой частью проблемы является то, что для эффективности вы можете захотеть разрешать внутренние IP, когда вы находитесь внутри, и внешние IP, когда вы находитесь снаружи. Здесь я говорю о компьютерах, которые имеют публичные и частные соединения.

Существует множество различных решений этой проблемы, и я помню, как решал ее даже с BIND4, но теперь я собираюсь использовать BIND9, чтобы сделать решение, которое очень чистое. Это было развернуто на сервере Debian GNU/Linux 3.1, но оно также должно работать для других операционных систем, которые запускают BIND9, просто убедитесь, что вы изменили свои пути соответствующим образом.

2 Начальная конфигурация

Давайте представим, что организация, в которой я работаю, делает примеры… чего? Я не знаю, но вы можете заказать их на example.com. Корпорации Examples была назначена сеть 192.0.2.0/24, а внутренне мы используем 10.0.0.0/24.

Давайте начнем обслуживать внешние имена и IP, мы редактируем /etc/bind/named.conf.local 4 и добавляем:

zone "example.com" {  
    type master;  
    file "/etc/bind/db.example.com";  
};

и затем мы создаем /etc/bind/db.example.com с следующим содержимым:

; example.com  
$TTL    604800  
@       IN      SOA     ns1.example.com. root.example.com. (  
                     2006020201 ; Serial  
                         604800 ; Refresh  
                          86400 ; Retry  
                        2419200 ; Expire  
                         604800); Negative Cache TTL  
;  
@       IN      NS      ns1  
        IN      MX      10 mail  
        IN      A       192.0.2.1  
ns1     IN      A       192.0.2.1  
mail    IN      A       192.0.2.128 ; У нас есть наш почтовый сервер где-то еще.  
www     IN      A       192.0.2.1  
client1 IN      A       192.0.2.201 ; Мы часто подключаемся к client1.

Как вы можете видеть, наша начальная установка имеет один компьютер для обслуживания всех, кроме почты, он даже удерживает IP переадресацию и пару баз данных.

Теперь хорошая настройка DNS имеет как минимум один вторичный сервер, и на самом деле некоторые регистраторы (где вы регистрируете доменные имена) это требуют. Поскольку у нас нет второго компьютера, мы идем в XName, открываем аккаунт и регистрируем example.com как вторичный с 192.0.2.1 как IP для передачи. Теперь нам нужно разрешить IP XName выполнять передачу; мы небольшая организация, но поскольку мы хотим быть успешным стартапом, мы стараемся делать все как можно более умно. Поэтому мы используем директиву конфигурации BIND9 acl, чтобы определить идентификатор, который ссылается на IP адреса XName; в начале /etc/bind/named.conf.local мы добавляем:

acl slaves {  
    195.234.42.0/24;    // XName  
    193.218.105.144/28; // XName  
    193.24.212.232/29;  // XName  
};

и мы изменяем объявление зоны на:

zone "example.com" {  
    type master;  
    file "/etc/bind/db.example.com";  
    allow-transfer { slaves; };  
};

Мы могли бы просто ввести IP, где мы вводим “slaves”.

3 Внутренние и внешние

Теперь, когда у нас есть надежная база, мы можем начать думать о том, чтобы обслуживать разные содержимое для внутренней и внешней сети, но сначала мы должны определить, что является внутренним, а что внешним.

В /etc/bind/named.conf.local мы добавляем следующее определение (вверху или под определением slaves):

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

Если бы у нас было больше внутренних сетей, мы могли бы просто добавить их туда. Мы не определяем внешние, потому что все, что не является внутренним, является внешним. Вы можете, если хотите, определить наборы различных внешних, если хотите обслуживать различный контент для различных частей Интернета.

Мы будем использовать новую функцию BIND9, называемую views. View позволяет поместить часть конфигурации внутри условия, которое может зависеть от множества вещей, в данном случае мы просто будем зависеть от internals. Мы заменяем объявление зоны в /etc/bind/named.conf.local на:

view "internal" {  
    match-clients { internals; };  
    zone "example.com" {  
        type master;  
        file "/etc/bind/internals/db.example.com";  
    };  
};  
view "external" {  
    match-clients { any; };  
    zone "example.com" {  
        type master;  
        file "/etc/bind/externals/db.example.com";  
        allow-transfer { slaves; };  
    };  
};

Директива конфигурации match clients позволяет нам условно показывать этот view на основе набора IP, “any” означает любой IP. Внутренние IP будут кэшироваться внутренним view, а остальные будут отброшены во внешнем view. Внешний мир не может видеть внутренний view, и это включает XName, нашего вторичного провайдера DNS, но мы убрали allow-transfer из внутреннего view, поскольку мы не хотим, чтобы кто-либо мог передать содержимое внутреннего view ни при каких обстоятельствах.

Мы также изменили путь, нам придется создать директории /etc/bind/externals и /etc/bind/internals и переместить /etc/bind/db.example.com в /etc/bind/externals/.

В /etc/bind/internals/db.example.com мы помещаем файл зоны, аналогичный соответствующему внешнему, но содержащему внутренние IP:

; example.com  
$TTL    604800  
@       IN      SOA     ns1.example.com. root.example.com. (  
                     2006020201 ; Serial  
                         604800 ; Refresh  
                          86400 ; Retry  
                        2419200 ; Expire  
                         604800); Negative Cache TTL  
;  
@       IN      A       10.0.0.1  
boss    IN      A       10.0.0.100  
printer IN      A       10.0.0.101  
scrtry  IN      A       10.0.0.102  
sip01   IN      A       10.0.0.201  
lab     IN      A       10.0.0.103

Отлично, теперь мы можем пинговать компьютер нашего босса с

ping boss.example.com

но попытка достучаться до mail.example.com разочарует нас, что произошло? Внутренний файл зоны не содержит ссылки на mail.example.com, и поскольку мы находимся во внутренней сети, мы можем разрешить mail.example.com. Хорошо, давайте просто скопируем содержимое внешнего файла зоны во внутренний файл зоны. Это сработает.

Но мы маленький, умный стартап, мы можем сделать лучше, чем копировать и вставлять каждое изменение в файл зоны, кроме того, это очень подвержено ошибкам (будете ли вы всегда помнить о том, чтобы изменить внутренний файл зоны, когда изменяете внешний, или забудете и проведете несколько дней, отлаживая сетевые проблемы?).

Что мы сделаем, так это включим внешний файл зоны во внутренний файл вот так:

$include "/etc/bind/external/db.example.com"  
@       IN      A       10.0.0.1  
boss    IN      A       10.0.0.100  
printer IN      A       10.0.0.101  
scrtry  IN      A       10.0.0.102  
sip01   IN      A       10.0.0.201  
lab     IN      A       10.0.0.103

и вуаля! Найти директиву $include в текущей документации было сложно… Просто помните, чтобы изменить серийный номер внешнего файла зоны каждый раз, когда вы изменяете внутренний, но это не большая проблема, если вы забудете, ничего плохого не произойдет, поскольку вы вряд ли будете иметь кэшированные серверы внутри вашей собственной маленькой сети.

4 Безопасность

Не рекомендуется использовать один и тот же DNS сервер в качестве основного для какого-либо домена (в нашем случае example.com) и в качестве кэшированного DNS сервера, но в нашем случае мы вынуждены это делать. Снаружи 192.0.2.1 является основным DNS сервером для example.com, из нашей внутренней сети 192.0.2.1 (или его частный адрес, 10.0.0.1) является нашим кэшированным именем сервером, который должен быть настроен как nameserver для использования на каждой рабочей станции, которую мы имеем.

Одна из проблем заключается в том, что кто-то может начать использовать наш кэшированный nameserver снаружи, существует атака, называемая cache-poisoning, и многие другие неприятные вещи, которые можно сделать и задокументированы на SINS (включая то, как их избежать).

Чтобы немного улучшить нашу безопасность, мы добавим пару директив в файл конфигурации:

view "internal" {  
    match-clients { internals; };  
    recursion yes;
    zone "example.com" {
        type master;
        file "/etc/bind/internals/db.example.com";
    };
};
view "external" {
    match-clients { any; };
    recursion no;

    zone "example.com" {
        type master;
        file "/etc/bind/externals/db.example.com";
        allow-transfer { slaves; };
    };
};

Это предотвратит использование нашего сервера рекурсивно кем-либо на опасном Интернете, в то время как мы, в нашей собственной сети, все еще можем это делать.

5 Конфигурационные файлы

5.1 /etc/bind/named.conf.local

acl slaves {  
    195.234.42.0/24;    // XName  
    193.218.105.144/28; // XName  
    193.24.212.232/29;  // XName  
};  
  
acl internals {  
    127.0.0.0/8;  
    10.0.0.0/24;  
};  
  
view "internal" {  
    match-clients { internals; };  
    recursion yes;  
    zone "example.com" {  
        type master;  
        file "/etc/bind/internals/db.example.com";  
    };  
};  
view "external" {  
    match-clients { any; };  
    recursion no;  
    zone "example.com" {  
        type master;  
        file "/etc/bind/externals/db.example.com";  
        allow-transfer { slaves; };  
    };  
};

5.2 /etc/bind/externals/db.example.com

; example.com  
$TTL    604800  
@       IN      SOA     ns1.example.com. root.example.com. (  
                     2006020201 ; Serial  
                         604800 ; Refresh  
                          86400 ; Retry  
                        2419200 ; Expire  
                         604800); Negative Cache TTL  
;  
@       IN      NS      ns1  
        IN      MX      10 mail  
        IN      A       192.0.2.1  
ns1     IN      A       192.0.2.1  
mail    IN      A       192.0.2.128 ; У нас есть наш почтовый сервер где-то еще.  
www     IN      A       192.0.2.1  
client1 IN      A       192.0.2.201 ; Мы часто подключаемся к client1.

5.3 /etc/bind/internals/db.example.com

$include "/etc/bind/external/db.example.com"  
@       IN      A       10.0.0.1  
boss    IN      A       10.0.0.100  
printer IN      A       10.0.0.101  
scrtry  IN      A       10.0.0.102  
sip01   IN      A       10.0.0.201  
lab     IN      A       10.0.0.103

Библиография

SINS

Обеспечение безопасности интернет-сервера имен

Сноски

… IPs

1

Для меня два компьютера уже квалифицируются как слишком много компьютеров, чтобы запомнить их IP.

… файлы

2

Файл хостов находится в /etc/hosts и является простой сопоставлением для локального компьютера от имен к IP. Это был первый способ разрешения имен в IP, и давно поддерживался центральный большой файл хостов, который позже распространялся по FTP или аналогично. Он быстро стал проблемой, которую решили с изобретением DNS. Постарайтесь не позволить вашему файлу хостов вырасти в проблему, прежде чем вы превратите его в DNS, учитесь на опыте пионеров!

… сервер

3

Или когда вы перфекционист и верите, что это должно быть осуществимо только с одним сервером.

…/etc/bind/named.conf.local

4

Это может быть просто /etc/bind/named.conf в вашей операционной системе, если это не Debian.