Назад | Перейти на главную страницу

как разрешить поддомены в bind9

в нашей компании есть отдельные подсети / 24 от одного большого адреса класса B (/ 16).

(см. картинку)

я работаю в domain1.company.com и оттуда я могу разрешить все имена хостов в одном домене xx.domain1.company.com (пример - server1.doamin1.company.com).

я также могу выйти в Интернет, используя DNS-сервер в domain3.company.com в качестве экспедитора.

но при попытке разрешить что-либо в другом поддомене (например: server3.domain2.company.com) это не удается.

вот как мой named.conf.options выглядит как.


acl "inner-net" {
    A.B.C.0/24;
    10.11.200.0/24; //private mgmt network
};

acl "blocked-from-recursion" {
    A.B.C.66/32;
};

options {
    directory "/var/cache/bind";
    // recursion yes;
        allow-recursion { inner-net; };
    blackhole { blocked-from-recursion; };
        listen-on { any; };
        allow-transfer { none; };
    allow-query { inner-net; };
        forwarders {
                A.B.E.2; // ip address of the DNS fowarder
                x.x.x.x; //second forwarder
                //8.8.8.8;
        };
    dnssec-enable yes;
    dnssec-validation yes;

    auth-nxdomain no;    # conform to RFC1035
    // listen-on-v6 { any; };
};

что я могу сделать, чтобы решить эту проблему, если у меня нет доступа к другим DNS-серверам в других подсетях? (не могу изменить свою конфигурацию)

Изменить: добавление зон по умолчанию

/etc/ named.conf.default-zones

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

/etc/bind/ named.conf.local

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "domain1.company.com" {
    type master;
    file "/etc/bind/zones/db.domain1.company.com";
//    allow-transfer { 10.20.30.14; };
};

zone "A.B.C.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.A.B.C";
//    allow-transfer { 10.20.30.14; };
};

zone "10.11.200.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.10.11.200";
//    allow-transfer { 10.20.30.14; };
};

В целях обсуждения назовем домен вашей компании example.com что является фиктивным, в отличие от company.com который действительно существует.

TL; DR Отлаживайте проблемы DNS сверху вниз, пока не найдете уровень, на котором все ломается. Отредактируйте свой пост, включив в него некоторые основные dig результаты, такие как:

dig @A.B.E.2 example.com ns
dig @A.B.E.2 domain2.example.com ns
dig @A.B.E.2 server3.domain2.example.com

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

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

DNS является иерархическим

Если вы извините небольшой обзор для тех читателей, которые изучают DNS, DNS - это, по сути, иерархическая база данных, где серверы имен верхнего уровня определяют информацию для серверов имен второго уровня и так далее, вплоть до нескольких уровней рекурсии. DNS также может быть организован в «плоскую» топологию (все домены и субдомены смешаны в один и тот же файл зоны), но, по крайней мере, на высших уровнях он является иерархическим.

Давайте называть доменное имя вашей компании в целом как example.com.

На верхнем уровне DNS находится "." зона. Это соответствует вашей "подсказке" в вашем конфиге. В этой зоне подсказки перечислены несколько DNS-серверов верхнего уровня:

.                        3600000      NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30
; 
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     199.9.14.201
B.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:200::b
..snip..

Каждый подуровень требует, чтобы уровень выше был правильным

Эти серверы имен «корневого уровня» знают, как добраться до любого из уровней ниже этого, а если хотите, до следующих «поддоменов». Они знают, что "для com адреса, иди сюда. Для org адреса, перейдите сюда ". И так далее. Поскольку мы говорим о example.com в данном случае это означает, что следующий уровень ниже com иерархия. То же самое часто происходит на нескольких уровнях, когда мы рекурсивно спускаемся по иерархии DNS. Если какой-либо уровень выдает неверную информацию, маловероятно, что какие-либо подуровни ниже, которые будут работать должным образом. Я подозреваю, что серверы имен верхнего уровня вашей компании могут иметь ошибку конфигурации или, возможно, намеренное ограничение доступа между доменами по какой-либо причине.

Устранение неполадок дерева

Мы можем произвольно выбрать один из ROOT-SERVERS серверов имен и спросите его, куда следует отправлять запросы для .com имена хостов, используя надежную утилиту DNS dig. Здесь мы используем dig запросить сервер имен @198.41.0.4 и спроси домен com. какие ns записи - то есть, какие серверы имён для com домен?

$ dig @198.41.0.4 com. ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 2252
;; flags: qr rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 12 
;; QUESTION SECTION:
;; com. IN      NS

;; ANSWER SECTION:

