directing DNS queries to local unbound?

[22decembre]

I would like myself to use a localhost unbound on my laptop.

Using 127.0.0.1 as resolver is indeed not a problem. But telling unbound to use the resolvers provided by the local network (dhcp or rtsol) to make all classical queries (eg : dynamic conf of unbound) would be great.

[jggimi]

Hello and welcome, 22decembre.

Yours is a separate question. We like to put branching questions into their own threads, to make them easier to find and read about when searching. I'm sure one of our admins will move your question and my answer to a separate thread.

---

1. Instruct dhclient(8) to ignore the nameserver(s) submitted by your DHCP server, and use your loopback (localhost) address:
   
   # echo "supersede domain-name-servers 127.0.0.1;" >> /etc/dhclient.conf
   
   See dhclient.conf(5) and dhcp-options(5) for much more information.
2. Edit /var/unbound/etc/unbound.conf and add your nameservers to the forward-zone as forward-addr addresses. See unbound.conf(5) for more information.
3. Add unbound(8) to your starting daemons:
   
   # echo unbound_flags= >> /etc/rc.conf.local

[22decembre]

I think my question fits perfectly into this subject, so I answer there. If not, then message me and I will create the right thread.

I would like that dhcp/rtsol gives its dns servers to unbound, so that unbound will query them for all dns requests, which will give lower network load. This is the behavior of dnssec-trigger.

But dhcp only create /etc/resolv.conf according to openbsd's manuals. And unbound has no option to create dynamically the forwarders option (not that I read).

I read that my desired behavior for dhcp/unbound has been setup in base freebsd.

I don't see any way to setup this in openbsd.

[ocicat]

This discussion has been separated from its parent thread:

http://daemonforums.org/showthread.p...2939#post52939

...which focused on secure DNS lookups.

We find that most members at this site use the archives extensively to search for specific information. To help simplify this process, we ask members to limit discussion in all threads to a single subject as set forward by the thread's original post. If a member has a question on something not pertinent to the original post, please start a new thread; it's easy.

This is also covered in the forum rules.

[rocket357]

Originally Posted by 22decembre

I would like that dhcp/rtsol gives its dns servers to unbound, so that unbound will query them for all dns requests, which will give lower network load.

Lower network load? How often are you looking up addresses that it would reduce load? Unbound caches, sure, but so do quite a few other programs running on your local machine (browser comes to mind immediately). I can see using unbound *as* your local network resolver, but I can't imagine a scenario where unbound should point to another resolver on the network solely on the function of reducing network load. (Based on the fact that the network resolver likely caches lookups, too, and dns packets tend to be miniscule in size).

Redirecting traffic to specific nameservers? OK, sure. Directing some urls to certain nameservers (.onion or .exit to a local tor relay...or perhaps even redirecting certain "sensitive" domain lookups to, say, dnscrypt proxies)? Ok, I get that...but purely to reduce network load? I don't understand your use-case.

[J65nko]

Rocket357, when is the last time you ran something like $ sudo tcpdump -ni re0 port 53 during a web surf session? You really should do it and then imagine you are in class with 30 other people and the wireless link is not so good

And with the increasing usage of DNSSEC the packets will become larger, so it was needed to eliminate the limit of 512 bytes in the EDNS specification.

IMHO plenty enough reasons to run a local caching forwarding (stub) resolver on workstation or laptop.

[22decembre]

Each time I reboot the laptop, I lose all the dns cache.

Plus, it's better to use the (closest) network dns, as you share your dns results within your close network. In that case, your local unbound would only do dnssec queries and validate them.

This is the aim.

Do any of you see how to do that ?

I think maybe I should just forward to a permanent dns that I setup, or use an open resolver like google or opendns (need other than them yet), but in that case, I increase the load.

PS : to admin, sorry I should have started a thread from the begining

[jggimi]

Originally Posted by 22decembre

Do any of you see how to do that ?

