Re: DGA Attack mitigation

[manu tman via Unbound-users]

unbound has a bunch of `ratelimit` options that may help you out.

On Tue, Apr 10, 2018 at 12:27 AM, W.C.A. Wijngaards via Unbound-users <
unbound-users@unbound.net> wrote:

> Hi Mahdi,
>
> This may not be what you are looking for but the just released
> aggressive-nsec: yes option uses DNSSEC aggressive NSEC processing to
> cache more NXDOMAINs per upstream lookup, and more quickly respond to
> NXDOMAINs, resulting in less upstream traffic and less load on the
> server for NXDOMAINS.
>
> Best regards, Wouter
>
> On 10/04/18 08:45, Mahdi Adnan via Unbound-users wrote:
> > Thank you all for your response,
> >
> >
> > --
> >
> > Respectfully*
> > **Mahdi A. Mahdi*
> >
> > 
> > *From:* Paul Vixie 
> > *Sent:* Monday, April 9, 2018 11:37 PM
> > *To:* Rainer Duffner
> > *Cc:* Mahdi Adnan; unbound-users@unbound.net
> > *Subject:* Re: DGA Attack mitigation
> >
> >
> >
> > Rainer Duffner via Unbound-users wrote:
> >>
> >>
> >>> Am 09.04.2018 um 20:04 schrieb Mahdi Adnan via Unbound-users
> >>> >:
> >>>
> >>> Im running 20 Unbound servers and around 20% of response are NXDOMAIN,
> >>> for queries coming from my clients.
> >>
> >>
> >>
> >> Block those IPs that are obviously p4wned until they clean up their PCs?
> >
> > the source addresses are forged. the victims are not unclean in any way.
> > this is why rrl exists.
> >
> > -- P Vixie
> >
>
>
>

Re: Unbound with DNSCrypt configuration

[manu tman via Unbound-users]

Hi Peter,

I think you are mixing up how DNScrypt in unbound work. By using:
```
interface: 0.0.0.0@443
interface: ::0@443

##DNSCRYPT
dnscrypt:
dnscrypt-enable:yes
dnscrypt-port:443
dnscrypt-provider:2.dnscrypt-cert.cryptostorm.is.
dnscrypt-secret-key:/usr/local/etc/unbound/1.key
dnscrypt-provider-cert:/usr/local/etc/unbound/1.cert

###
```

Unbound will create a DNSCrypt server that will listen on port 443. Its
provider name will be 2.dnscrypt-cert.cryptostorm.is. and it will use
cert/key /usr/local/etc/unbound/1.{cert,key} .

I am under the impression that you think it will connect to `5.101.137.251`
over DNSCrypt. this is the role of DNSCrypt proxy instead.

When you add:
```
forward-zone:
name: "."
forward-addr:5.101.137.251
```
to the config, unbound will forward request to 5.101.137.251 and will
behave as a caching server. Because 5.101.137.251 also handles clear text
DNS, this is working just fine and that IP is showing through the website
you mentioned.

When you remove the forward-zone, unbound will behave as a recursive
resolver and DNS queries will show up as coming from your DNS server to the
outside world.

I think you are mis-understanding what role Unbound has in DNSCrypt setup.
Essentially, the config you are providing is the one that cryptostorm.is
would use if they were going to set up a DNSCrypt server (aside from the
forward-zone bit).

TL;DR you want to install DNSCrypt proxy. The original author is working on
a new version: https://github.com/jedisct1/dnscrypt-proxy .

Manu

On Tue, Jan 23, 2018 at 5:46 AM, peter.newey--- via Unbound-users <
unbound-users@unbound.net> wrote:

