Created attachment 1715 [details] The DNS logs after the fresh install. With build next/07805a0e the dns times out for 120 seconds and ends up with FAIL status. Then the dhcpcd connection is successfully made and I can log in to the console. The status of knot-resolver shows it is running with a pid. Log in with the WUI and the DNS page shows DNS as Broken and the "ISP" dns connection (which is my main IPFire system) is shown with an Error status and the message Response Timeout. The attachment shows the dns logs from the system.
I did a reboot and the dns counted for only 26 seconds. No FAIL indication but also no OK. After completing the WUI still showed the same status for the DNS of Broken and the DNS server giving Response Timeout.
(In reply to Adolf Belka from comment #0) > Created attachment 1715 [details] So the log looks pretty bad. It seems that the system has absolutely no chance reach any of the root DNS servers for priming. Does it have connectivity at all? Or is this just because we are starting Knot Resolver without the rest of the network being up, yet? (In reply to Adolf Belka from comment #1) > I did a reboot and the dns counted for only 26 seconds. No FAIL indication > but also no OK. Well it isn't supposed to print the counter at all. That was a line I forgot to remove before my commit. But it should say OK if it terminates before the timeout. Knot Resolver has a persistent cache on disk. So once it has been primed, it won't need network connectivity to serve any hot data that is still in the cache. > https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/waitfordns;h=f353db778fb6398147f898e4e7cbabd1551cd775;hb=refs/heads/next#l36 On this line, could you replace looking up NS for the root zone with A and localhost? The resolver should always know what that resolves to without being online and the only thing we care about at this stage is that the DNS resolver is responding, not that it will be able to actually look up anything. > After completing the WUI still showed the same status for the DNS of Broken > and the DNS server giving Response Timeout. That suggests that something is very wrong on your installation. I did a fresh install from the nightly build this morning and Knot Resolver came up just fine. So we have to find out what is different between your and my setup.
(In reply to Michael Tremer from comment #2) > > > https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/waitfordns;h=f353db778fb6398147f898e4e7cbabd1551cd775;hb=refs/heads/next#l36 > > On this line, could you replace looking up NS for the root zone with A and > localhost? The resolver should always know what that resolves to without > being online and the only thing we care about at this stage is that the DNS > resolver is responding, not that it will be able to actually look up > anything. > To make sure that I have it correct for what I should do. I should change line 37 from "NS" "." to "A" "@127.0.0.1" Is that correct?
Created attachment 1719 [details] DNS logs with static red connection It looks like the problem, whatever was causing it, seems to have stopped. I remembered that you had said that you were using a static connection while mine was dhcp. So I ran setup and changed red from dhcp to static. Then I rebooted and the dns waiting bit was around 4 seconds and then showed OK. The DNS WUI page also showed working. This was without any change as had been suggested in comment 2. I rebooted 3 or 4 times and in all cases the dns wait time was between 2 and 4 seconds and the DNS WUI page was working. The DNS logs from this are attached.
Created attachment 1720 [details] DNS logs with dhcp connection I then ran setup again and changed red back to dhcp and then rebooted several times. The dns wait time was around 4 seconds. In all reboots the DNS WUI page showed working. The attached DNS log is for the dhcp connection. It seems to me to be showing a similar result for both the static and dhcp red connection. The previous issue that triggered this bug is no longer occurring. I suspect that I should close it for now unless it comes back and I can define how to make it do what it was doing. I will also do any further testing with the latest build version. All of this was with Development Build: next/07805a0e
(In reply to Adolf Belka from comment #3) > (In reply to Michael Tremer from comment #2) > > > > > https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/waitfordns;h=f353db778fb6398147f898e4e7cbabd1551cd775;hb=refs/heads/next#l36 > > > > On this line, could you replace looking up NS for the root zone with A and > > localhost? The resolver should always know what that resolves to without > > being online and the only thing we care about at this stage is that the DNS > > resolver is responding, not that it will be able to actually look up > > anything. > > > To make sure that I have it correct for what I should do. > > I should change line 37 from > > "NS" "." > > to > > "A" "@127.0.0.1" > > Is that correct? Yes, this should make the check a lot more sane. We just want to know if the resolver is responding. It doesn't have to be online, yet. So, let's consider this solved until we change our mind.
https://www.ipfire.org/blog/ipfire-2-29-core-update-203-is-available-for-testing
Confirmed on 4 vm systems to be working correctly.
Core Update 203 has been released: > https://www.ipfire.org/blog/ipfire-2-29-core-update-203-released