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

bind не может запросить некоторые серверы / домены

У нас возникли проблемы с DNS-сервером нашей компании при попытке разрешить только определенные домены, мы запускаем BIND 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 на сервере CentOS 6.5. Мы отвечаем за некоторые зоны, и наши внутренние клиенты и почтовая система разрешают использование этого сервера. Один из доменов, с которым у нас возникли проблемы, - это www.dhl.com, вот что мы получаем при запросе с помощью dig:

[root@serverx etc] dig www.dhl.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> www.dhl.com
;; global options: +cmd
;; connection timed out; no servers could be reached

и

[root@serverx etc]# dig +trace www.dhl.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> +trace www.dhl.com
;; global options: +cmd
.           517419  IN  NS  g.root-servers.net.
.           517419  IN  NS  a.root-servers.net.
.           517419  IN  NS  h.root-servers.net.
.           517419  IN  NS  m.root-servers.net.
.           517419  IN  NS  f.root-servers.net.
.           517419  IN  NS  b.root-servers.net.
.           517419  IN  NS  l.root-servers.net.
.           517419  IN  NS  j.root-servers.net.
.           517419  IN  NS  k.root-servers.net.
.           517419  IN  NS  e.root-servers.net.
.           517419  IN  NS  i.root-servers.net.
.           517419  IN  NS  d.root-servers.net.
.           517419  IN  NS  c.root-servers.net.
;; Received 496 bytes from 192.168.X.X#53(192.168.X.X) in 11 ms

com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
;; Received 489 bytes from 202.12.27.33#53(202.12.27.33) in 6128 ms

dhl.com.        172800  IN  NS  ns4.dhl.com.
dhl.com.        172800  IN  NS  ns6.dhl.com.
dig: couldn't get address for 'ns4.dhl.com': no more

И когда я копаюсь на DNS-сервере Google:

dig @8.8.4.4 www.dhl.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> @8.8.4.4 www.dhl.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11325
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dhl.com.           IN  A

;; ANSWER SECTION:
www.dhl.com.        1619    IN  CNAME   ngw.dhl.com.edgesuite.net.
ngw.dhl.com.edgesuite.net. 8520 IN  CNAME   a1085.g.akamai.net.
a1085.g.akamai.net. 19  IN  A   23.74.2.113
a1085.g.akamai.net. 19  IN  A   23.74.2.120

;; Query time: 229 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Dec  4 14:47:56 2014
;; MSG SIZE  rcvd: 129

Нет проблем !, и с того же сервера ...

Когда вы смотрите в "/ var / log / messages", ничего не регистрируется !!!. Опять же, это происходит только с определенными доменами, и этот сервер работал нормально пару дней назад, мы также отключили selinux в целях тестирования.

Это наш файл named.conf (named запускается в среде chroot):

options {
//      listen-on port 53 { 127.0.0.1;192.168.xx.x; };
//      listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
//      allow-query     { localhost; };
        allow-query     { any; };
        recursion yes;
        allow-recursion { recursive-clients; };
//      query-source address * port 53;
//      dnssec-enable yes;
        dnssec-enable no;
//      dnssec-validation yes;
        dnssec-validation no;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
        allow-transfer { xxx.x.x.x; xxx.x.x.x; xxx.x.x.x; 127.0.0.1; };
        allow-update { 192.168.xx.xx; };
//        forwarders { 8.8.4.4; };
};

acl recursive-clients { xxx.x.x.x/24; 127.0.0.1; xxx.xxx.xx.x/24; xx.xxx.xxx.xxx/29; xxx.xxx.xx.x;};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };

};

zone "." IN {
        type hint;
        file "named.ca";
};


zone "domain.com.xx" IN {
        type master;
        file "db.domain.com.xx";
        allow-transfer { xxx.xxx.xx.xx; xxx.xxx.xxx.x; };
};

