☰

Конфигурация DNS для многоуровневого делегированного поддомена без доступа в Интернет

tag-icon • tag-icon dns bind
Конфигурация DNS для многоуровневого делегированного поддомена без доступа в Интернет

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

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

  • мой-хост-1.мой-проект.мой-корп.com
  • мой-хост-2.область-1.мой-проект.мой-корп.com
  • мой-хост-3.область-2.мой-проект.мой-корп.com

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

  • мой-проект.мой-корп.com
  • область-1.мой-проект.мой-корп.com
  • область-2.мой-проект.мой-корп.com

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

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

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

Мой файл мастер-зоны длямой-проект.мой-корп.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

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

ВОПРОС 2

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

решение1

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

Связанный контент