LINUX.ORG.RU
ФорумAdmin

Очень плохо работает Bind9 на Debian 9.7

 , , , ,


0

1

Есть работающий как кэширующий DNS Bind 9 на Debian 5.0. Перенёс эту конфигурацию (перетащил конфиги) на новый сервер на Debian 9.7. Поставилась версия BIND 9.10.3-P4-Debian DNS очень странно работает. То резолвит за пару милисекунд всё, то тупит по секунд 20 и иногда вообще выкидывает ошибку в стиле - Your request could not be processed because an error occurred contacting the DNS server. The DNS server may be temporarily unavailable, or there could be a network problem. когда с браузера лезешь через него куда то.

На данный момент конфиг такой -

options {
	directory "/var/cache/bind";

allow-query {127.0.0.1/8; 192.168.0.0/16; 10.0.0.0/8; 172.16.0.0/12; 91.194.64.0/23; };
// allow-query-cache { any; }
allow-recursion {127.0.0.1/8; 192.168.0.0/16; 10.0.0.0/8; 172.16.0.0/12; 91.194.64.0/23; };
allow-transfer { 212.5.66.14; 212.15.127.1; 195.128.64.3; 212.5.64.43; };
forward first;
forwarders { 212.5.66.14; 195.128.64.3; 212.5.64.43; 212.15.127.1; 212.15.122.253; };
//forwarders { 8.8.8.8; 8.8.4.4; };


fetch-glue no;
query-source address * port 53;


	auth-nxdomain no;    # conform to RFC1035
	listen-on-v6 { none; };
// allow-notimy {none;};
};

в resolv.conf стоит 127.0.0.1

Вот что ещё выдаёт проверка на https://dnsflagday.net/ : Serious problem detected!

dns=timeout edns=timeout edns1=timeout edns@512=timeout ednsopt=timeout edns1opt=timeout do=timeout ednsflags=timeout docookie=timeout edns512tcp=refused optlist=timeout

Warning: test failures may indicate that some DNS clients cannot resolve the zone or will get a unintended answer or resolution will be slower than necessary.



Последнее исправление: postfix81 (всего исправлений: 1)
Ответ на: комментарий от Turbid

1. Не очень понял о чём речь. Что за code. 2. Логи отдельно вывел. Да прямо так ошибками особо не сыпет. Вот кусочек -

30-Jan-2019 10:16:34.369 client: debug 3: client 212.15.127.1#53: UDP request 30-Jan-2019 10:16:34.369 client: debug 3: client 212.15.127.1#53: next 30-Jan-2019 10:16:34.369 client: debug 3: client 212.15.127.1#53: endrequest 30-Jan-2019 10:16:34.369 client: debug 3: client @0x7f63ac7ac4e0: udprecv 30-Jan-2019 10:16:34.369 lame-servers: info: REFUSED unexpected RCODE resolving 'http://www.rbc.ru/A/IN': 212.15.127.1#53 30-Jan-2019 10:16:34.371 client: debug 3: client 212.5.64.43#53: UDP request 30-Jan-2019 10:16:34.371 client: debug 3: client 212.5.64.43#53: next 30-Jan-2019 10:16:34.371 client: debug 3: client 212.5.64.43#53: endrequest 30-Jan-2019 10:16:34.371 client: debug 3: client @0x7f63ac7ac4e0: udprecv 30-Jan-2019 10:16:34.371 client: debug 3: client 192.168.70.4#59503 (http://www.rbc.ru): send 30-Jan-2019 10:16:34.371 client: debug 3: client 192.168.70.4#59503 (http://www.rbc.ru): sendto 30-Jan-2019 10:16:34.371 client: debug 3: client 192.168.70.4#59503 (http://www.rbc.ru): senddone 30-Jan-2019 10:16:34.372 client: debug 3: client 192.168.70.4#59503 (http://www.rbc.ru): next 30-Jan-2019 10:16:34.372 client: debug 3: client 192.168.70.4#59503 (http://www.rbc.ru): endrequest 30-Jan-2019 10:16:34.373 client: debug 3: client 192.168.70.4#59593: UDP request 30-Jan-2019 10:16:34.373 client: debug 3: client 192.168.70.4#59593: query 30-Jan-2019 10:16:34.373 client: debug 3: client 192.168.70.4#59593 (pics.rbc.ru): replace 30-Jan-2019 10:16:34.373 general: debug 3: clientmgr @0x7f63bae74458: get client 30-Jan-2019 10:16:34.373 general: debug 3: clientmgr @0x7f63bae74458: recycle 30-Jan-2019 10:16:34.373 resolver: debug 1: fetch: pics.rbc.ru/A

