DNS Resolver - force DNS server lookup order
-
You don't! Why anyone thinks they should be asked in order?
If you want forwarding done sequentially to specific dns - then use the forwarder..
That unbound even has a forwarding mode is pretty stupid if you ask me - its a Resolver ;)
In what possible scenario in dns does it make sense to have to ask specific dns in order? Are you pointing to multiple servers that resolve different things? That is a borked setup.. Pointing to say a NS that resolves local stuff as say your primary, and then pointing to 2nd NS that resolve public stuff is not how it is designed to be setup.
While you can list multiple NS, this is meant for hey A doesn't work or doesn't answer.. They need to resolve all the same domains.. Ie they need to be local or they need to be public. But setting some that resolve xyz domains, and others that only resolve abc domains is not how it should be setup.
So in what scenario does it matter which dns you ask first?
-
Where you're using a secure DNS server (e.g. Comodo or Symantec) that for whatever reason goes down, and then you want to fall back to (say) Google when that occurs.
However, if you define both the secure DNS servers and Google, then there's a race condition as to which replies first. Meaning in some circumstances you bypass the secure DNS.
So, I want to query the secure DNS first and only if that fails, fall back to the DNS servers lower in the list.
-
Except that the standard doesn't define any order, the implementations are free to round-robin, randomly use one or use them in the set order if they like. Even sending the queries to every defined forwarder at the same time is possible.
Unbound does what it sees the as best option for you and doesn't offer any option to change the behaviour.
-
There's a sequential query option in the Forwarder (dnsmasq) that does it - see the UI:
Query DNS servers sequentially If this option is set, pfSense DNS Forwarder (dnsmasq) will query the DNS servers sequentially in the order specified (System - General Setup - DNS Servers), rather than all at once in parallel.
I think what you're saying is that the forwarding component of the resolver doesn't have that option.
-
"Comodo or Symantec) that for whatever reason goes down"
Yeah so then like X% of users that use them of the whole internet is down.. So your security matters when its available - but hey if not then just send my shit to any dns that will resolve it give me an IP I can go too ;)
Do you not see the problem with that logic?? From a security point of view?
So your saying both Comodo and Symantec, or any of the other "secure" as you put it dns is down?? Are there not others you could put to get your 4 you think you need.. So that if those 2 secure ones go down, then you use a 3rd or 4th secure one. If they are all secure then what does it matter what order you ask them ;)
Or you could just freaking RESOLVE, using dnssec - and not give 2 shits if comodo or google or open or isp dns is down.. Your using roots and walking the tree.. If the root servers are down then the whole freaking internet is offline anyway ;)
-
There's a sequential query option in the Forwarder (dnsmasq) that does it - see the UI:
Query DNS servers sequentially If this option is set, pfSense DNS Forwarder (dnsmasq) will query the DNS servers sequentially in the order specified (System - General Setup - DNS Servers), rather than all at once in parallel.
I think what you're saying is that the forwarding component of the resolver doesn't have that option.
That's exactly what I'm saying. DNSMasq offers a creative non-standard solution but no other resolver offers the same option (at least that I know of). DNS standard is incomplete in this area and doesn't tell you how multiple forwarders are to be handled.
And yes I agree with john, if you're really concerned about security use the resolver mode.
-
Thanks. I'm probably being slow, but if I turn off the DNS Forwarding option, the resolver still needs to query the root servers. i.e.
"Hey root servers who is NS for .com"
Does that mean that somewhere you still need to tell DNS Resolver what root server to use?
-
Does that mean that somewhere you still need to tell DNS Resolver what root server to use?
No because that's done with the root hints file, it's either built in to the resolver or kept as a separate file or both.
-
Thanks johnpoz. Always grateful for your help.
I'm not using Symantec or Comodo because I think they're any more or less trusted than doing it yourself with the resolver. I'm using them because they allow you to screen out certain types of sites.
But if it's not working for whatever reason then, yes, I'd rather automatically fall back to either using DNS resolver or using Google or some other unfiltered DNS than have no internet at all.
In any event, I think the problem I'm having is due to some problem with DNS Resolver. For reasons I haven't got to the bottom of yet, one particular domain name will not resolve using DNS Resolver (says that it doesn't exist at all), but resolves fine if I use an external DNS server to look it up.
-
The resolver defaults to DNSSEC on and if a domain has broken DNSSEC records it won't resolve. You should be able to add a custom option (Services->DNS Resolver->General Settings->Display Custom Options) for Unbound like this to overcome the problem for a particular domain:
domain-insecure: "brokendomain.tld"Repeat as necessary for other broken domains that you come across.
-
Thanks kpa - that seems to be the exact problem. Trawling through the logs, the domain fails the DNSSEC validation.
It's actually my work's website that's the problem - presumably the DNSSEC records are something the site administrators have control of, so I should be escalating to them too?
…. this actually sidesteps the original question above. I'd thought the problem was Symantec's DNS servers (as another server I tried, which didn't support DNSSEC) successfully resolved the query. With the domain in question marked as insecure, I only need my preferred DNS servers (Symantec) and have removed the other ones.
Thanks for everyone's help.
-
Hi all,
I want to come back to this topic. I want to query the upstream DNS servers in a specific order for achieving the following use case.
I want to use DNS resolver in order to resolve local stuff. The next upstream DNS server should be Pihole or Adguard (i don't want to use pfBlocker ;) ) which is running as a Docker container on my NAS to filter Ads and resolving all the rest (by using public DNS servers). In case the container or the whole NAS is down, the DNS server running in the container is not reachable. This results in DNS problems on the client.
Therefore I would like to setup a public DNS server as a backup directly in pfsense which should be called in case the first upstream DNS server (the one running in the container) is not reachable or timing out.
Is there really no way to achieve this with the DNS resolver?
I am running the newest pfSense 21.05.2-RELEASEThanks
Holger -
@hubs04 This scenario and failure mode is not good at all.
Why would unfiltered results be a valid failure mode? If your concerned with where your running your filtering failing - that make sure if 1 ns fails there is another that does the same filtering
If that fails - I would want to know right away - so I can fix it - or just point unbound to different NS or just let it resolve if my filtering is down. Vs a scenario where my filtering is not working and I don't know about it, they you have say a kid looking at porn, or infecting your network with malware..
How exactly does unbound flip to this other NS - 1 query fails, 10, what if one query just takes a long time? When does it fail back - does it not? So no you run into a scenario where again you do not know what is being asked - your filter system, or not filtered. Which is a horrible scenario.. The only time you should switch to non filtered, is your sure - I you actually tested, yup if broke - and I can not fix it in 2 minutes. So flip users over to nonfiltered in 10 seconds.
There is no way to do your "only" if scenario that makes any sense - if your worried about your filtering system fail - then make sure it doesnt.. That is where time spent on what happens if fail mode should be concentrated..