;; AUTHORITY SECTION:
com.    172800  IN      NS      e.gtld-servers.net.
com.    172800  IN      NS      b.gtld-servers.net.
com.    172800  IN      NS      j.gtld-servers.net.
com.    172800  IN      NS      m.gtld-servers.net.
com.    172800  IN      NS      i.gtld-servers.net.
com.    172800  IN      NS      f.gtld-servers.net.
com.    172800  IN      NS      a.gtld-servers.net.
com.    172800  IN      NS      g.gtld-servers.net.
com.    172800  IN      NS      h.gtld-servers.net.
com.    172800  IN      NS      l.gtld-servers.net.
com.    172800  IN      NS      k.gtld-servers.net.
com.    172800  IN      NS      c.gtld-servers.net.
com.    172800  IN      NS      d.gtld-servers.net.

;; ADDITIONAL SECTION:
e.gtld-servers.net.     172800  IN      A       192.12.94.30
e.gtld-servers.net.     172800  IN      AAAA    2001:502:1ca1::30
b.gtld-servers.net.     172800  IN      A       192.33.14.30
b.gtld-servers.net.     172800  IN      AAAA    2001:503:231d::2:30
j.gtld-servers.net.     172800  IN      A       192.48.79.30
j.gtld-servers.net.     172800  IN      AAAA    2001:502:7094::30
m.gtld-servers.net.     172800  IN      A       192.55.83.30
m.gtld-servers.net.     172800  IN      AAAA    2001:501:b1f9::30
i.gtld-servers.net.     172800  IN      A       192.43.172.30
i.gtld-servers.net.     172800  IN      AAAA    2001:503:39c1::30
f.gtld-servers.net.     172800  IN      A       192.35.51.30
f.gtld-servers.net.     172800  IN      AAAA    2001:503:d414::30

;; Query time: 23 msec
;; SERVER: 198.41.0.4
;; WHEN: Fri Aug  9 12:55:15 2019
;; MSG SIZE  rcvd: 509

Это неплохой результат, поэтому я его разбью. Самая важная строка для нашей непосредственной цели:

;; flags: qr rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 12

Это означает, что сервер имен, который мы опрашивали по адресу 198.41.0.4, получил 1 запрос, вернул 0 ответов и 13 авторитетных источников. Мы пока проигнорируем «дополнительные» записи, но в основном они существуют для удобства и для ускорения дальнейших DNS-запросов, которые могут возникнуть.

Тот факт, что мы получили 0 ответов, в основном означает, что сервер имен говорит нам: «Я не знаю ответа ...», а 13 авторитетных записей означают: «... но я делать знайте, что эти серверы имен могут ответить на этот вопрос ". Это называется delegated домен. На высшем уровне ROOT-SERVERS не имеют прямого знания о com домен (кроме существующего), но они специально делегировали полномочия для com домены к 13 серверам имен, которые появляются в списке. У любого из них можно запросить подробную информацию о доменах в com иерархия. Сделаем именно это:

$ dig @192.12.94.30 example.com ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 38217
;; flags: qr rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;; example.com.       IN      NS

;; ANSWER SECTION:

;; AUTHORITY SECTION:
example.com.  172800  IN      NS      ns.example.com.
example.com.  172800  IN      NS      ns2.example.com.

;; ADDITIONAL SECTION:
ns.example.com.       172800  IN      A       172.16.177.4
ns2.example.com.      172800  IN      A       172.16.217.4

;; Query time: 4 msec
;; SERVER: 192.12.94.30
;; WHEN: Fri Aug  9 13:05:51 2019
;; MSG SIZE  rcvd: 98

Часть этой информации выдумана с целью иллюстрации. В частности, давайте сделаем вид, что 172.16.x.y адреса - это настоящие общедоступные IP-адреса, которые в значительной степени должны быть .com домен. Снова мы видим ANSWER: 0 поэтому сервер имен говорит нам: "Я не знаю example.com, но у этих серверов имен есть. " ns.example.com и ns2.example.com являются серверами домена высшего уровня вашей компании. Они могут не быть разрешающими серверами (а лучше всего этого не делать), но они должны быть авторитетными. То есть им нужно либо а) иметь ответ на любой DNS-запрос о вашей компании example.com домен; или б) им нужно знать, куда направить DNS-клиента, который ищет любую запись DNS, которая не доступна напрямую от них. Кажется вероятным, что это уровень, на котором возникает ваша проблема, на серверах имен верхнего уровня вашей компании.

Как я упоминал ранее, иерархическая природа DNS означает, что проблема высокого уровня может помешать правильной работе более низких уровней DNS. В частности, если произошла ошибка конфигурации в ns.example.com помешал вам получить информацию о субдомене domain1.example.com, это одна из причин, по которой у вас могут возникнуть проблемы. Другой причиной может быть то, что сервер имен верхнего уровня выдает правильную информацию, но внутренние политики маршрутизации или брандмауэра компании намеренно или непреднамеренно блокируют ваш доступ.

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

dig @192.12.94.30 example.com ns

