Sometimes name resolution for hosts on the GREEN network worked, sometimes it didn’t

Networking DNS
1

Continuing the discussion from Core 154: Problems with local domain name resolving:

Hi - I’m sorry to bring this ancient thread back to life! I’m baffled why this works.

I applied one of the changes outlined in the post marked as “Solution”.

My approach with IPFire since forever is to have the simplest possible configuration that works for me. I have DHCP enabled on the GREEN interface on /cgi-bin/dhcp.cgi.

DHCP used to be taken care of by a RPi running PiHole, but I got rid of that as it was adding unnecessary complexity.

Since switching to IPFire as my DHCP server for the GREEN network, sometimes name resolution for hosts on the GREEN network worked, sometimes it didn’t. I’ve desultorily quacked for a solution on and off for months, until the right combination of search terms brought me here.

Frankly I didn’t expect the fix outlined here to work:

after I setup the setting of the NTP server and the WINS-Server, which is in my case the same as for the DNS server, the problem is gone.

The IP address of the GREEN interface on my IPFire host is the value for “Primary DNS” on the /cgi-bin/dhcp.cgi page. I added the same IP address for “Primary NTP server” and hit “Save”.

To my amazement, the problem was solved instantly. Hosts running Android and Linux which a moment before were returning “unknown host” or “Name or service not known” were now able to resolve a host on the GREEN network.

image
image653×587 35 KB

What’s going on here? How could adding “Primary NTP server” be the fix for this problem?

Isn’t this a symptom of a bug? Network Time Protocol is completely unrelated to DNS!

Happy New Year! Thanks for reading.

1 Like
2

@barneyklarnocks
maybe an ancient 'feature' :man_shrugging:
you can try a search on the 'forum' with the
keyword 'unbound-dhcp-leases-bridge' to get the idea :mag:

3

Oh, thanks: Search results for 'unbound-dhcp-leases-bridge' - IPFire Community

I’ll read up further on this later today. That’s disappointing. Though I’d rather a bug like this than having my firewall owned.

4

Please note that the unbound-dhcp-leases-bridge program has been re-written in Core Update 188

https://www.ipfire.org/blog/ipfire-2-29-core-update-188-has-been-released

and some additional bugs further fixed in Core Update 190.

https://www.ipfire.org/blog/ipfire-2-29-core-update-190-released

Most of the posts in your search are from before the above changes were implemented I think.

2 Likes
5

Thanks for the quick reply, Adolf. Good to know this (at first glance) misbehaving component has been addressed. I’m on 190.

What else then could be causing these intermittent name resolution failures?

(I find DNS annoying hard to debug. Mostly through ignorance on my part, but also because I detest systemd. Which is what most of my hosts use.)

6

@barneyklarnocks
have you checked the content of
the lease file when the 'host not found' appears :question:

7

I have no real idea.

I have never seen the problems that you are experiencing. I have never had to enter anything into my Primary NTP server box. It is always empty for all my IPFire systems (physical production system, physical dev testing system and several virtual dev testing systems. I specify the ntp server to be used on each client system.

All my systems tend to run with only fixed leases, so I don’t have any dynamic leases except occasionally when doing some testing on the virtual systems.

All my hosts, except my android phone, are using systemd and they get a host IP allocation with no problems.

I have added all my clients into my WUI Hosts page.

The only thing I can suggest is that when a situation occurs where the resolution fails is to run a dig command on the name and see what response comes back with that and also look in the logs for unbound and dhcp and see if there are any messages related to the issue.

You could also try the ping command and add -v so you get the verbose output to maybe get more info on which point it is failing.

Also when the name resolution fails confirm by the systemctl status command if the clients still have the same IP address. Then to restart the client and confirm if the dhcp communication is normal or not.

The above would be the sort of things I would be looking for if I was fault finding that sort of issue on my systems.

1 Like
8

Superb. Thank you for these tips. I wasn’t even aware IPFire is using unbound, for example.

I have never had to enter anything into my Primary NTP server box.

On reflection, I don’t think adding this property was the ‘fix’ - the restart of the DHCP server after I’d made the change was - for a whole, at least. The issue recurred later in the day.

9

@barneyklarnocks
was it for all hosts or some hosts :question: :mag_right:

2 Likes