I am running unbound 1.6.6 on Amazon Linux (RHEL 7 derivative).
I have an issue where startup is taking roughly a minute. After reading several posts I discovered that this is due to unbound trying to contact root DNS servers and it takes a minute to timeout. As a test I updated my outbound rules to allow all outbound traffic on port 53. This indeed made startup almost immediate.
Unfortunately I have been told by my security team that I cannot enable this rule since they require all outbound DNS traffic to route through OpenDNS. In short I need to set up my unbound as a “dumb forwarder”. I tried setting module-config: “iterator” to disable DNSSEC but the behavior is the same. I even tried putting in the OpenDNS server IPs in root.hints but the startup time is still around a minute (timeout). As a further test I put one of the known root servers as the only entry in the root.hints file and set an outbound rule just for that server. The behavior I am seeing is it is faster but not what I expect. Start up takes 7-10 seconds which leads me to believe that it is still trying all of the root servers and not just the one I have configured.
Does anyone know how to truly disable the root server queries on start up? I have read several of the threads and this appears to be the closest to my issue:
In the end he was told that it may be due to an older version of Unbound since the bug was fixed. I verified I am running the proper/latest for my Linux distribution unbound version (1.6.6):
OpenDNS rewrites DNS answers and breaks DNSSEC. So you need to get in
sync with your Security people on the question of whether they expect
you to trust DNSSEC answers rewritten by opendnssec. If they just want
to audit the DNS queries and are monitoring all DNS queries to/via
opendns, then you only need to configure the opendns servers as
forwarders. You will drop all rewritten answers that fail DNSSEC
validation (but since they were rewritten, likely these were filtered
anyway)
If the expect you to believe different DNS answers as rewritten by
opendns to possibly point to different IPs (does opendns do this?)
then you might need to also disable DNSSEC validation, but that
makes you vulnerable to DNS spoofing in the path between opendns
and your servers.
For your configuration, you can try removing the forward-zone
and use:
If I remove the forward zone as you proposed, that will not send traffic to OpenDNS correct? I understand that I need to have the conversation with my security team about whether they choose to trust rewritten answers, but they still require that we use OpenDNS.
Second, I am not sure I completely understand the root.hints functionality. I was under the impression that I could create a custom one. For example the one you linked has 13 root servers. I tried configuring it with only one of those root servers, allowing outbound access to that server, yet the startup time is still not as quick as when I allow all outbound access. This leads me to believe that it is still trying root servers I did not define? (This was only a test and I am not proposing to only use one root server)
This email is from an external sender.
> I am running unbound 1.6.6 on Amazon Linux (RHEL 7 derivative).
> Unfortunately I have been told by my security team that I cannot enable this rule since they require all outbound DNS traffic to route
> through OpenDNS. In short I need to set up my unbound as a “dumb forwarder”. I tried setting module-config: "iterator" to disable DNSSEC
> but the behavior is the same. I even tried putting in the OpenDNS server IPs in root.hints but the startup time is still around a minute
> (timeout). As a further test I put one of the known root servers as the only entry in the root.hints file and set an outbound rule just
> for that server. The behavior I am seeing is it is faster but not what I expect. Start up takes 7-10 seconds which leads me to believe
> that it is still trying all of the root servers and not just the one I have configured.
OpenDNS rewrites DNS answers and breaks DNSSEC. So you need to get in
sync with your Security people on the question of whether they expect
you to trust DNSSEC answers rewritten by opendnssec. If they just want
to audit the DNS queries and are monitoring all DNS queries to/via
opendns, then you only need to configure the opendns servers as
forwarders. You will drop all rewritten answers that fail DNSSEC
validation (but since they were rewritten, likely these were filtered
anyway)
If the expect you to believe different DNS answers as rewritten by
opendns to possibly point to different IPs (does opendns do this?)
then you might need to also disable DNSSEC validation, but that
makes you vulnerable to DNS spoofing in the path between opendns
and your servers.
For your configuration, you can try removing the forward-zone
and use:
Hoping someone can help me understand the root.hints functionality.
"I was under the impression that I could create a custom root.hints. For example the one you linked has 13 root servers. I tried configuring it with only one of those root servers, allowing outbound access to that server, yet the startup time is still not as quick as when I allow all outbound access. This leads me to believe that it is still trying root servers I did not define? (This was only a test and I am not proposing to only use one root server)"
Is there a way to do root server lookup on only the server specified (if it cannot be disabled completely)?
The root hints are used to find a server that can respond to a priming query, ./IN/NS -- once a response to that priming query is received (containing in the additional section at least some set of glue, sufficient to look up whatever glue did not fit, in the event it was not complete) the root hints are no longer used. So even if you start with a set of root hints that contains a single address, the resolver will still generally use the full 26 addresses once it has received a priming response.
If you want to use a root server set that is different from the full set, you need to create your own private set of root servers that serve your own root zone with a different NS set. You will have to import the delegation RRSets from the real root zone, sign that zone with your own key set and use your own trust anchor if you want to be able to validate responses using DNSSEC.
This is not a particularly good idea for an operational DNS service, but it's often done in a lab environment.
I suspect the answer you're looking for is "you can't do that".
Since your forward-zone is configured correctly, it should work fine as long as you have access to the forward servers. I am not sure what you mean by allowing all outbound traffic on port 53 or not. You need to be able to send traffic to port 53 on the OpenDNS servers for this to work. I run with a forward-zone for "." all the time and have no problems with the default root servers.
Regarding root-hints: The reason they are called hints is that as long as you can get to any one of them, that one will tell you where the others are. In other words, having one is the same as having all, as long as that one is valid.
Perhaps I was a little too vague by saying "allowing all outbound traffic on port 53". In short I meant my outbound NACL currently only allows outbound access on port 53 to the OpenDNS IPs (208.67.222.222 & 208.67.222.220). Rather than putting rules for all 26 root servers (both udp and tcp on port 53), it was easier for me to test by allowing all outbound (0.0.0.0/0) on port 53.
I have a better understanding now of how this works. Thanks again!
Rather than putting rules for all 26 root servers (both udp and tcp on port 53), it was easier for me to test by allowing all outbound (0.0.0.0/0) on port 53.
A minor correction; 13 root servers but 26 root server addresses (each
currently has one IPv4 and one IPv6 address).
Note also that the root servers are not the only things you need to be
able to reach if you want your nameserver to operate with full
recursive lookups and you want to be able to resolve things outside
the root, arpa and root-servers.net zones.
Yes, it is truly annoying to operate unbound in a non-Internet or firewall-restricted environment.
Every start/restart takes ~2 minutes on my CentOS box. Even though I provide the root-hints to unbound as a file, it still wants to contact the root nameservers during startup.
I’ve found better results with unbound-control reload. It does something similar to restart or kill -9 + start, I am not aware of the exact difference tho.
It reloads unbound in a few seconds even in a restricted environment.
Additionally, nowhere in the documentation does it say what I need to do when I update the root.hints file, reload or restart ?
Thanks for the tip regarding unbound-control. I assume the initial start still has to be via the systemctl script. I Bring up this point since for the teams I support they need DNS to be available much quicker during bootstrap. I will dig deeper into this as well. Thanks again.