Я использую Bind 9 под Debian. У меня есть один мастер и один вторичный.

Мои доменные имена структурированы следующим образом:

  • my-host-1.my-project.my-corp.com
  • my-host-2.area-1.my-project.my-corp.com
  • my-host-3.area-2.my-project.my-corp.com

Мои серверы имен являются авторитетными для:

  • my-project.my-corp.com
  • area-1.my-project.my-corp.com
  • area-2.my-project.my-corp.com

Мои серверы имен не являются полномочными для my-corp.com, и у меня нет административных прав для серверов имен, которые являются полномочными для my-corp.com.

Итак, серверы имен my-corp.com делегируют запросы для моих доменов моим серверам имен, а мои серверы имен пересылают запросы, на которые они не могут напрямую отвечать серверам имен my-corp.com . Такое расположение не является обязательным. Это требуется ИТ-отделом моей компании. Так что, в частности, мои серверы имен не могут выполнять итеративные запросы или каким-либо другим образом достигать любого сервера имен в Интернете.

Серверы имен my-corp.com имеют следующие IP-адреса:

  • 10.0.0.1/24 (основной)
  • 10.0.0.2/24 (среднее)

Выделенный мне блок IP-адреса - 10.1.0.0/23. Это актуально для обратного разрешения.

Мои серверы имен имеют следующие IP-адреса и имена хостов:

  • 10.1.0.1/23, ns1.my-project.my-corp.com (основной)
  • 10.1.1.1/23, ns2.my-project.my-corp.com (дополнительный)

Моя основная конфигурация сервера имен выглядит следующим образом:

options {
        directory "/etc/bind";
        forward only;
        forwarders {
                10.0.0.1; 10.0.0.2;
        };

zone "my-project.my-corp.com" {
   type master;
   file "db.my-project.my-corp.com";
};

zone "0.1.10.in-addr.arpa" {
   type master;
   file "db.10.1.0";
};

zone "1.1.10.in-addr.arpa" {
   type master;
   file "db.10.1.1";
};

// ALL OF THE FOLLOWING IS DEFAULT IN BIND 9.

// prime the server with knowledge of the root servers

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";
};

Мой файл мастер-зоны для my-project.my-corp.com выглядит следующим образом:

$TTL 3h

my-project.my-corp.com.   IN   SOA   ns1.my-project.my-corp.com. root.localhost. (
   2018010500 ; Serial
   3h         ; Refresh
   1h         ; Retry
   1w         ; Expire
   3h     )   ; Negative Cache TTL

my-project.my-corp.com.   IN   NS   ns1.my-project.my-corp.com.
my-project.my-corp.com.   IN   NS   ns2.my-project.my-corp.com.

ns1.my-project.my-corp.com.                IN   A   10.1.0.1
ns2.my-project.my-corp.com.                IN   A   10.1.1.1
my-host-1.my-project.my-corp.com.          IN   A   10.1.0.2
my-host-2.area-1.my-project.my-corp.com.   IN   A   10.1.0.3
my-host-3.area-2.my-project.my-corp.com.   IN   A   10.1.1.2

Мой файл мастер-зоны для 0.1.10.in-addr.arpa выглядит следующим образом:

$TTL 3h

0.1.10.in-addr.arpa.   IN   SOA   ns1.my-project.my-corp.com. root.localhost. (
   2018010500 ; Serial
   3h         ; Refresh
   1h         ; Retry
   1w         ; Expire
   3h     )   ; Negative Cache TTL

0.1.10.in-addr.arpa.     IN   NS    ns1.my-project.my-corp.com.
0.1.10.in-addr.arpa.     IN   NS    ns2.my-project.my-corp.com.

1.0.1.10.in-addr.arpa.   IN   PTR   ns1.my-project.my-corp.com.
2.0.1.10.in-addr.arpa.   IN   PTR   my-host-1.my-project.my-corp.com.
3.0.1.10.in-addr.arpa.   IN   PTR   my-host-2.area-1.my-project.my-corp.com.

Мой файл основной зоны для 1.1.10.in-addr.arpa выглядит следующим образом:

$TTL 3h

1.1.10.in-addr.arpa.   IN   SOA   ns1.my-project.my-corp.com. root.localhost. (
   2018010500 ; Serial
   3h         ; Refresh
   1h         ; Retry
   1w         ; Expire
   3h     )   ; Negative Cache TTL

1.1.10.in-addr.arpa.     IN   NS    ns1.my-project.my-corp.com.
1.1.10.in-addr.arpa.     IN   NS    ns2.my-project.my-corp.com.

1.1.1.10.in-addr.arpa.   IN   PTR   ns2.my-project.my-corp.com.
2.1.1.10.in-addr.arpa.   IN   PTR   my-host-3.area-2.my-project.my-corp.com.

У меня два вопроса.

ВОПРОС 1

Можно ли размещать хосты из my-project.my-corp.com и двух его поддоменов непосредственно в той же зоне, как я делал выше?

ВОПРОС 2

Поскольку мои серверы имен не могут подключиться к Интернету, как мне обращаться с корневыми серверами имен? Должен ли я просто не настраивать их вообще, так как я никогда не буду выполнять итеративный запрос? Если они должны быть определены, как я должен их определить?

1 ответ1

2

Q2 v Как мне обращаться с корневыми серверами имен?

У вас есть forward only; установить вместе с экспедиторами. Корневые подсказки не будут использоваться.

Можно ли ставить хосты с my-project.my-corp.com?

Да, это прекрасно. Вам не нужно создавать дополнительные файлы зон, если только вам не нужно обрабатывать зоны разными серверами имен или иметь разные параметры запроса или что-то в этом роде.

Вы можете сделать свою зону более простой, если пропустите добавление зоны и упоминание «IN».

$TTL 3h
@  SOA   ns1.my-project.my-corp.com. root.localhost. (
   2018010500 ; Serial
   3h         ; Refresh
   1h         ; Retry
   1w         ; Expire
   3h     )   ; Negative Cache TTL

@  NS   ns1
@  NS   ns2
ns1               A   10.1.0.1
ns2               A   10.1.1.1
my-host-1         A   10.1.0.2
my-host-2.area-1  A   10.1.0.3
my-host-3.area-2  A   10.1.1.2

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .