Hi, folks. Just wondering why every time I log into IPFire to check DNS etc., my chosen Quad9 will be greyed out, and the system itself reports that it’s using my “ISP’s” DNS, despite it having been ostensibly turned off (per attached screenshots)?
Versus what the system reports (at same time as the above).
In the above, you can see I disabled 1.1.1.1 (= one.one.one.one???) and 8.8.8.8 on RED
In this screen shot, you can see purported 1.1.1.1 & 8.8.8.8
This is confusing.
This last screen is right, because your RED interface uses DHCP and your router/modem gives you for DNS 1.1.1.1 & 8.8.8.8. That’s why the headline is RED DHCP configuration. You can overwrite the DNS via DNS configuration.
1 Like
Maybe this is a fallback solution if both manually setup DNS don’t work / unreachable. Only a dev member may tell you about that.
Your first screen seems ok. ISP’s DNS disabled, alternative servers enabled an OK, DNS working.
Why do you suppose, the ISP’s supplied servers are used?
The state of the servers specified can be displayed by hovering over the ‘OK’ fields.
In the 2nd screenshot, it’s just showing the ISP-assigned DNS servers. Not necessarily what you are using.
I don’t see in either of your screenshots that Quad9 is “greyed out”. The first screen does in fact show Quad9 as the active DNS server.
1 Like
So, yeah: the phrase, “RED DHCP configuration” on an actual Net-Traffic graph page says to me it’s configured, to 1.1.1.1 / 8.8.8.8. Doesn’t that page reflect real world traffic? Not just settings?
Meanwhile, back on the DNS servers configuration page, my selections marked in green as okay now, were greyed out, until I went in to ‘Check DNS Servers’. As soon as I check, they pass and light up.
Still confused at what I’m seeing.
If you mean the ‘status’ column, this is filled after a ‘Check DNS Servers’ only.
That is what IPFire gets when it queries your ISP’s DHCP server. It is showing their settings on their end. Once traffic comes into IPFire, then IPFire can, at your direction, use different DNS servers in place of the ISP’s.
Not totally right: this column only shows the settings (IP-Adress, gateways, DNS) given via DHCP by any DHCP server found on the RED interface.
In my case for exampe it has nothing to do with the ISP, because I have a router with a DHCP server connected to the RED network.
1 Like
Hm this is strange and comes back to my suggestion, that both servers couldn’t be reached and then a fallback solution (using the DHCP DNS IPs) took place. Next time you see that take a screenshot.
As far as I am aware there is no fallback option. If the ISP dns’s are disabled, they are never used.
That would be good to see.
1 Like
What happens if the manually configured DNSs are not reachable?
Will they be disabled automatically and the DHCP DNSs reactivated and the other way around whem the manually DNSs are reachable again?
DNS fails to get any answers and your url’s will fail to be resolved.
1 Like
Ok so there is no fallback. Still like to see a screenshot of this situation.
As far as I am aware there is no fallback. A screenshot would be good to see.
The DNS entries are not shown as greyed out on my system when they are not enabled.
I will have to have a look at the code to see if there is anything that would make an entry greyed out.
That might take a bit of time as I am very busy at the moment but I will try and remember to have a look.
3 Likes
As far as I know, unless the behavior was changed deliberately when it was ported in:
netlabs version of unbound checks connections for all in the list then connects with the one that has the fastest response ping in the list.
If it looses this connection it scans the dns in the list and connects to the fastest dns ping response.
If fails, then it retries every 5 minutes until it gets a dnssec connection..
There is no fallback to a dns server, as like a ‘secondary dns’ like cient dns software has, only a list of servers it will try if it doesn’t have a connection and timeout/reties timers set to 5 minutes.
I really don’t understand why secondry dns is in the dhcp part because you will always want the network clients to use the network’s dns as the resolver.
I have mine set to use ISP andi have two other dns entries that are google dns.
So unless they change it when the isp dns goes offline to reboot, it connects to the avvailable one on the list, then if there are preferred dns selected, it will try those every 5 minutes to reconnect to the preferred entries. In ipfire I am assuming the “use ISP DNS” is their preferred DNS entries in the list.
DHCP settings and DNS settings are two separate things!
DHCP info is given to a DHCP client in the LAN. The client can decide which DNS entry it uses.
DNS entries are put into the unbound configuration. Unbound, as a DNS resolver, uses this pool as possible name information ressources. This pool can consist of any servers, which use DNSSEC ( this is a wise decision of IPFire devs!). Many ISP provided DNS servers ( which are announced by the DHCP response on RED ) do not support DNSSEC. This is the reason, why they are not recommended and can be switched off.
1 Like
Ok, so the option to use isp dns is not a tag for the preferred dns. That means it will default to the order of the list of dns in the file.
I know dhcpd and dns are separate things. I just wondered why there are secondary dns entry options on a self resolving system. I guess if the priority is high enough to warrant putting an entry into it, but that opens up the possibility for dns leaks too.