> Hello
>
> I am using unbound from Git version: 1.6.9 and have compiled it  with
> --enable-dnscrypt .
> This is my unbound.conf setup;
>
> # unbound.conf for a local subnet.#
> server:
> interface: 0.0.0.0
> interface: ::0
> access-control: 192.168.0.0/16 allow
> access-control: ::1 allow
>
> # DNSCRYPT server: ###
> interface: 0.0.0.0@443
> interface: ::0@443
>
> directory: "/usr/local/etc/unbound"
> chroot: ""
> username: ""
> verbosity:0
> num-threads: 1
> prefetch:yes
> prefetch-key:yes
> use-syslog:no
> do-ip6: no
> so-reuseport: yes
> module-config: "validator iterator"
>
> do-not-query-localhost: no
>
> # file to read root hints from.
> #get one from ftp://FTP.INTERNIC.NET/domain/
> root-hints: "/usr/local/etc/unbound/named.cache"
> 
> include: "/usr/local/etc/unbound/unbound_ad_servers"
> #update the above file by using below command as root  :
> #curl -sS -L --compressed "http://pgl.yoyo.org/
> adservers/serverlist.php?hostformat=unbound=0=plaintext"
> > /usr/local/etc/unbound/unbound_ad_servers
>
> logfile: "/usr/local/etc/unbound/unbound.log"
>
> log-time-ascii:yes
>
>  
>
>  #auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
> #root key file, automatically updated# remove # only for DNSSEC capable
> dns servers ##
>  
>
> #Remote control config section.
> remote-control:
> # Enable remote control with unbound-control(8) here.
> # set up the keys and certificates with unbound-control-setup.
>  control-enable:yes
>
> ##DNSCRYPT
> dnscrypt:
> dnscrypt-enable:yes
> dnscrypt-port:443
> dnscrypt-provider:2.dnscrypt-cert.cryptostorm.is.
> dnscrypt-secret-key:/usr/local/etc/unbound/1.key
> dnscrypt-provider-cert:/usr/local/etc/unbound/1.cert
>
> forward-zone:
> name: "."
> forward-addr:5.101.137.251
>
> ###
>
> The only lines I see in my unbound.log  where dnscrypt is mentioned is
> this line that is repeated occasionally :
>
> Jan 23 05:35:12 unbound[32581:0] notice: DNSCrypt: Freeing environment.
>
> If I use the above unbound.conf and look on website https://whoer.net/
> it shows my own ISP i.p address correctly and DNS 5.101.137.251
> correctly, which belongs to  dnscrypt-provider:2.dnscrypt-
> cert.cryptostorm.is.
>
> If I change it to :
> #forward-zone:
>   # name: "."
> #forward-addr:5.101.137.251
>
> my DNS address then shows my own ISP DNS , but I presume it should show
> 5.101.137.251 if dnscrypt was working correctly.
>
>
> If I change it to :
>
> #dnscrypt:
># dnscrypt-enable:yes
> #dnscrypt-port:443
> #dnscrypt-provider:2.dnscrypt-cert.cryptostorm.is.
> #dnscrypt-secret-key:/usr/local/etc/unbound/1.key
> #dnscrypt-provider-cert:/usr/local/etc/unbound/1.cert
>
> forward-zone:
> name: "."
>   

Re: Load a certificate without restart

[manu tman via Unbound-users]

Hi Sebastian,

There is currently no easy way to rotate the certificates without
restarting unbound.

You can gracefully rotate certs by using
https://github.com/NLnetLabs/unbound/commit/52e2331dd495ca820c631d9aab6649455cb0c6e5#diff-47ddff7bf6b45ab98520775e2a29b9fd
to advertise new certs while still handling the connections with the old
ones, or more broadly if you have multiple servers that may receive queries:
- start priming the new cert in (-rotated) mode so all servers could handle
the new cert while not necessarily advertising it
- once all servers have the new cert, move the old cert to -rotated, and
remove the new one from -rotated after restarting, the new cert will be
advertised while clients still using the old cert, will be able to query
until they refresh their cert.

This does not solve the restart issue and the flushing of the cache, but if
you have a way to gracefully take servers in and out of the pool, this will
allow you to gracefully rotate the certs.

Manu

On Thu, Jan 4, 2018 at 4:37 AM, Sebastian Schmidt via Unbound-users <
unbound-users@unbound.net> wrote:

> Hello,
>
> I'm wondering if unbound has a method where a new certificate can be
> loaded without restarting unbound. This would be helpful when loading for
> short-lived (1 day) DNSCrypt certificates and potentially for TLS certs
> from Let's Encrypt (3 Months). Ideally unbound would run forever without a
> restart when deploying secure transport for DNS.
> I've attempted to write a auto-renew script: https://gist.github.
> com/publicarray/a246106b5a6821b69b86e8d05ee41896
> But the problem is that I haven't found a way to tell unbound of the new
> cert without restarting the daemon. If there is a way I can't see it
> documented.
>
> Not related but can someone tell me if using `serve-expired: yes` has some
> security risk? basically I'm trying to evaluate whether is better or worse
> than setting `cache-min-ttl: 1800`. The server has low usage and is in
> Australia. So on average the lookup time is around 350ms and I like to
> serve more replies from the cache.
>
> Also may I ask on the progress on TLS-over-DNS? https://
> dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status Lists
> OOOR and EDNS0 Keepalive as WIP
>
> Thanks,
> Sebastian
>
>
>
>
>

Re: DNSCrypt - Public key in Python Module

[manu tman via Unbound-users]

Hi Nick,

I have little experience with the python module, but based on how the
dnscrypt protocol is made, you could find out which certificate was chosen
based on the client magic:
https://github.com/jedisct1/dnscrypt-proxy/blob/master/DNSCRYPT-V2-PROTOCOL.txt#L55

Manu

On Tue, Dec 5, 2017 at 8:19 AM, Nick via Unbound-users <
unbound-users@unbound.net> wrote:

> Hi,
>
> I am playing with the DNSCrypt support in unbound - seems to be working
> great.
>
> Can you tell me if its possible to get the public key for the request from
> within my python module?
>
> Thanks
>
> Nick
>