Thanks Simon & Paride.
That is reassuring to know that BIND will retry. Based on that I'm happy
for you to treat this as a low priority issue. I still do think it is
worth fixing (somehow), but better to deal with it in a generic way that
helps other packages too, rather than trying to cobble
Thanks Simon for setting up a reproducer and verifying! @Nick do you
agree with Simon's findings, which basically mean that the error this
bug report is about is mostly a cosmetic thing, as named will retry?
Anyway, we acknowledge that in general "service X starts before network is
ready" is an
** Tags removed: server-triage-discuss
** Tags added: network-online-ordering
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1965521
Title:
named.service starts too early: Unable to fetch DNSKEY set
Hi Nick,
As you mentioned in the issue description, "Unable to fetch DNSKEY set
'.': failure" is not a fatal error as named is still fully functional.
This is because named comes with the current root zone KSK (key id
20326) compiled in. The error is because it tries to refresh it using
RFC5011
Hi Paride.
The fundamental problem I see with your last statement is how do you
know what "the right one(s)" are? That will depend on BIND
configuration, such as whether named is launched with a '-4' or '-6'
option, and possibly even the value of configuration options such as
'listen-on' and
@Nick I'm not convinced by --any, as AIUI we don't want "any" interface,
but "the right one(s)". I'll mark this bug (again) for further
discussion.
** Tags added: server-triage-discuss
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi Paride.
Thanks for your updates. It is good news that there is a fix for
#1909822.
However this fix won't help with the current issue, because the problem
here isn't whether or not BIND uses interfaces that are added after BIND
is running, but rather the fact that BIND doesn't have
@Nick: LP: #1909822 has been reported as fixed in Jammy. Could you
please test if you can still reproduce the issue you described here on a
clean Jammy system? Thanks!
Marking this as Incomplete for now.
** Tags removed: server-triage-discuss
** Changed in: bind9 (Ubuntu)
Status: New =>
Hello Nick and thanks for this bug report. I didn't try to reproduce
your specific issue, however I can see how it can happen. Unfortunately
detecting when network is ready is a tricky thing, as the definition of
"ready" is not fixed and it's very dependent on the specific
configuration of the
I discovered that above workaround isn't ideal when the server has
multiple network interfaces because the systemd-networkd-wait-online
command above will wait for all interfaces to reach routable status.
This may cause systemd-networkd-wait-online to timeout (after 10 seconds
as per --timeout
10 matches
Mail list logo
