https://git.altlinux.org/gears/s/..git?p=samba-winbind-dnsupdate.git;a=blob;f=winbind-dnsupdate;hb=0.7.1-alt1

На строках 585 и 608 глючные функции; они при наличии нескольких адресов на интерфейсе дампят их все через LF. А потом validate_ipv{4,6} ничего по факту не валидируют.

Далее рекомендации тем, кто будет фиксить:
1) Не надо парсить обычный вывод `ip(8)`. Легко ошибиться, легко словить регрессию. Варианты:
  * ip -br a ...
  * ip -j a ...
Если возьмёте последний, лучше покройте его тестами своими; апстрим iproute2 системно таким не занимается, там бывают регрессии и не все команды умеют выдавать json-данные. Апстрим будет рад, конечно, увидеть патчи.
2) Не надо регулярками парсить текстовое представление адреса, это смерть. IPv6 в этом плане, кстати, проще, чем IPv4. Нужно применить алгоритм inet_pton(3), что на шелле нелегко. Правда, поговорить с ядром по RTNL и получить оттуда адреса в бинарном network byte order виде ещё сложнее.
3) Не надо хавать какие попало адреса.
Понятно, что ряд адресов выпадают из множ-ва тех, которые имеет смысл регистрировать в домене. Этот ряд — подмножество вот этих двух списков:
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
* Локалхост (::1/128, 127.0.0.0/8)
* IPv4-mapped IPv6 (::ffff:0:0/96)
* Link-local (fe80::/10, 169.254.0.0/16)
* 6to4 (2002::/16)
* ...
Вот это и нужно валидировать. IPv4-mapped и link-local надо обязательно отрывать. Скрыть link-local можно, передав ip(8) фильтр `scope global`.

Кроме того, для IPv6 нужна политика, какие адреса предпочтительно там регистрировать, здесь нужен экспертный совет по домен-решению. Primary/non-temporary или secondary/temporary? Если temporary, то надо брать valid и preferred lifetime в рассмотрение (подозреваю, что и для IPv4 DHCP-клиент их выставляет). В любом случае надо протухшие адреса убирать.
Вот так выглядит результат в неплохом приближении:
  # ip -br -f $family addr show scope global -tentative -deprecated
Но тут всё равно адресов может оказаться несколько, PTR для них всех нужно прописывать. Что приводит нас к пункту 4...

4) Не должна ли эта программа быть даймоном и реагировать на события, например, от `ip monitor`? Адрес появился (add), у адреса изменились флаги либо другое состояние (он по-change-ился), адрес пропал (delete).
Или не быть даймоном, а запускаться этим даймоном по событию (fork-exec на событие, конечно, но хоть что-то).

Может быть, уже так и есть, а я не в курсе; тогда хорошо.

(Ответ для Arseny Maslennikov на комментарий #3)
> 4) Не должна ли эта программа быть даймоном и реагировать на события,
> например, от `ip monitor`? Адрес появился (add), у адреса изменились флаги
> либо другое состояние (он по-change-ился), адрес пропал (delete).
> Или не быть даймоном, а запускаться этим даймоном по событию (fork-exec на
> событие, конечно, но хоть что-то).
> 
> Может быть, уже так и есть, а я не в курсе; тогда хорошо.

В samba-winbind-dnsupdate-0.7.1-alt1.noarch есть .service и .timer:

/usr/lib/systemd/system/winbind-dnsupdate.service
/usr/lib/systemd/system/winbind-dnsupdate.timer


# /usr/lib/systemd/system/winbind-dnsupdate.service
[Unit]
Description=Update dns record service
After=network.target network-online.target

[Service]
Type=oneshot
EnvironmentFile=-/etc/sysconfig/winbind-dnsupdate
ExecStart=/usr/bin/winbind-dnsupdate $OPTIONS

[Install]
WantedBy=multi-user.targe


# /usr/lib/systemd/system/winbind-dnsupdate.timer
[Unit]
Description=Update dns record Daily and on boot

[Timer]
OnBootSec=5min
OnUnitActiveSec=60min

[Install]
WantedBy=timers.target

(In reply to Artem Varaksa from comment #4)
> (Ответ для Arseny Maslennikov на комментарий #3)
> > 4) Не должна ли эта программа быть даймоном и реагировать на события,
> > например, от `ip monitor`? Адрес появился (add), у адреса изменились флаги
> > либо другое состояние (он по-change-ился), адрес пропал (delete).
> > Или не быть даймоном, а запускаться этим даймоном по событию (fork-exec на
> > событие, конечно, но хоть что-то).
> > 
> > Может быть, уже так и есть, а я не в курсе; тогда хорошо.
> 
> В samba-winbind-dnsupdate-0.7.1-alt1.noarch есть .service и .timer:
> 
> /usr/lib/systemd/system/winbind-dnsupdate.service
> /usr/lib/systemd/system/winbind-dnsupdate.timer
Благодарю за инфо. :)

> # /usr/lib/systemd/system/winbind-dnsupdate.service
> <...>
> 
> # /usr/lib/systemd/system/winbind-dnsupdate.timer
> [Unit]
> Description=Update dns record Daily and on boot
> 
> [Timer]
> OnBootSec=5min
> OnUnitActiveSec=60min
> 
> [Install]
> WantedBy=timers.target
Обновление раз в 60 минут — это, если честно, паллиатив. Оно должно срабатывать по событию изменения множества адресов на интерфейсе (и у главного конкурента, чудаков на букву М, именно так), потому что такое изменение — это преждевременно протухшие записи.

Но просто изменить в таймере промежуток или привязать её к выхлопу `ip monitor addr` — тоже не то, потому что:
— программа, видимо, при работе ещё и выясняет, где сервер, на который слать nsupdate; это несколько DNS-запросов с зависимостью по данным;
— из-за этого слишком часто (в случае флапа адресов на интерфейсе, последовательности мгновенных появлений-пропаданий) её дёргать нельзя, нужен grace period, я бы предложил сделать его сравнимым с neighbour reachability timer, по умолчанию 1,5 секунды.
https://datatracker.ietf.org/doc/html/rfc4861#section-6.3.2, "ReachableTime"

Воспроизвёл на своём стенде эту ошибку:
https://altlinux.space/alt-domain/samba-winbind-dnsupdate/issues/6