• All systems on my LAN (network 10/8) share a local nameserver at 10.0.1.1. (This happens to be a pair of computers sharing the address with carp(4) but that doesn't matter.)
• The local nameservers use unbound(8), and I have configured unbound to use Google's public nameservers. I have the following lines at the end of /var/unbound/etc/unbound.conf:
  

  .
  .
  .
  forward-zone:
          name: "."
          forward-addr: 8.8.8.8
          forward-addr: 4.4.4.4

• My local DHCP servers provide 10.0.1.1 as the nameserver address to all systems on the LAN.
• The unbound(8) servers use 127.0.0.1 in their local /etc/resolv.conf files.

[22decembre]

@jggimi : yeah, but you're static, so no problem. Your setup is just a classical local-lan-dhcp-nameserver (I have dnsmasq on my static lan).

My laptop is by definition mobile. So I can't use the nameservers provided by dhcp (which are generally not dnssec-aware/able).

[jggimi]

If, by "mobile" you mean you will be using your laptop on untrusted LANs, you can either use a VPN, or DNSSEC, or both together. DNSSEC only provides authentication, a VPN would be needed for privacy.

Is your problem that you are unable to switch from your home caching nameserver to a local-on-laptop unbound(8) configured for DNSSEC dynamically? If so, there are scriptable solutions, using either multiple dhclient.conf or unbound.conf files.

If I've misunderstood, please clarify what it is you wish to accomplish.

[22decembre]

I don't see what is hard to understand.

By mobile I mean that I go from one lan to another. So I believe it means untrusted if you're paranoïd. What it means for sure is that I don't control the network settings (local address of my laptop, local dns resolvers, local gateway to the rest of the world...).

So if I use a local unbound on 127.0.0.1, but don't use the dns provided by dhcp, it will produce a massive network load as each browser request will produce a complete dns request, no matter that everybody around me has already ask for these data and are present in the local resolvers.

Instead, I should tell unbound to use the local resolvers provided by dhcp to forward all request to them. That way, unbound will only do final validation with dnssec.

So, I don't know about the scripts you just mentionned. I believe it's what I need. Can you tell me more.

[jggimi]

Originally Posted by 22decembre

...I don't control the network settings (local address of my laptop, local dns resolvers, local gateway to the rest of the world...).

This is true: to participate on a routed TCP/IP network and route your traffic to other networks, you must use the addressing and routing requirements of your participating network: a) one (or more) unique IP address assignment(s) within a defined subnet, and b) routing your traffic through the appropriate gateway(s).

Your device is not required to use any local DNS nameservers. Whether or not the network allows outbound DNS queries to other nameservers is a separate administrative issue.

So if I use a local unbound on 127.0.0.1, but don't use the dns provided by dhcp, it will produce a massive network load as each browser request will produce a complete dns request, no matter that everybody around me has already ask for these data and are present in the local resolvers.

I can agree with all but your use of the word massive. Even if you were to use a locally provided nameserver, your domain queries will still carry a local network load. This is a small percentage of the data being carried over that wireless network segment you will be using. Any domain queries you submit to your own (or other) namesevers will not be a significant portion of your overall bits-per-second bandwidth or, the more critical packets-per-second traffic demaind.

Instead, I should tell unbound to use the local resolvers provided by dhcp to forward all request to them. That way, unbound will only do final validation with dnssec.

I understand you wish to be a good network citizen and not increase demands upon a local network you are using. However, I do not see DNS queries by a browser being abusive, and I do not see this step as necessary.

Whether or not those local nameservers participate in DNSSEC is a separate issue, and if not your trust anchor traffic will be produced by your local DNSSEC resolver, unbound, anyway.

So, I don't know about the scripts you just mentionned. I believe it's what I need. Can you tell me more.

Your personal "road warrior" setup script might:

1. Issue an ifconfig(8) scan command to search for SSIDs
2. Permit you to select from the SSIDs found, and add WPA pre-shared keys or WEP keys as desired.
3. Issue a dhclient(8) command to accept and configure IP address, gateway routes, and locally recommended nameserver IP addresses.
4. Read the nameserver address(es) from your newly created resolv.conf
5. Create a temporary unbound.conf(5) file that includes your DNSSEC configuration and the locally recommended nameserver(s) as forwarding servers.
6. Start unbound(8) using its -c option to point to the temporary file.

[22decembre]

Originally Posted by jggimi

Your device is not required to use any local DNS nameservers. Whether or not the network allows outbound DNS queries to other nameservers is a separate administrative issue.