postfix81
() автор топика
Ответ на: комментарий от postfix81

Не очень понял о чём речь. Что за code

Никто тут твои неформатированные портянки разбирать не будет. Удачи.

Turbid ★★★★★
()
Ответ на: комментарий от Turbid
30-Jan-2019 10:16:34.369 client: debug 3: client 212.15.127.1#53: UDP request
30-Jan-2019 10:16:34.369 client: debug 3: client 212.15.127.1#53: next
30-Jan-2019 10:16:34.369 client: debug 3: client 212.15.127.1#53: endrequest
30-Jan-2019 10:16:34.369 client: debug 3: client @0x7f63ac7ac4e0: udprecv
30-Jan-2019 10:16:34.369 lame-servers: info: REFUSED unexpected RCODE resolving 'www.rbc.ru/A/IN': 212.15.127.1#53
30-Jan-2019 10:16:34.371 client: debug 3: client 212.5.64.43#53: UDP request
30-Jan-2019 10:16:34.371 client: debug 3: client 212.5.64.43#53: next
30-Jan-2019 10:16:34.371 client: debug 3: client 212.5.64.43#53: endrequest
30-Jan-2019 10:16:34.371 client: debug 3: client @0x7f63ac7ac4e0: udprecv
30-Jan-2019 10:16:34.371 client: debug 3: client 192.168.70.4#59503 (www.rbc.ru): send
30-Jan-2019 10:16:34.371 client: debug 3: client 192.168.70.4#59503 (www.rbc.ru): sendto
30-Jan-2019 10:16:34.371 client: debug 3: client 192.168.70.4#59503 (www.rbc.ru): senddone
30-Jan-2019 10:16:34.372 client: debug 3: client 192.168.70.4#59503 (www.rbc.ru): next
30-Jan-2019 10:16:34.372 client: debug 3: client 192.168.70.4#59503 (www.rbc.ru): endrequest
30-Jan-2019 10:16:34.373 client: debug 3: client 192.168.70.4#59593: UDP request
30-Jan-2019 10:16:34.373 client: debug 3: client 192.168.70.4#59593: query
30-Jan-2019 10:16:34.373 client: debug 3: client 192.168.70.4#59593 (pics.rbc.ru): replace
30-Jan-2019 10:16:34.373 general: debug 3: clientmgr @0x7f63bae74458: get client
30-Jan-2019 10:16:34.373 general: debug 3: clientmgr @0x7f63bae74458: recycle
30-Jan-2019 10:16:34.373 resolver: debug 1: fetch: pics.rbc.ru/A

postfix81
() автор топика

А как к твоему DNS мир будет обращаться, если у тебя allow-query ограничен? Это у тебя какой-то локальный DNS. Остальное ограничивать можно (да и нужно). Или он у тебя свои публичные зоны не держит? А зачем проверяешь снаружи тогда?

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 2)
Ответ на: комментарий от AS

я вижу кусочек ответа от dnsflagday.net. Это вообще может быть другой ип. Они просто опрашивают nsы зоны. По факту один ns зафильтрован, bind-9.10 с дефолтным конфигом и открытыми портами должен все тесты отработать.

anonymous
()
Ответ на: комментарий от AS

так-то да. Его allow-query вообще закрывают сервер снаружи -)

anonymous
()
Ответ на: комментарий от anonymous