zone "xx.xxx.xxx.in-addr.arpa" IN {
        type master;
        file "db.xxx.xxx.xx";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

Есть идеи, ребята ??? ... Я проводил тесты и исследования со вчерашнего дня, и я не могу понять, что происходит !!!

Заранее благодарим за любую помощь или идею.

Вот результат использования dig + trace + additional www.dhl.com:

копать + трассировать + дополнительный www.dhl.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> +trace +additional www.dhl.com
;; global options: +cmd
.           518340  IN  NS  h.root-servers.net.
.           518340  IN  NS  l.root-servers.net.
.           518340  IN  NS  e.root-servers.net.
.           518340  IN  NS  k.root-servers.net.
.           518340  IN  NS  i.root-servers.net.
.           518340  IN  NS  m.root-servers.net.
.           518340  IN  NS  b.root-servers.net.
.           518340  IN  NS  c.root-servers.net.
.           518340  IN  NS  g.root-servers.net.
.           518340  IN  NS  f.root-servers.net.
.           518340  IN  NS  d.root-servers.net.
.           518340  IN  NS  a.root-servers.net.
.           518340  IN  NS  j.root-servers.net.
k.root-servers.net. 518345  IN  A   193.0.14.129
k.root-servers.net. 518345  IN  AAAA    2001:7fd::1
b.root-servers.net. 518345  IN  A   192.228.79.201
b.root-servers.net. 518345  IN  AAAA    2001:500:84::b
c.root-servers.net. 518345  IN  A   192.33.4.12
c.root-servers.net. 518345  IN  AAAA    2001:500:2::c
i.root-servers.net. 518345  IN  A   192.36.148.17
i.root-servers.net. 518345  IN  AAAA    2001:7fe::53
f.root-servers.net. 518345  IN  A   192.5.5.241
f.root-servers.net. 518345  IN  AAAA    2001:500:2f::f
h.root-servers.net. 518345  IN  A   128.63.2.53
h.root-servers.net. 518345  IN  AAAA    2001:500:1::803f:235
a.root-servers.net. 518345  IN  A   198.41.0.4
;; Received 508 bytes from 192.168.x.x#53(192.168.x.x) in 11363 ms

com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
a.gtld-servers.net. 172800  IN  A   192.5.6.30
b.gtld-servers.net. 172800  IN  A   192.33.14.30
c.gtld-servers.net. 172800  IN  A   192.26.92.30
d.gtld-servers.net. 172800  IN  A   192.31.80.30
e.gtld-servers.net. 172800  IN  A   192.12.94.30
f.gtld-servers.net. 172800  IN  A   192.35.51.30
g.gtld-servers.net. 172800  IN  A   192.42.93.30
h.gtld-servers.net. 172800  IN  A   192.54.112.30
i.gtld-servers.net. 172800  IN  A   192.43.172.30
j.gtld-servers.net. 172800  IN  A   192.48.79.30
k.gtld-servers.net. 172800  IN  A   192.52.178.30
l.gtld-servers.net. 172800  IN  A   192.41.162.30
m.gtld-servers.net. 172800  IN  A   192.55.83.30
a.gtld-servers.net. 172800  IN  AAAA    2001:503:a83e::2:30
;; Received 489 bytes from 202.12.27.33#53(202.12.27.33) in 4335 ms

dhl.com.        172800  IN  NS  ns4.dhl.com.
dhl.com.        172800  IN  NS  ns6.dhl.com.
ns4.dhl.com.        172800  IN  A   165.72.192.16
ns6.dhl.com.        172800  IN  A   199.40.254.166
dig: couldn't get address for 'ns4.dhl.com': no more

Вывод из dig + tcp www.redhat.com

dig + tcp www.redhat.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> +tcp www.redhat.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62110
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 8, ADDITIONAL: 8

;; QUESTION SECTION:
;www.redhat.com.            IN  A

;; ANSWER SECTION:
www.redhat.com.     11  IN  CNAME   wildcard.redhat.com.edgekey.net.
wildcard.redhat.com.edgekey.net. 20484 IN CNAME wildcard.redhat.com.edgekey.net.globalredir.akadns.net.
wildcard.redhat.com.edgekey.net.globalredir.akadns.net. 2485 IN CNAME e1890.b.akamaiedge.net.
e1890.b.akamaiedge.net. 20  IN  A   172.229.164.152

;; AUTHORITY SECTION:
b.akamaiedge.net.   2874    IN  NS  n2b.akamaiedge.net.
b.akamaiedge.net.   2874    IN  NS  n3b.akamaiedge.net.
b.akamaiedge.net.   2874    IN  NS  n4b.akamaiedge.net.
b.akamaiedge.net.   2874    IN  NS  n1b.akamaiedge.net.
b.akamaiedge.net.   2874    IN  NS  n7b.akamaiedge.net.
b.akamaiedge.net.   2874    IN  NS  n5b.akamaiedge.net.
b.akamaiedge.net.   2874    IN  NS  n6b.akamaiedge.net.
b.akamaiedge.net.   2874    IN  NS  n0b.akamaiedge.net.

;; ADDITIONAL SECTION:
n5b.akamaiedge.net. 6917    IN  A   201.144.215.107
n1b.akamaiedge.net. 4917    IN  A   23.61.206.74
n6b.akamaiedge.net. 2917    IN  A   201.144.215.108
n2b.akamaiedge.net. 6917    IN  A   192.204.11.244
n4b.akamaiedge.net. 4917    IN  A   201.144.215.110
n7b.akamaiedge.net. 4917    IN  A   201.144.215.113
n0b.akamaiedge.net. 2917    IN  A   23.61.206.68
n3b.akamaiedge.net. 2917    IN  A   201.144.215.114

;; Query time: 132 msec
;; SERVER: 192.168.x.x#53(192.168.x.x)
;; WHEN: Thu Dec  4 16:03:03 2014
;; MSG SIZE  rcvd: 463

Другие тесты:

traceroute -U -p 53 165.72.192.16
traceroute to 165.72.192.16 (165.72.192.16), 30 hops max, 60 byte packets
 1  192.168.17.10 (192.168.17.10)  0.724 ms  0.718 ms  0.681 ms
 2  168.243.205.74 (168.243.205.74)  4.188 ms  4.677 ms  3.945 ms
 3  172.26.64.21 (172.26.64.21)  179.831 ms  180.282 ms  181.633 ms
 4  172.24.0.13 (172.24.0.13)  182.433 ms  182.585 ms  179.870 ms
 5  172.24.0.9 (172.24.0.9)  180.654 ms  183.023 ms  180.876 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *

И:

ping 165.72.192.16
PING 165.72.192.16 (165.72.192.16) 56(84) bytes of data.
64 bytes from 165.72.192.16: icmp_seq=1 ttl=240 time=356 ms
64 bytes from 165.72.192.16: icmp_seq=2 ttl=240 time=325 ms
64 bytes from 165.72.192.16: icmp_seq=3 ttl=240 time=291 ms
64 bytes from 165.72.192.16: icmp_seq=4 ttl=240 time=260 ms

traceroute -U -p 53 199.40.254.166
traceroute to 199.40.254.166 (199.40.254.166), 30 hops max, 60 byte packets
 1  192.168.17.10 (192.168.17.10)  0.710 ms  0.683 ms  0.764 ms
 2  168.243.205.74 (168.243.205.74)  3.136 ms  3.875 ms  4.191 ms
 3  172.26.64.21 (172.26.64.21)  19.367 ms  18.988 ms  19.698 ms
 4  172.24.0.177 (172.24.0.177)  4.657 ms  6.608 ms  7.088 ms
 5  172.24.0.9 (172.24.0.9)  5.126 ms  7.412 ms  5.518 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *

ping 199.40.254.166
PING 199.40.254.166 (199.40.254.166) 56(84) bytes of data.
64 bytes from 199.40.254.166: icmp_seq=1 ttl=237 time=287 ms
64 bytes from 199.40.254.166: icmp_seq=2 ttl=237 time=280 ms
64 bytes from 199.40.254.166: icmp_seq=3 ttl=237 time=286 ms

ОБНОВЛЕНИЕ - 5 декабря 2014 г.

Ну, я установил привязку на другом сервере в той же подсети, той же версии ОС и той же версии привязки, и она работает нормально !!!, единственное, что меняется, - это IP-адрес, и я не могу изменить его для проверки, потому что сервер с проблемой находится в производстве ... поэтому я думаю, что теория IDS, которую считает Эндрю, верна ... Я поговорю с нашим интернет-провайдером и исследую наш внешний IP-адрес, если он внесен в черный список, и опубликую, как это происходит ...

ОБНОВЛЕНИЕ - 6 декабря 2014 г.

IP-адрес сервера не указан ни в одном черном списке, который я проверял в Интернете ...

Перезапустите свой dig +trace с +additional флаг. Я ожидаю, что это все равно не удастся, но я объясню, что происходит.

  • +trace с участием +additional отобразит клей для сервера имен (ДОПОЛНИТЕЛЬНЫЙ раздел), который, по крайней мере, скажет вам, что серверы имен TLD правильно возвращают IP-адрес ns4.dhl.com.
  • В couldn't get address for 'ns4.dhl.com': no more сбой исходит от вашего локального сервера имен. Это непонятная деталь, но dig + trace не использует данные из раздела ДОПОЛНИТЕЛЬНО для определения IP-адреса сервера имён "следующего перехода". Фактически он запрашивает ваш сервер имен в /etc/resolv.conf, чтобы получить IP-адрес ns4.dhl.com, и этот запрос не выполняется.

Судя по результатам команд dig, которые вы запускали в комментариях, похоже, возникла проблема с обменом данными с серверами имен DHL на порту 53. Трассировка на основе UDP на порту 53 (traceroute -U -p 53) даст вам лучшее представление о том, где теряется пакет. Это либо устройство в вашей сети, либо DHL теряет запрос / ответ. В последнем случае IP-адрес вашего сервера имен мог каким-то образом попасть в базу данных репутации устройства IDS.

Вы проверили, что ваш брандмауэр не блокирует порт 53? TCP - Мне кажется, что зона dhl.com подписана и поэтому довольно велика - для больших запросов DNS возвращается с UDP на TCP, и это может объяснить вашу проблему.

иногда ничего не регистрируется, потому что запрос невозможен. Эта ошибка появляется, например, когда отключена функция allow-recursion {} или другое значение, необходимое для запросов. Проверьте свой файл named.conf

Я прокомментировал эту строку в своей конф:

query-source address * port 53;

Тогда я просто собирался настроить функцию ведения журнала, но я еще раз попытался выполнить nslookup в одном из проблемных доменов. На этот раз это сработало. Я не знаю, как и почему, но, вероятно, это как-то связано с портом адреса источника запроса. Я пошел на второй DNS-сервер, где эта строка еще не была прокомментирована, попытался выполнить nslookup в том же домене, и это не удалось. На данный момент убрал строчку, все снова стало нормально работать. Ты хоть представляешь, почему и как это работает?