Obviously.

I can agree with all but your use of the word massive. Even if you were to use a locally provided nameserver, your domain queries will still carry a local network load. This is a small percentage of the data being carried over that wireless network segment you will be using.

Thank you. It is indeed my preoccupation. Low use of network and other public ressources, efficiency.

I was not aware of the amount of network load in such case.

So instead, I believe I should forward my dns queries to my own static unbound server or another resolver.

[rocket357]

Originally Posted by J65nko

Rocket357, when is the last time you ran something like $ sudo tcpdump -ni re0 port 53 during a web surf session?

You can't be serious.

My home network has a resolver (unbound on OpenBSD-5.6-STABLE) serving numerous vlans both wired and wireless with a 100 Mbps core Cisco switch (needed the port density vs. the speed). The dns traffic distribution while my wife is watching streams + surfing the web and my daughter is goofing surfing the web while my 8 machines are all doing various daily tasks is amazingly miniscule. That's not including the cell phones, tablets, and tivos on wifi, or other odds and ends running locally.

Yes, x + y is greater than x (given that y is positive, and I've never witnessed negative-sized dns traffic, so I must assume y is positive), but that's like saying if you shoot a freight train in the caboose with a bb gun the freight train will go faster. Sure, there might be some very minimal effect, but designing a system to reduce load on the freight train by shooting it repeatedly with bb guns is insane.

Surely there is a bigger impact solution that should be resolved first before following this route to completion?

As I said before, I can see running a resolver on a local machine for various other reasons (directing specific traffic to specific resolvers, etc...) but running a local caching resolver *when local programs typically cache dns lookups anyways* to cut down on network load seems silly. If the network can't handle normal dns traffic, there's no sense in doing anything else until you fix *that* issue first.

Edit - and to answer your question directly, it was around two years ago when I was in RHCE classes, with around 75 students. I still maintain that if the network is "under load" from normal domain traffic, you have bigger problems than local resolvers.

[rocket357]

J65nko,

I felt it would be prudent to actually gather bandwidth consumption on my network for DNS and non-DNS traffic (if I'm going to make a claim that the traffic is "amazingly miniscule", I should back it up, right?).

I ran a single browsing session over the course of a few minutes and gathered bandwidth for just "dns + dnscrypt" and for everything else. During that time a total of 4.262 MB of data was transferred, and of that 212 Kb was dns/dnscrypt. Now, dnscrypt uses considerably more bandwidth than pure dns (with the TLS overhead and what not), so I think that lends credence to the idea that DNS traffic is a small fraction of overall traffic. Still, that's just under 5% of bandwidth consumed, which I will admit is higher than I expected and perhaps enough under the right conditions to exasperate other existing network issues.

Given that, it does seem to me that if one is stuck behind a very high latency link, it might make sense to run a local resolver like unbound.

In short, fair enough...I accept your argument.

[jggimi]

Network usages vary. I just took a look at network flows through two firewalls over the same 24-hour period ... I selected December 23, the most recent normal traffic day. DNSSEC is not used, this is only queries and responses using UDP/TCP port 53. These numbers include local queries to unbound nameservers as well as remote queries, and represent overall network usage:

Percentage of bytes transmitted and received: 0.036%
Percentage of packets transmitted and received: 0.315%

When looking at domain traffic with external nameservers as a percentage of Internet traffic only, rather than total network traffic:

Percentage of bytes transmitted and received: 1.251%
Percentage of packets transmitted and received: 8.707%

Domain traffic are relatively small packets, which is why there is an order of magnitude ratio difference between traffic in bytes and traffic in packets. They are a much higher consumer of packets than of bandwidth.


In summary:

• The network load for standard, insecure domain traffic was seen to be a negligible component of overall bandwidth.
• Domain resolutions requiring external nameserver lookup was a minor component of Internet bandwidth consumption.
• Domain resolutions are a significant portion of Internet-transiting packet traffic, even with local caching nameservers deployed.

Authentication (DNSSEC) and encryption (VPN, DNSCurve, etc.) were not used for domain traffic and were not examined.

[IdOp]

In firefox/SeaMonkey you can set

network.dns.disablePrefetch

to true in about:config.