Ну это скорее не снаружи а внутри. Это локальный кэширующий DNS внутри организации. Вот если с другой машины сделать:


 dig aviasales.ru @192.168.77.30

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> aviasales.ru @192.168.77.30
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6245
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 11

;; QUESTION SECTION:
;aviasales.ru.                  IN      A

;; ANSWER SECTION:
aviasales.ru.           299     IN      A       185.106.81.236
aviasales.ru.           299     IN      A       188.42.198.44

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

;; ADDITIONAL SECTION:
a.root-servers.net.     533682  IN      A       198.41.0.4
a.root-servers.net.     516653  IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     98712   IN      A       199.9.14.201
b.root-servers.net.     98712   IN      AAAA    2001:500:200::b
c.root-servers.net.     504286  IN      A       192.33.4.12
c.root-servers.net.     529599  IN      AAAA    2001:500:2::c
d.root-servers.net.     104842  IN      A       199.7.91.13
d.root-servers.net.     336751  IN      AAAA    2001:500:2d::d
e.root-servers.net.     93854   IN      A       192.203.230.10
e.root-servers.net.     117141  IN      AAAA    2001:500:a8::e
f.root-servers.net.     28225   IN      A       192.5.5.241

;; Query time: 1213 msec
;; SERVER: 192.168.87.30#53(192.168.77.30)
;; WHEN: Wed Jan 30 13:28:19 2019
;; MSG SIZE  rcvd: 509

Вот что в tcpdump:

)
13:28:19.087792 IP (tos 0x0, ttl 64, id 50687, offset 0, flags [none], proto UDP                                                                                                                                (17), length 537)
    192.168.77.30.domain > relay.51540: [udp sum ok] 6245 q: A? aviasales.ru. 2                                                                                                                               /13/11 aviasales.ru. A 185.106.81.236, aviasales.ru. A 188.42.198.44 ns: . NS i.                                                                                                                               root-servers.net., . NS f.root-servers.net., . NS c.root-servers.net., . NS k.ro                                                                                                                               ot-servers.net., . NS a.root-servers.net., . NS d.root-servers.net., . NS j.root                                                                                                                               -servers.net., . NS h.root-servers.net., . NS e.root-servers.net., . NS m.root-s                                                                                                                               ervers.net., . NS l.root-servers.net., . NS b.root-servers.net., . NS g.root-ser                                                                                                                               vers.net. ar: a.root-servers.net. A 198.41.0.4, a.root-servers.net. AAAA 2001:50                                                                                                                               3:ba3e::2:30, b.root-servers.net. A 199.9.14.201, b.root-servers.net. AAAA 2001:                                                                                                                               500:200::b, c.root-servers.net. A 192.33.4.12, c.root-servers.net. AAAA 2001:500                                                                                                                               :2::c, d.root-servers.net. A 199.7.91.13, d.root-servers.net. AAAA 2001:500:2d::                                                                                                                               d, e.root-servers.net. A 192.203.230.10, e.root-servers.net. AAAA 2001:500:a8::e                                                                                                                               , f.root-servers.net. A 192.5.5.241 (509)
13:29:06.789703 IP (tos 0x0, ttl 64, id 53935, offset 0, flags [none], proto UDP                                                                                                                                (17), length 55)
    relay.45495 > 192.168.87.70.domain: [udp sum ok] 18541+ A? toster.ru. (27)
13:29:06.795080 IP (tos 0x0, ttl 64, id 62241, offset 0, flags [none], proto UDP                                                                                                                                (17), length 518)


postfix81
() автор топика
Ответ на: комментарий от AS

Это локальный кэширующий DNS внутри организации.Т.е. изнутри используется. Да он ещё публичные зоны держит и отдаёт их, но это отдельно в других файликах настроено. Более того - вот этот конфиг что выше работал отлично несколько лет на Debian 5. Тоже самое запихнутое на Debian 9.7 в более новый Bind9 даёт такой результат.

postfix81
() автор топика
Ответ на: комментарий от AS

По поводу «А зачем проверяешь снаружи тогда?» извиняюсь, с терминологией попутал - из внутренней подсети проверяем, конечно

