HOWTO - DNS Security / Unbound DNS with DNSCrypt, DoH Plugin for IPv4 + IPv6

Started by p1n0ck10, December 13, 2018, 10:14:12 PM

Previous topic - Next topic
Ah, yes, you can add as many loopback ips as you like, or just use a different port

Thanks,

In BIND, you can't set Port for Forwarder in GUI.

Should ::8 work for ipv6?
And wich Adapter I shoud set?
Loopback?


Greets

Byte

Hi guys,

I have OPNSense installed as a VM in a Proxmox homelab test server for the purpose of trial and error (the first error is that the PC only has one physical NIC).

I setup Unbound and DNSCrypt as described in this excellent HowTo. Now to the odd behaviour:

If I use the automatic DNS option for a client, I get the expected ISP running a dnsleaktest.com extended test and if I set a DNS like the fallback resolver specified in DNSCrypt, then I get that.
However, if I set the OPNSense VM as the sole DNS then nothing will be resolved. Yet, if I specify a second DNS name server, like the one used as fallback resolver, then I do get DNScrypt results. Even more strange, I don't exclusively get DNSCrypt name server, but also the odd amazon, google and similar?!?

Running "dnscrypt-proxy -resolve opnsense.org" and "unbound-host opnsense.org" don't return anything unexpected.

Has anyone seen that before and/or any idea how to solve it?

I am new to the topic and any help and advise would be much appreciated.


Hello Guys, following this tutorial, I deployed DNSCrypt and it's working. Is it possible to use this service in conjunction with a Transparent Proxy?

Hi All,
I followed the tutorial and DNSSEC works fine for ipv4 but I get no access on IPv6. All the tests fail on IPv6.
I made sure that IPv6 was enabled and added to the rules.
Is there something more basic I am missing? Gateway maybe? NIC properties?

[UPDATE]
I am now able to get IPv6 DNS. I set the WAN Interface IPv6 Configuration type to DHCPv6 with a PD of 60 and my two LAN interfaces to 'Track Interface', each with a different Prefix ID. I could not find info on how to get multiple LAN interfaces to work with IPv6 anywhere, so hopefully this info will help someone.

If this approach is incorrect, please post here.

[UPDATE2]
Seems all my proxys didn't work because they were using IPv6 addressing, so I changed Settings>General>Prefer IPv4 over IPv6 to checked, and now everything works again.
Again, if this wasn't the correct way to handle this, please advise.

Thanks

I have set the Unbound + DNSCrypt-proxy bundle as described, for it makes sense.
Unfortunately, some of the requests seems to fail from my computer.
Further investigation revealed the following:

1. The cache sometimes causes trouble
When DNSCrypt-proxy restarts for too long, Unbound panics and says that all is lost, and then my macOS caches that there is no IP for the name, and I get a blank page.
This behaviour can be eliminated with forward-first: yes, as someone mentioned, but this poses obvious disadvantages.
Another possibility is forward-no-cache: yes, but that might be even worse.
Now, a better option is to enable Unbound DNS :: Advanced :: Serve expired responses, because the most affected records are short-TTL ones.

2. DNSSEC hardening causes trouble
When Unbound DNS :: Advanced :: Harden DNSSEC data is enabled (a naive thing to do, it was), this often happens:
2021-06-20T03:33:04 unbound[76608] [76608:0] debug: validator[module 0] operate: extstate:module_wait_module event:module_event_moddone
2021-06-20T03:33:04 unbound[76608] [76608:0] info: validator operate: query wiki.mageia.org. A IN
2021-06-20T03:33:04 unbound[76608] [76608:3] debug: verify: signature mismatch

Disabling the option solves the problem.

Now, what I don't understand at all is that when I change forwarders from DNSCrypt to 9.9.9.9@53, it seems fine (with other settings unchanged):

2021-06-20T15:57:58 unbound[13980] [13980:1] debug: validator[module 0] operate: extstate:module_wait_subquery event:module_event_pass
2021-06-20T15:57:58 unbound[13980] [13980:1] info: validator operate: query wiki.mageia.org. A IN
2021-06-20T15:57:58 unbound[13980] [13980:1] info: Verified that unsigned response is INSECURE

