33300 2017-03-29 20:55:59 +0300 bind перестаёт работать с интерфейсом после ifup/ifdown 2025-08-25 16:13:36 +0300 1 1 4 Development Sisyphus bind unstable all Linux CLOSED FIXED https://bugzilla.altlinux.org/show_bug.cgi?id=43042 P3 normal --- 1 rider placeholder aen asy evg george glebfm jenya ldv mike placeholder rider sbolshakov sem slev vt qa-sisyphus oldest_to_newest 162817 0 rider 2017-03-29 20:55:59 +0300 Имеем: bind-9.10.4-alt2 пачку vpn туннелей в разные стороны (openvpn). форвардинг запросов dns через vpn туннели к другим named серверам. Проблемы: bind перестаёт отправлять forward запросы на другой сервер, если интерфейс VPN переинициализируется по каким-то причинам (аналог ifdown && ifup) после перезапуска bind снова начинает работать нормально. Явно это из-за сброса capability. Меня бы устроила ручка по отключению такого поведения, ну или какое-то исправление, которое позволило бы bind садиться на те интерфейсы, которые появились после его запуска. Аналогичная проблема с dhcp, но там не vpn а vlan'ы - после ifdown/ifup на интерфейсе приходится перезапускать dhcp сервер. 162830 1 asy 2017-03-30 11:24:34 +0300 interface-interval не эта ли ручка ? 162831 2 asy 2017-03-30 11:29:30 +0300 Кстати, а почему бы не добавить IP на lo и повесить BIND на этот адрес ? И всё делать с этим src ip. 162832 3 rider 2017-03-30 11:39:25 +0300 interface-interval у нас не работает - bind не биндится на порт с диагностикой permission denied: Mar 30 11:36:04 xxxxxxx named[20586]: listening on IPv4 interface vpn1, 172.22.0.1#53 Mar 30 11:36:04 xxxxxxx named[20586]: could not listen on UDP socket: permission denied Mar 30 11:36:04 xxxxxxx named[20586]: creating IPv4 interface vpn1 failed; interface ignored Можно, наверное, решить это через lo0 и маршруты, но ошибка не о том, какой костыль придумать для того, что бы обойти неработающий в нашей сборке функционал. 163072 4 rider 2017-04-07 15:30:22 +0300 PING. Сегодня опять нарвался, правда на dhcpd, который теряет интерфейс после ifdown/ifup Мне собирать ещё один bind+libbind в Sisyphus ? 163074 5 ldv 2017-04-07 15:42:08 +0300 (In reply to comment #4) > PING. > Сегодня опять нарвался, правда на dhcpd, который теряет интерфейс после > ifdown/ifup > > Мне собирать ещё один bind+libbind в Sisyphus ? А как же ты жил все эти годы? bind утратил эту возможность, когда стал непривилегированным, с версии 8.2.какой-то. 163079 6 sem 2017-04-07 16:41:06 +0300 (In reply to comment #5) > bind утратил эту возможность, когда стал > непривилегированным, с версии 8.2.какой-то. Мне помнится, что когда-то давно по этой причине для Кольчуги делался костыль, перезапускающий bind после ifdown/ifup. 163081 7 asy 2017-04-07 17:41:04 +0300 А мне, на самом деле, непонятен отказ от варианта повесить Bind на дополнительный рабочий адрес на lo. Никакие маршруты не требуются, надо только дописать в ifaces/lo/ipv4address ещё один IP, а-ля 10.1.1.1/32 и раздавать его на клиентские подключения в качестве DNS. default gw ведь на этот же сервер ведёт ? Ну и придёт запрос к этому IP на этот сервер сам собой. 163083 8 rider 2017-04-07 20:45:15 +0300 Чаще всего налетаешь на dhcpd. если с bind ещё можно как-то выкрутиться, то с dhcp всё плохо. Мне кажется, что dhcp сервер раньше так не работал. Но я могу ошибаться. 163084 9 rider 2017-04-07 20:45:54 +0300 (In reply to comment #7) > А мне, на самом деле, непонятен отказ от варианта повесить Bind на > дополнительный рабочий адрес на lo. Никакие маршруты не требуются, надо только > дописать в ifaces/lo/ipv4address ещё один IP, а-ля 10.1.1.1/32 и раздавать его > на клиентские подключения в качестве DNS. default gw ведь на этот же сервер > ведёт ? Ну и придёт запрос к этому IP на этот сервер сам собой. default gw не ведёт на этот сервер. Если б вёл. 163186 10 ldv 2017-04-13 07:50:37 +0300 (In reply to comment #8) > Чаще всего налетаешь на dhcpd. > > если с bind ещё можно как-то выкрутиться, то с dhcp всё плохо. > Мне кажется, что dhcp сервер раньше так не работал. Но я могу ошибаться. dhcp собирается и работает с библиотеками от bind-9.9.9-P5, упакованными в пакет libisc-export-dhcp-devel. 163187 11 rider 2017-04-13 07:54:35 +0300 Открутишь от него сброс привелегий ? 163188 12 ldv 2017-04-13 07:58:45 +0300 (In reply to comment #11) > Открутишь от него сброс привелегий ? Я думаю, что тот код в bind нерелевантен для dhcp. По идее, поведение dhcp не должно было поменяться, потому что бибилиотеки не поменялись. 163189 13 rider 2017-04-13 08:03:55 +0300 релевантность кода можно легко проверить. я допускаю, что помимо обновлений у меня могли поменяться usecase - появились отдельные vlan'ы, которые я стал перезапускать немного чаще обычного. но в любом случае смысл остаётся тот же - DHCP и bind ведут себя одинаково - теряют интерфейс после его рестарта. 164598 14 sbolshakov 2017-07-07 11:51:22 +0300 потерять же интерфейс можно не только его рестартом -- достаточно моргнуть линку, и, если сеть под etcnet+ifplugd или systemd-networkd, то всё, этот bind уже не bind, а так, массогабаритный муляж. нужно это прекратить. 164599 15 rider 2017-07-07 11:53:03 +0300 Дима, можешь добавить опцию, позволяющую отключать подобное поведение у bind ? 164600 16 ldv 2017-07-07 14:00:02 +0300 (In reply to comment #14) > потерять же интерфейс можно не только его рестартом -- достаточно > моргнуть линку, и, если сеть под etcnet+ifplugd или systemd-networkd, то всё, А зачем они это делают? > этот bind уже не bind, а так, массогабаритный муляж. И что, теперь весь сетевой софт должен из-за этого стать привилегированным? > нужно это прекратить. не лучше ли это прекратить там, где это появилось, т.е. на стороне софта, выводящего из строя сетевые интерфейсы? 172802 17 rider 2018-07-20 12:03:28 +0300 ifdown/ifup интерфейс и named/dhcp перестаёт работать неожиданно для администратора. Сегодня опять словили. 172803 18 mike 2018-07-20 12:10:55 +0300 (В ответ на комментарий №14) > если сеть под etcnet+ifplugd или systemd-networkd Э-ээ, а зачем так делать на сервере? Там же работать должно. ifplugd для ноутов пакетил, даже не для десктопов вообще-то. PS: как ещё вариант -- воткнуть рестартилку в подъёмные скрипты, где они там (в ppp это ip-up.d из того, куда недавно заглядывал). 172804 19 rider 2018-07-20 12:19:05 +0300 Миша, сейчас существует как минимум три штатных способа настраивать сеть. Какую рестартилку ? Надо просто добавить в bind опцию, отключающую такое поведение. Для случаев, когда нужно. 172805 20 sbolshakov 2018-07-20 12:20:59 +0300 (In reply to comment #18) > (В ответ на комментарий №14) > > если сеть под etcnet+ifplugd или systemd-networkd > Э-ээ, а зачем так делать на сервере? Там же работать должно. > ifplugd для ноутов пакетил, даже не для десктопов вообще-то. > > PS: как ещё вариант -- воткнуть рестартилку в подъёмные скрипты, > где они там (в ppp это ip-up.d из того, куда недавно заглядывал). Миша, если ты не в курсе, то я поясню: в вашем bind (себе я вынужден пересобирать) некоторые штатные возможности специально оторваны. Изобретать к такому bind парные костыли мне не хочется. 172806 21 ldv 2018-07-20 12:28:28 +0300 Раньше указание "interface-interval 0;" в options решало это проблему - bind переставал "терять" интерфейс. 172810 22 rider 2018-07-20 14:09:05 +0300 Конечно, эта опция не может помочь от рестарта интерфейса Выглядит это так: # ss -u -a -p '( sport = 53 )' State Recv-Q Send-Q Local Address:Port Peer Address:Port UNCONN 0 0 192.168.1.1:domain 0.0.0.0:* users:(("named",pid=5423,fd=520),("named",pid=5423,fd=519),("named",pid=5423,fd=518)) UNCONN 0 0 127.0.0.1:domain 0.0.0.0:* users:(("named",pid=5423,fd=517),("named",pid=5423,fd=516),("named",pid=5423,fd=515)) UNCONN 0 0 [::]:domain [::]:* users:(("named",pid=5423,fd=514),("named",pid=5423,fd=513),("named",pid=5423,fd=512)) # ifdown lan && ifup lan # ss -u -a -p '( sport = 53 )' State Recv-Q Send-Q Local Address:Port Peer Address:Port UNCONN 0 0 127.0.0.1:domain 0.0.0.0:* users:(("named",pid=5423,fd=517),("named",pid=5423,fd=516),("named",pid=5423,fd=515)) UNCONN 0 0 [::]:domain [::]:* users:(("named",pid=5423,fd=514),("named",pid=5423,fd=513),("named",pid=5423,fd=512)) # /etc/init.d/bind restart Stopping named service: [ DONE ] Checking named configuration file syntax: [ DONE ] Starting named service: [ DONE ] # ss -u -a -p '( sport = 53 )' State Recv-Q Send-Q Local Address:Port Peer Address:Port UNCONN 0 0 192.168.1.1:domain 0.0.0.0:* users:(("named",pid=5711,fd=520),("named",pid=5711,fd=519),("named",pid=5711,fd=518)) UNCONN 0 0 127.0.0.1:domain 0.0.0.0:* users:(("named",pid=5711,fd=517),("named",pid=5711,fd=516),("named",pid=5711,fd=515)) UNCONN 0 0 [::]:domain [::]:* users:(("named",pid=5711,fd=514),("named",pid=5711,fd=513),("named",pid=5711,fd=512)) 175749 23 rider 2018-11-13 19:02:28 +0300 Я снова поймал эту ошибку неприятным образом (перестаёт работать DNS сам по себе после отваливанивания vpn интерфейса, на котором висит bind). Ты планируешь её как-то исправить? 184853 24 rider 2019-10-10 09:51:06 +0300 И я опять словил эту же проблему но уже на p9. Предлагаю ещё раз посмотреть на код, который реализует такое поведение. 184854 25 asy 2019-10-10 10:51:19 +0300 (In reply to comment #16) > > нужно это прекратить. > > не лучше ли это прекратить там, где это появилось, т.е. на стороне софта, > выводящего из строя сетевые интерфейсы? Тут есть такой момент, что с упавшего интерфейса могут убираться разные штуки, например статические маршруты через него. И это ожидаемое поведение для тех, кто привых к железным маршрутизаторам. То есть, при пропадании линка интерфейс должен как-то среагировать, и это нормально. Но должно ли так себя прикладное ПО вести - вопрос открытый... 184859 26 rider 2019-10-10 11:40:56 +0300 Ну смотри, если пофилосовствовать, то например - у нас есть какая-то прикладная программа, которая использует к примеру СУБД. Она присоединилась к этой СУБД и эксплуатирует данное соединение всегда для своей работы. Перезапуск СУБД ведёт к разрыву этого соединения. Прикладная программа должна корректно отрабатывать такую ситуацию и либо падать (в связи с тем, что функций своих она выполнять не может) либо просто делать reconnect. СУБД в данном контексте - это сетевой интерфейс, а прикладная программа - bind. Мы запустили named, он сел на интерфейс, на котором он нам нужен. Далее мы этот интерфейс перезапустили. named остался работать, хотя своих функций так как ожидает от него администратор - он уже не выполняет. Тут ещё накладывается то, что такая фича есть только у нас и больше ни у кого. 184873 27 slev 2019-10-10 20:04:38 +0300 Проблема из-за сброса CAP_NET_BIND_SERVICE. Альтовый сброс привилегий отличается от варианта апстрима. Если в апстриме сброс до рабочего состояния(ruid, euid,suid: named; caps: net_bind_service, sys_resource +) происходит еще до загрузки конфигурации BIND'а. То у нас это проходит в два этапа: 1) до загрузки конфигурации происходит сброс (ruid, euid, suid: named, named, 0; caps: net_bind_service, sys_resource +) 2) во время загрузки конфигурации (ruid, euid, suid: named, named, named; caps: ) Еще два немаловажных отличия заключаются в том, что апстрим не дропает флаг SECBIT_KEEP_CAPS и capability bounding set. Пункт два происходит чуть-чуть(несколько долей секунды) позже запуска потока плагина bind-dyndb-ldap. Отсюда возникает рэйс, так как RT сигнал, сгенерированный setresuid из основного потока BIND, рвет соединение плагина с доменным сокетом LDAP. Но это решаемо в самом плагине. А вот дроп (по моему мнению) CAP_NET_BIND_SERVICE можно отключить. Если Дмитрий не возражает, то я мог бы подготовить патч на патч. Хотелось бы узнать мнение, чтобы не тратить время впустую. 184878 28 ldv 2019-10-10 21:47:33 +0300 (In reply to comment #27) > А вот дроп (по моему мнению) CAP_NET_BIND_SERVICE можно отключить. Если Дмитрий > не возражает, то я мог бы подготовить патч на патч. Тут всё обсуждение ровно о том, что мне нужно, чтобы никаких CAP'ов у работающего bind'а не было, Антон хочет, чтобы у него bind работал с CAP_NET_BIND_SERVICE, и удовлетворить эти противоположные желания одним и тем же bind'ом пока не получается. 184880 29 rider 2019-10-10 22:32:28 +0300 Мне кажется, что в каком-то из обсуждений мы сошлись на том, что должна быть опция -#, включающая нужное тебе поведение. Мы можем Стаса попросить это реализовать. 190596 30 slev 2020-06-08 12:46:58 +0300 Ручка для BIND добавлена: http://git.altlinux.org/tasks/archive/done/_246/252433/logs/events.5.1.log 209429 31 asy 2022-04-13 09:23:40 +0300 (In reply to Stanislav Levin from comment #30) > Ручка для BIND добавлена: > http://git.altlinux.org/tasks/archive/done/_246/252433/logs/events.5.1.log Наверное надо было в changelog про этот баг добавить, а то за версией в задание лезть надо. * Fri May 29 2020 Stanislav Levin <slev@altlinux> 9.11.19-alt3 - Placed Linux capabilities dropping under control(1). 209444 32 asy 2022-04-13 11:01:38 +0300 (In reply to Sergey Y. Afonin from comment #31) > * Fri May 29 2020 Stanislav Levin <slev@altlinux> 9.11.19-alt3 > - Placed Linux capabilities dropping under control(1). Описано и добавляется в /etc/sysconfig/bind