postfix81
() автор топика
Ответ на: комментарий от postfix81

из внутренней подсети проверяем, конечно

А при чём тут тогда «Вот что ещё выдаёт проверка на https://dnsflagday.net/ » ?

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от postfix81

Да он ещё публичные зоны держит и отдаёт их, но это отдельно в других файликах настроено

То есть, там allow-query переопределяется? В принципе вариант.

Вот ещё что. «query-source address * port 53;» лучше убрать. Для ip это бывает нужно, но вот указывать порт сейчас не очень модно: считается несекьюрно. Может и правильно.

AS ★★★★★
()
Ответ на: комментарий от anonymous

А ещё вот что интересно. С одинаковыми настройками сейчас два эти сервера.И вот что интересно. Тот. что на Debian 5.0, который рабочий, например вот так выдаёт:

# dig @192.168.77.5 500px.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @192.168.87.5 500px.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52916
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 2

;; QUESTION SECTION:
;500px.com.                     IN      A

;; ANSWER SECTION:
500px.com.              54      IN      A       198.50.208.98

;; AUTHORITY SECTION:
500px.com.              172800  IN      NS      ns-1537.awsdns-00.co.uk.
500px.com.              172800  IN      NS      ns-46.awsdns-05.com.
500px.com.              172800  IN      NS      ns-1489.awsdns-58.org.
500px.com.              172800  IN      NS      ns-557.awsdns-05.net.

;; ADDITIONAL SECTION:
ns-1537.awsdns-00.co.uk. 6684   IN      A       205.251.198.1
ns-1537.awsdns-00.co.uk. 18862  IN      AAAA    2600:9000:5306:100::1

;; Query time: 3053 msec
;; SERVER: 192.168.77.5#53(192.168.77.5)
;; WHEN: Wed Jan 30 16:06:53 2019
;; MSG SIZE  rcvd: 223

А тот, что новый с этими же конфигами, который криво работает, выдаёт вот так. Зачем то с корневыми сертификатами на такую же комманду:

# dig @192.168.77.30 500px.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @192.168.77.30 500px.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21790
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 11

;; QUESTION SECTION:
;500px.com.                     IN      A

;; ANSWER SECTION:
500px.com.              59      IN      A       198.50.208.98

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

;; ADDITIONAL SECTION:
a.root-servers.net.     1778    IN      A       198.41.0.4
a.root-servers.net.     1778    IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     1778    IN      A       199.9.14.201
b.root-servers.net.     1778    IN      AAAA    2001:500:200::b
c.root-servers.net.     1778    IN      A       192.33.4.12
c.root-servers.net.     1778    IN      AAAA    2001:500:2::c
d.root-servers.net.     1778    IN      A       199.7.91.13
d.root-servers.net.     1778    IN      AAAA    2001:500:2d::d
e.root-servers.net.     1778    IN      A       192.203.230.10
e.root-servers.net.     1778    IN      AAAA    2001:500:a8::e
f.root-servers.net.     1778    IN      A       192.5.5.241

;; Query time: 1208 msec
;; SERVER: 192.168.77.30#53(192.168.77.30)
;; WHEN: Wed Jan 30 16:04:53 2019
;; MSG SIZE  rcvd: 490


postfix81
() автор топика
Ответ на: комментарий от anonymous

Спасибо, погуглил уже эту тему. Не очень помогло. Вот нашёл похожую тему по этой секции -

bind9 - возврат Authority Section

Сделал как там - частично помогло, но по сути в боле половины запросов всё равно там корневые сертификаты.

postfix81
() автор топика
Ответ на: комментарий от postfix81

Не знал.

А ты читать пробовал что на экране написано в частности в форме помещения сообщения? И в особенности думать зачем там есть кнопка «Предпосмотр».

В форме помещения сообщения на форум есть такой текст:
Внимание: прочитайте описание разметки LORCODE
«Поместить» «Предпросмотр» «Отмена».

Вот открой ссылку и почитай.

anonymous
()
Ответ на: комментарий от anonymous

Зачем флудить? Мне сделали замечание - я всё поправил уже давно (что можно было).