Does it mean that DNSCrypt somehow tries to sign that's unsigned, causing frustration in Unbound?..

Some awkward behaviour is also visible around them new TYPE65 requests, but I did not reveal anything specific.

3. Even when all works, Unbound seems to treat forwarders inefficiently

2021-06-20T15:57:57 unbound[13980] [13980:1] info: resolving wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: processQueryTargets: wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: sending query: wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] debug: sending to target: <.> 9.9.9.9#53
2021-06-20T15:57:57 unbound[13980] [13980:1] debug: cache memory msg=138269 rrset=146053 infra=10617 val=136881
2021-06-20T15:57:57 unbound[13980] [13980:1] debug: iterator[module 1] operate: extstate:module_wait_reply event:module_event_reply
2021-06-20T15:57:57 unbound[13980] [13980:1] info: iterator operate: query wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: sanitize: removing extraneous answer RRset: sucuk.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: response for wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: reply from <.> 9.9.9.9#53
2021-06-20T15:57:57 unbound[13980] [13980:1] info: query response was CNAME
2021-06-20T15:57:57 unbound[13980] [13980:1] info: resolving wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: processQueryTargets: wiki.mageia.org. A IN
2021-06-20T15:57:57 unbound[13980] [13980:1] info: sending query: sucuk.mageia.org. A IN


So, what I read from this, when Unbound gets CNAME instead of A, it does query for that A, but first complains that it is from another domain. I am mildly concerned that this is not right.

Recommendations for the tutorial

  • Add a suggestion to enable Unbound DNS :: Advanced :: Serve expired responses.
  • Add a suggestion to disable Unbound DNS :: Advanced :: Harden DNSSEC data.
  • Propose a consensus for DNSBL: it is possible to use them in either DNSCrypt-Proxy or Unbound, but some advice might be helpful for users. My personal opinion is that Unbound is a better place (as of 21.4), but that might be debatable.
  • Investigate the extraneous RRSet magic.

Thank you for the attention.

How to solve the wrong boot load order?

Unbound loads early, before DNSCrypt is loaded. Unbound fails to connect to DNSCrypt and reports error. The error persist until DNSCrypt is loaded AND Unbound is restarted.

More details here: https://forum.opnsense.org/index.php?topic=23606.0

I configured my unbound & dnscrypt-proxy as described in the first post.

Unfortunatley it doesn't work right.
While some domains are working fine others can't be resolved at all.

query.log of dnscrypt-proxy shows like this:


[2021-07-12 16:46:13]   127.0.0.1       office365.com   DS      PASS    11ms    NextDNS-Primary
[2021-07-12 16:46:13]   127.0.0.1       office365.com   DS      PASS    0ms     -
[2021-07-12 16:46:13]   127.0.0.1       office365.com   DS      PASS    0ms     -
[2021-07-12 16:46:13]   127.0.0.1       office365.com   DS      PASS    0ms     -
[2021-07-12 16:46:13]   127.0.0.1       office365.com   DS      PASS    0ms     -
[2021-07-12 16:46:13]   127.0.0.1       office365.com   DS      PASS    0ms     -
[2021-07-12 16:46:22]   127.0.0.1       community.librenms.org  A       PASS    0ms     -
[2021-07-12 16:46:22]   127.0.0.1       librenms.org    DS      PASS    0ms     -
[2021-07-12 16:46:22]   127.0.0.1       librenms.org    DS      PASS    0ms     -
[2021-07-12 16:46:22]   127.0.0.1       librenms.org    DS      PASS    0ms     -
[2021-07-12 16:46:22]   127.0.0.1       librenms.org    DS      PASS    0ms     -
[2021-07-12 16:46:22]   127.0.0.1       librenms.org    DS      PASS    0ms     -
[2021-07-12 16:46:22]   127.0.0.1       librenms.org    DS      PASS    0ms     -
[2021-07-12 16:46:22]   127.0.0.1       beacons.gvt2.com        A       PASS    0ms     -


