:: Re: [DNG] Unbound details: was Mozi…
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Steve Litt
日付:  
To: dng
題目: Re: [DNG] Unbound details: was Mozilla and cloudflare to hijack all your DNS requests - for your own good of course
I've found the way for Unbound itself to do simple on-subnet auth
without a separate auth server, and will reveal them tomorrow.

Thanks.

SteveT

On Sun, 19 Aug 2018 21:22:40 -0400
Steve Litt <slitt@???> wrote:

> On Tue, 7 Aug 2018 13:27:25 -0700
> Rick Moen <rick@???> wrote:
>
>
> > Most highly rated comment:
> >
> > I run my own local recursive nameservers even on my portable
> > devices. Totally not interested in using anyone's resolvers but my
> > own.
> >
> > Ding!
> >
> > 1. apt-get install unbound
> > 2. sed -i '1s;^;nameserver 127.0.0.1\n;' /etc/resolv.conf
>
> So it's been about 2 weeks I've been using unbound, and subjectively,
> my web browsing has slowed, compared to the straight 8.8.8.8 and
> 8.8.4.4 I used before. Sometimes the browser's status bar says
> "resolving" during those delays, and sometimes it doesn't.
>
> It's been about 4 or 5 years since I last used djbdns, but IIRC I
> didn't have such delays with djbdns.
>
> So there may come a time when I'll be asking you for the name of a
> different caching DNS server. But first, I just five minutes ago read
> the info on:
>
> https://nlnetlabs.nl/documentation/unbound/howto-optimise/
>
> and based on that configured my 2 core, 16gRAM Daily Driver Desktop as
> follows:
>
> ========================================================
> ### BE SURE to use unbound-checkconf
> ### before enabling a changed conf file!
>
>
> # FORWARD-ZONE SECTION!!!!!!!!!!!!!!!!
> # The following is how you query google DNS instead of root servers
> # I chose to query the root servers and commented it out.
> #forward-zone:
> #name: "."
> #forward-addr: 8.8.8.8
> #forward-addr: 8.8.4.4
>
>
> # REMOTE-CONTROL SECTION!!!!!!!!!!!!!!
> # Enable use of unbound-control
> # Remote control is very, very useful
> # Use judgement re security
> # Use doublequotes on filenames, unbound should read them
> # from /etc/unbound
> # Create keys and certs by running unbound-control-setup
> remote-control:
> control-enable: yes
> control-use-cert: yes
> server-key-file: "unbound_server.key"
> server-cert-file: "unbound_server.pem"
> control-key-file: "unbound_control.key"
> control-cert-file: "unbound_control.pem"
>
>
>
> # SERVER SECTION!!!!!!!!!!!!!!!!!!!!!!
> server:
> use-syslog: yes
>
> # Guard against future default changes: no systemd ever!
> use-systemd: no
>
> # Speed UDP
> so-reuseport: yes
>
> # use all CPU cores, I have 1 CPU with 2 cores
> num-threads: 2
>
> # power of 2 close to num-threads
> msg-cache-slabs: 2
> rrset-cache-slabs: 2
> infra-cache-slabs: 2
> key-cache-slabs: 2
>
> # more cache memory, rrset=msg*2
> rrset-cache-size: 100m
> msg-cache-size: 50m
>
> # more outgoing connections
> # depends on number of cores: 1024/cores - 50
> outgoing-range: 450
>
> # Larger socket buffer.
> # OS may need config, so I don't use it
> #so-rcvbuf: 4m
> #so-sndbuf: 4m
>
> # Faster UDP with multithreading (only on Linux).
> so-reuseport: yes
>
> # Other stuff, see
> # https://www.tecmint.com/setup-dns-cache-server-in-centos-7/
> # Enable dig command with allow_snoop
> access-control: 0.0.0.0/0 allow_snoop
> ========================================================
>
> The preceding assumes you have quite a bit of RAM, and it's based on
> having 2 cores.
>
> Subjectively, the preceding configuration improved my lookup speed.
>
> Everyone please understand that as far as I know, there's no automatic
> storage of cache to disk before a reboot or before downing, restarting
> or reloading unbound. Do any of those things and you lose all cache,
> so web browsing will be slow when hitting any website, including ones
> that came right up before your action. For debugging purposes, I
> created the following shellscript:
>
> ==============================================================
> #!/bin/sh
> rm temp.cache
> unbound-control dump_cache > temp.cache
> #unbound-control reload
> unbound-control stop
> unbound-control start
> unbound-control load_cache < temp.cache
> ==============================================================
>
> In the preceding, users of runit should substitute "sv stop unbound"
> and "sv start unbound" for the equivalent unbound-control commands:
> Works much better and really dumps cache before the cache reload.
>
> The preceding completely restarts unbound without a significant loss
> of cache (but with a full reread of /etc/unbound/unbound.conf. Notice
> that unbound seems to poll its config file, because changes you make
> to /etc/unbound/unbound.conf *sometimes* produce changed behavior
> immediately, without rereading, restarting hupping, etc. By the way, I
> couldn't find anywhere documentation on what it does when receiving a
> hup. I do know from runit that hupping doesn't stop and restart,
> because the uptime doesn't change.
>
> Lookup speed is very important when web browsing because modern
> websites access many, many domains. For instance, when I browsed
> jeep.com and ran:
>
> unbound-control dump_cache | wc
>
> Browsing jeep.com added over 2000 to the number of lines of cache.
> Even the minimal site Troubleshooters.Com added 240. No wonder
> browsing can be so slow with inadequate cache, or with an unbound
> instance that just recently started.
>
> In summary, if you simply install and use unbound, without tweaking
> it, you might perceive some slowness. If you do what's in this email,
> I think it will be much better. And remember, resolution is always
> going to be slow right after a reboot.
>
>
> SteveT
>
> Steve Litt
> September 2018 featured book: Quit Joblessness: Start Your Own
> Business http://www.troubleshooters.com/startbiz
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng