OPNsense Forum
English Forums => General Discussion => Topic started by: tofaz on October 12, 2018, 08:45:26 pm
-
Hi all,
I just moved to OPNS 18.7 from PFS 2.4.4 and I was wondering if it is still true that the Unbound DNS is still caching previous queries as it will first query itself and then the configured external DNS for faster responses.
When I diagnose a DNS query in "Interfaces: Diagnostics: DNS Lookup" I see that only the configured DNS are queried and not itself as "127.0.0.1" with 0ms response time since it's local.
Thank you!
-
Hi,
Yes, that's what Unbound does if you don't use forwarding mode.
Cheers,
Franco
-
If DNS still is somewhat a mystery to you - and don't be ashamed if it is, being pretty complex for newcomers - this might clear something up:
Normally - with forwarding enabled, it works like this:
- Your client asks the DNS service "Who is opnsense.org?"
- Your DNS service will check its cache and reply if the answer is already known.
- Since 2 is not true in our example, the DNS service forwards the request to the configured external upstream DNS server(s).
- Upon receiving the answer, your DNS service will reply to your client and tell it the answer of its request.
- Lastly, your DNS service will save the answer in its cache to be able to respond faster if any of your clients queries the same domain again.
With forwarding disabled, it works like this:
- Your client asks the DNS service "Who is opnsense.org?"
- Your DNS service will check its cache and reply if the answer is already known.
- Since 2 is not true in our example, the DNS service delegates the request to the (local) recursive DNS resolver.
- Your recursive server will send a query to the DNS root servers: "Who is handling .org?"
- The root server answers with a referral to the TLD servers for .org.
- Your recursive server will send a query to one of the TLD DNS servers for .org: "Who is handling opnsense.org?"
- The TLD server answers with a referral to the authoritative name servers for opnsense.org.
- Your recursive server will send a query to the authoritative name servers: "What is the IP of opnsense.org?"
- The authoritative server will answer with the IP address of the domain opnsense.org.
- Your recursive server will send the reply to your DNS service which will, in turn, reply to your client and tell it the answer of its request.
- Lastly, your DNS service will save the answer in its cache to be able to respond faster if any of your clients queries the same domain again.
You can easily imagine even longer chains for subdomains as the query process continues until your recursive resolver reaches the authoritative server for the zone that contains the queried domain name. It is obvious that the methods are very different and the own recursion is more involved than "just" asking some upstream server. This has benefits and drawbacks:
- Benefit: Privacy - as you're directly contacting the responsive servers, no server can fully log the exact paths you're going, as e.g. the Google DNS servers will only be asked if you want to visit a Google website, but not if you visit the website of your favorite newspaper, etc.
- Drawback: Traversing the path may be slow, especially for the first time you visit a website - while the bigger DNS providers always have answers for commonly used domains in their cache, you will have to transverse the path if you visit a page for the first time time. A first request to a formerly unknown TLD may take up to a second (or even more if you're also using DNSSEC). Subsequent requests to domains under the same TLD usually complete in < 0.1s.
Information largely sourced from a Pi-Hole guide (https://docs.pi-hole.net/guides/unbound/). Interesting, unrelated side-note: another member, Alec, is implementing the functionality (https://forum.opnsense.org/index.php?topic=9523.0) Pi-Hole offers in OPNsense!
-
I think the confusion comes from the fact, that there are actually 2 very similar solutions in opnsense for the DNS name resolution: Unbound AND dnsmasq. So its not a surprise, that without guidance or detailed explanation, one can get easily lost whether these 2 both are needed (they both solve only half of the task), or they are mutually exclusive and only 1 should be used at any time?
Its also not trivial, considering that:
1) you can provide a global DNS server list in the System tab. Its not really explained, that the definition of an entry here basically sets forwarding to an upstream DNS server, and practically disables recursion type of working
2) your ISP can send you their own preferred list of DNS servers, when you establish an internet connection via your opnsense box. You either accept this list or you reject it ans specify your own preference, as seen in 1)
3) recursion mode enabled in Unbound settings, that does completely ignores 1) and 2)
Your explanation (even if copied from an external source) could use some more wording, like:
1) Your client asks the DNS service "Who is opnsense.org?"
rather say this:
1) A PC on your local LAN wants to resolve a DNS name.
This PC has been set up with the preferred nameserver pointing towards the LAN IP address of the Opnsense box. So this PC sends a DNS query to the Opnsense router, to resolve the DNS name, and send back the reply to your PC.
2) Your DNS service will check its cache and reply if the answer is already known.
rather say this:
2) The DNS service called Unbound, running on your Opnsense router will check its internal cache and reply, if the answer is already known.
3) Since 2 is not true in our example, the DNS service delegates the request to the (local) recursive DNS resolver.
rather this:
3) Since 2) is not true in our example, the Unbound DNS service running on your Opnsense router delegates the request to the (local) recursive DNS resolver. Which is a fancy way of saying, that the local Unbound service needs to figure out how to get the job done via asking other DNS servers.
4) Your recursive server will send a query to the DNS root servers: "Who is handling .org?"
rather this:
4) The Unbound service running on your Opnsense box will send a query to the DNS root servers: "Who is handling .org?" How did Unbound know where these DNS root servers are? It has a static file stored locally, called root.hints that lists the IPs of all these publically known DNS root servers. Without the root.hints file, this approach breaks!
"It is obvious that the methods are very different and the own recursion is more involved than "just" asking some upstream server. This has benefits and drawbacks:"
I would extend this section with the following:
Malware protection: some hosts on the internet serve malicious content, therefore it is advised to block your DNS clients being able to contact these hosts. So as a simple defense method, you want to "break" the normal DNS name resolution for malicious hostnames, and reply with a bogus IP address for such hosts. Either you maintain an active lists of such hosts. In that case your Unbound running on the Opnsense box can authoritatively reply for such entries with a bogus IP address.
Or you subscribe to the public OpenDNS service. In that case, you cannot use recursion on your Unbound, but rather use it in forwarding mode, and trust OpenDNS to make a filtering on the requests of your DNS clients.
-
Thank you for all the responses and explanations.
I am aware how DNS works and specifically how OPNsense DNS service works with unbound and dnsmasq. My question was related to the fact that, when I use the GUI lookup tool to lookup an name with my unbound config using the forwarding mode, I see the tool querying just the forwarding DNS entries and not itself first in order to diagnose if the query is already in the cache. This is something that PFsense was showing when using the diagnostic tool, so not being specifically showed there, I just wanted to make sure that Unbound was still querying itself first in order to check if a name is already in the cache
Thank you
-
"I am aware how DNS works and specifically how OPNsense DNS service works with unbound and dnsmasq"
Would you mind sharing the details with the conmunity about your knowledge? Is it your own experimenting, or you found the explanation on some public website?
-
Like any other *nix package that I use I read the man. For Unbound specifically you can find it on line here:
https://nlnetlabs.nl/documentation/unbound/ (https://nlnetlabs.nl/documentation/unbound/)
My question was related to the diagnostic tool that was not showing the query delay to himself since the record could be already cached, before asking to the forwarding DNSs.
Anyway, a "dig" from your client can clarify this, but I was not sure why it was not showed on the OPNsense GUI itself (Like PFsense).
-
@2fun0: thanks, but the official Unbound man page has no idea how Opnsense has been built to provide name resolution to the opnsense box itself, and to LAN clients. As opnsense can be configured to use unbound in many different ways:
1) recursive mode
2) forwarder mode
3) use dnsmasq (in parallel with unbound?)
4) use bind (but in what relation with unbound?)
So in short, the Unbound man page has not much to do with how a different product called Opnsense works.
-
OPNsense GUI configures Unbound as it would be configured by CLI.
-
Sorry, but I think we are talking about to separate things:
you talk about unbound as a standalone/separated product living on an empty island, and I am talking about unbound integrated into opnsense, and configured in parallel with dnsmasq and bind.