As you can see the first request was working while all the others end with "PASS" but with the "-" in the end of the line instead the selected DNS-Server profile.

Unbound custom options:

server:
tls-cert-bundle: "/etc/ssl/cert.pem"
local-zone: "use-application-dns.net" always_nxdomain
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5354


dnscrypt-proxy is listening on 127.0.0.1:5354 and does get the requests forwarded by unbound, so this shouldn't be the issue.

Any ideas why this does happen?

Edit:
I can solve the issue by uncheck "Enable DNSSEC Support" in unbound settings.
I do not like to disable DNSSEC support. So is there a other way to get it working?

I followed this tutorial (but I do have the DNS servers set in the general settings) and I have issues after a while, where Unbound fails (but DNScrypt remains working).

Unbound:

# dig @127.0.0.1 docs.ruckuswireless.com

; <<>> DiG 9.16.18 <<>> @127.0.0.1 docs.ruckuswireless.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39747
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;docs.ruckuswireless.com.       IN      A

DNScrypt:
# dig @127.0.0.1 -p5300 docs.ruckuswireless.com

; <<>> DiG 9.16.18 <<>> @127.0.0.1 -p5300 docs.ruckuswireless.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19463
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;docs.ruckuswireless.com.       IN      A

;; ANSWER SECTION:
docs.ruckuswireless.com. 599    IN      CNAME   docs.ruckuswireless.com.cdn.cloudflare.net.
docs.ruckuswireless.com.cdn.cloudflare.net. 599 IN A 104.20.41.32
docs.ruckuswireless.com.cdn.cloudflare.net. 599 IN A 104.20.42.32

;; Query time: 35 msec
;; SERVER: 127.0.0.1#5300(127.0.0.1)
;; WHEN: Tue Jul 27 12:24:22 CEST 2021
;; MSG SIZE  rcvd: 140


Anyone knows what could be happening?

Dear @p1n0ck10 and others,

Does this DOH still work on opnsense 21.7 ?
Since unbound dns - custom options is removed (?)
I followed your guide and have this in the custom options added:
server:
do-not-query-localhost: no

forward-zone:
   name: "."
   forward-addr: 127.0.0.1@5353
   forward-addr: ::1@5353

Can I upgrade to opnsense 21.7 or what should we alter where in the opnsense gui to keep DoH running like it should???
Deciso DEC850v2

https://forum.opnsense.org/index.php?topic=23929.msg115176#msg115176

is the solution, but you need to mess around with console and these things don'T end in config.xml, so you need to restore this manually for any new install.

Or you install the plugin from the community repo (mimugmail) for the custom options field after updating to 21.7

https://forum.opnsense.org/index.php?topic=23929.msg114064#msg114064
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

Thanks for the link, but Owh, messing around with the console doesn't sound very promising....
Should we better switch from DoH to DoT than? Since that is more straight forward?
As I just read here: https://homenetworkguy.com/how-to/configure-dns-over-tls-unbound-opnsense/

I thought that DoH was the " better" solution over DoT ?
Deciso DEC850v2

Better as in what? ;-)

I use DoT and there is a page in 21.7 for that, together with CNAME minimisation under "Advanced" settings for unbound you are for most things on the not-so-unsafe side. Choose some servers you want to trust, I posted my choice in the thread linked above.

Or you install the plugin for the custom stuff in unbound from mimugmail. Choose your weapon...

kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

QuoteBetter as in what? ;-)
good question :-)
When learning about DoT and DoH I read this: "However, from a privacy perspective, DoH is arguably preferable. With DoH, DNS queries are hidden within the larger flow of HTTPS traffic. This gives network administrators less visibility but provides users with more privacy."

And that made me choose DoH back than...

But I'm also looking at opnsense and read about the native DoT usage in Unbound, added with the latest update of opnsense loosing the DoH custom option in Unbound, made we switch to DoT and keeps things over here easy to manage and update future proof without having to "mesh around in the console" :-)

Thanks for your help!
Running DoT works as a charm...
Deciso DEC850v2