postfix81
() автор топика
Ответ на: комментарий от anonymous

Кстати сейчас вроде бы более менее заработало всё. Но вот снаружи dnsflagday.net на наш сайт первой строчкой выдаёт вот это -

dns=refused edns=refused edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused docookie=refused edns512tcp=refused optlist=refused

Что тут не так и как исправить?

postfix81
() автор топика
Ответ на: комментарий от AS

Да не понятно. Вот опять работал нормально. Всё открывалось.dnsflagday.net выдаёт - Minor problems detected! This domain is going to work after February 1st 2019.

Там первой строчкой - dns=refused edns=refused edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused docookie=refused edns512tcp=refused optlist=refused

Позже через полчасика примерно вдруг перестаёт пару минут ресолвить некоторые сайты. Приходится по ф5 перегружать - захожу и dnsflagday.net выдаёт -

Serious problem detected! и там: dns=timeout edns=timeout edns1=timeout edns@512=timeout ednsopt=timeout edns1opt=timeout do=timeout ednsflags=timeout docookie=timeout edns512tcp=refused optlist=timeout

postfix81
() автор топика
Ответ на: комментарий от postfix81

К сожалению пока что ничего не изменилось(

Не знаю, что сказать. Вроде больше не вижу ничего. А у меня 9.10.6 сейчас стоит много где и в разных ипостасях, в том числе некоторые и зоны держат, вроде всё работает.

AS ★★★★★
()
Ответ на: комментарий от postfix81

как минимум bind97 9.7 из rhel5 отрабатывает все нормально. версия bind тут не при чем.

anonymous
()
Ответ на: комментарий от postfix81

Гм... 9.10.6? У меня на stable Debian

Ну у меня традиционно не Debian. :-) Про 9.10.3 не помню, был ли, и как долго.

AS ★★★★★
()
Ответ на: комментарий от AS

Ну вот не знаю что у меня с ним. Работает раза в 2 медленнее, чем до этого старый бинд на debian 5 :(

postfix81
() автор топика
Ответ на: комментарий от AS

Ну вот опять... Работало всё всё хорошо и вдруг разом сайты не резолвятся. С одной из машин внутри сети делаю запрос и там так -

dig @192.168.77.5 rambler.ru

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @192.168.77.5 rambler.ru ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached

и всё... повторяю запрос через пару минут -

dig @192.168.87.5 rambler.ru

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @192.168.77.5 rambler.ru ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53507 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 6

;; QUESTION SECTION: ;rambler.ru. IN A

;; ANSWER SECTION: rambler.ru. 300 IN A 81.19.82.9 rambler.ru. 300 IN A 81.19.82.10 rambler.ru. 300 IN A 81.19.82.11 rambler.ru. 300 IN A 81.19.82.8

;; AUTHORITY SECTION: rambler.ru. 1090 IN NS ns2.rambler.ru. rambler.ru. 1090 IN NS ns5.rambler.ru. rambler.ru. 1090 IN NS ns4.rambler.ru. rambler.ru. 1090 IN NS ns3.rambler.ru.

;; ADDITIONAL SECTION: ns2.rambler.ru. 3344 IN A 81.19.73.8 ns2.rambler.ru. 1649 IN AAAA 2a02:6b0:6:2::1:53 ns3.rambler.ru. 337 IN A 81.19.83.8 ns4.rambler.ru. 3079 IN A 81.19.73.9 ns4.rambler.ru. 3040 IN AAAA 2a02:6b0:6:2::2:53 ns5.rambler.ru. 337 IN A 81.19.83.9

;; Query time: 13 msec ;; SERVER: 192.168.77.5#53(192.168.87.5) ;; WHEN: Tue Feb 5 14:04:31 2019 ;; MSG SIZE rcvd: 284

и такие провалы постоянно. Не понимаю где ещё посмотреть. Что это и как лечить.

postfix81
() автор топика
Ответ на: комментарий от postfix81

Соберите дамп трафика, посмотрите, что происходит во время таймаутов.

ValdikSS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.