Это должно вернуть что-то вроде вымышленной информации выше и рассказать вам, какие серверы имен верхнего уровня являются для названия вашей компании. Теперь мы запросим их напрямую и запросим информацию о субдомене. Поскольку мы настроены скептически, мы зададим ему вопрос, на который уже знаем ответ. Сервер имен для domain1.example.com является ваш BIND сервер, правильно? Посмотрим, согласны ли корпоративные серверы имен:

dig @172.16.177.4 domain1.example.com ns

Вместо 172.16.177.4 используйте фактический IP, возвращенный предыдущим dig команда. Как правило, информация, которую вы затем видите, должна подтверждать конфигурацию вашего существующего сервера BIND (это имя хоста и номер IP), поскольку он является авторитетным для domain1.example.com.

Сломанная делегация?

Точно так же серверы имен компаний верхнего уровня должны знать, какие серверы имен следует использовать для все действующие поддомены в вашей компании. По определению авторитетный сервер имен должен знать ответ на любой запрос в этом домене или, по крайней мере, иметь возможность ссылаться на другой сервер имен, который знает ответ (или знает кого-то, кто знает и т. Д.). поскольку domain2.example.com это конкретный проблемный случай для вас, давайте посмотрим на это:

dig @172.16.177.4 domain2.example.com ns

Здесь может возникнуть как минимум пара случаев. В качестве первого случая предположим, что ns.example.com неправильно настроен и не знает, что domain2.example.com существуют. Вы бы увидели такой ответ:

;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 21457
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; domain2.example.com.       IN      NS

;; ANSWER SECTION:

;; AUTHORITY SECTION:
example.com.  3600    IN      SOA     ns.example.com. hostmaster.example.com. 201906260 7200 900 2592000 3600

;; ADDITIONAL SECTION:

;; Query time: 4 msec
;; SERVER: 172.16.177.146
;; WHEN: Fri Aug  9 14:03:16 2019
;; MSG SIZE  rcvd: 89

Опять же, обратите внимание: ANSWER: 0; AUTHORITY: 1. «Не знаю», но вторая часть другая. В ответах "рефералов" выше мы получили дополнительные NS записи для просмотра, что означает «Я не знаю, но спросите у одного из них». Здесь запись «авторитет» - это запись «Начало полномочий» для самого домена. Другими словами, это может означать "больше не у кого спрашивать, потому что я являюсь окончательным сервером для example.com. "Этот стиль результата (ответ: 0, авторитет, указывающий на SOA для домена) является окончательным", что запись не существует ". Строка rcode: NXDOMAIN также является диагностикой результата «не существует».

Недоступный сервер имен

Второй случай, который может возникнуть, - это когда сервер имен компании возвращает значение, но вы не можете связаться с этим хостом. Предположим, вы ищите на серверах имен domain2.example.com и получить:

$ dig @172.16.177.146 domain2.example.com ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3098
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 5
;; QUESTION SECTION:
;; domain2.example.com.        IN      NS

;; ANSWER SECTION:
domain2.example.com.   3600    IN      NS      ns1.domain2.example.com.
domain2.example.com.   3600    IN      NS      ns2.domain2.example.com.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
ns1.domain2.example.com.       3600    IN      A       172.16.92.50
ns2.domain2.example.com.       3600    IN      A       172.16.27.50

;; Query time: 0 msec
;; SERVER: 172.16.177.146
;; WHEN: Fri Aug  9 14:08:17 2019
;; MSG SIZE  rcvd: 200

Это кажется многообещающим! Теперь мы знаем, кого просить разрешить имена хостов в domain2. Но если это произойдет:

$ dig @172.16.27.50 host.domain2.example.com
Error: error sending query: Could not send or receive, because of network error

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

"Хромой" сервер имен

Если сервер имен делегирует поддомен другому серверу имен, но этот второй сервер имен не знает об этом делегировании (другими словами, он специально не настроен для ответа на запросы для этой зоны), то нижестоящий сервер имен называется «хромым». Он должен отвечать на запросы, но не знает, что должен. Или иногда может случиться иным образом, что нисходящий сервер имен был удален, но вышестоящий сервер имен все еще выдает неправильные реферальные записи. У меня нет простого примера того, как это будет выглядеть, но со временем вы испытаете это. Первый сервер имен скажет: «Я не знаю, но спросите этого парня». Второй сервер имен скажет: «Откуда мне знать? Почему вы меня спрашиваете?»

Резюме

Поскольку это иерархическая база данных, поиск в которой осуществляется рекурсивно, DNS может дать сбой, если произойдет сбой на одном уровне. Ключ к устранению неполадок, связанных с невозможностью разрешать DNS-запросы, - это начать сверху и работать вниз, пока не найдете последний уровень, который правильно разрешает запросы. Вероятно, проблема находится на следующем уровне - реферальные записи, возвращенные последним известным хорошим сервером имен.

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