Unbound not using DNSSEC for ROOT

4o4rh

I am using DNS Resolver in caching mode.

It appears that it connects to the root servers via 53 despite having selected to use DNSSEC.
A packet trace shows only traffic on 53 and not 853.

I understood ROOT Zone supports DNSSEC, so it should be possible to block 53 on the WAN/VPN ports.

Why is this so, and despite having Block IP4/6 on all interfaces, why is it still passing 53?

Gertjan

@gwaitsi said in Unbound not using DNSSEC for ROOT:

It appears that it connects to the root servers via 53 despite having selected to use DNSSEC.
A packet trace shows only traffic on 53 and not 853.

Probably because the big 13 do not listen on their 853 port ?!

Re read the definition of DNSSEC ^^
DNSSEC is all about obtaining valid DNS information.
It's not about encrypting. Example : https://serverfault.com/questions/912948/are-dns-queries-encrypted

root servers - and all the others, will probably be '853' compatible' in the future, but .... the load on a server to encode everything - and decoding on the other side, is huge. Latency will suffer.
And what the heck, why should it be hidden that you want to know what the IP is for microsoft.com ? Everybody knows that already.

@gwaitsi said in Unbound not using DNSSEC for ROOT:

I understood ROOT Zone supports DNSSEC, so it should be possible to block 53 on the WAN/VPN ports.

I don't know the numbers, but one thing is sure : block DNS (port 53) and then look for the main power switch , because all 'URL' communication just stopped ...
"DNS over SSL/TLS" is purely optional, as DNNSEC, as IPv6 ....

@gwaitsi said in Unbound not using DNSSEC for ROOT:

why is it still passing 53?

DNS goes over 53.
Want to stop outgoing traffic over 53 ? Just stop unbound (or the Forwarder). Block also all incoming 'port 53 TCP & UDP' traffic on all internal interfaces (LAN's) and you'll be fine. No more outgoing traffic to any port 53. Consider using a floating rule for this.
But again, your Internet experience will become very painful. Go for the switch again.

4o4rh

This post is deleted!

4o4rh

@Gertjan so how do i know, or how can i confirm that dnssec is being used?

this brings me back to my original problem. with unbound (not in forwarding mode) dns leak test shows my IP.
if i put in forwarding mode, my isp is not shown.

How can i have in cache mode, without my ISP? can i block 53 over the WAN interface?

kiokoman

@Gertjan said in Unbound not using DNSSEC for ROOT:

DNSSEC

I think you're doing some confusion
DNSSEC (short for DNS Security Extensions) adds security to the Domain Name System to prevent MITM
it's only useful for Authoritative DNS
it has nothing to do with DOT that listen on port 853

4o4rh

@kiokoman ok, so there are two issues as i see it.

using unbound in cache mode is exposing me WAN ISP.
dig com. SOA +dnssec does not return the AD flag as the unbound manual describes

i would like to solve both of these issues with the 1st one the priority

my rules operate correctly. i.e. everything goes over VPN excluding China GEO IPs and VPNBYPASS hosts.
They all go over the WAN directly. traceroute shows the correct path for each class as does icmp

kiokoman

https://www.netgate.com/blog/dns-over-tls-with-pfsense.html
https://forum.netgate.com/topic/139771/setup-dns-over-tls-on-pfsense-2-4-4-p2-guide
https://www.reddit.com/r/PFSENSE/comments/bywvxr/dns_over_tls_cloudflare/

Gertjan

@kiokoman said in Unbound not using DNSSEC for ROOT:

DNSSEC (short for DNS Security Extensions) adds security to the Domain Name System to prevent MITM

Yep.
I'm using it on all my domains since day 1.
All my domains are on my own authoritative name servers.

@kiokoman said in Unbound not using DNSSEC for ROOT:

I think you're doing some confusion
it has nothing to do with DOT that listen on port 853

@gwaitsi wanted to use / force "DNS over TLS" (or for short : DoT) - and related it to DNSSEC .... at least, I guess he was.
These two are distinct technologies - having only the word DNS in common.

edit : again : https://serverfault.com/questions/912948/are-dns-queries-encrypted removes all the confusions ....

4o4rh

@Gertjan ok, so the problem

i had WAN enabled as outgoing interface, to allow the OpenVPN client to lookup the client address. I have switched to hard coded IPs and disabled the WAN interface, so the DNS Leak issue is solved.

Leaves me with the remaining problem. DNSSEC appears not to be used for the Root Zone servers.
According to the docs below, if i go dig com. SOA +dnssec
https://nlnetlabs.nl/documentation/unbound/howto-anchor/

I get the below from the pfsense box.

; <<>> DiG 9.12.2-P1 <<>> com. SOA +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7140
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;com.				IN	SOA

;; ANSWER SECTION:
com.			900	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 1568973101 1800 900 604800 86400
com.			900	IN	RRSIG	SOA 8 1 900 20190927095141 20190920084141 17708 com. nmkAwVvNUofbMMHMSogTNY2G3sUPJFKR7z+tLNS+KksACn41n0/WLMOg ZDbry+2LXMtCw0dRel0gS5/X+isD2wgNjQtKbAQRLLbBYHHpqmJWC2Yj kTw4CIr1wQUKQh63a3NN19kDTDk8uFHyyw3AFWDZcnZ7y9sd7f+vUx7o AYs=

;; Query time: 27 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 20 11:52:06 CEST 2019
;; MSG SIZE  rcvd: 268

johnpoz

And you see there ad set right

4o4rh

@johnpoz but if i run
unbound-host -C /var/unbound/unbound.conf www.nic.cz.

i get the following error

[1568973734] libunbound[79092:0] notice: init module 0: validator
[1568973734] libunbound[79092:0] error: unable to open /root.key for reading: No such file or directory
[1568973734] libunbound[79092:0] error: error reading auto-trust-anchor-file: /var/unbound/root.key
[1568973734] libunbound[79092:0] error: validator: error in trustanchors config
[1568973734] libunbound[79092:0] error: validator: could not apply configuration settings.
[1568973734] libunbound[79092:0] error: module init for module validator failed
resolve error: initialization failure

johnpoz

If the dnssec failed you would not get a response..

Do a simple test..

$ dig sigfail.verteiltesysteme.net

; <<>> DiG 9.14.4 <<>> sigfail.verteiltesysteme.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16658
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; Query time: 4908 msec
;; SERVER: 192.168.3.10#53(192.168.3.10)
;; WHEN: Fri Sep 20 05:05:50 Central Daylight Time 2019
;; MSG SIZE  rcvd: 57

Does it FAIL with servfail - then dnssec is being used and working.

Does this come back ok

; <<>> DiG 9.14.4 <<>> sigok.verteiltesysteme.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17311
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sigok.verteiltesysteme.net.    IN      A

;; ANSWER SECTION:
sigok.verteiltesysteme.net. 3599 IN     A       134.91.78.139

;; Query time: 648 msec
;; SERVER: 192.168.3.10#53(192.168.3.10)
;; WHEN: Fri Sep 20 05:07:09 Central Daylight Time 2019
;; MSG SIZE  rcvd: 71

4o4rh

@johnpoz confirmed. both results, same as yours. thx m8

johnpoz

Also just go here with your browser pointing to pfsense for dns

https://dnssec.vs.uni-due.de/

Start the test - do you get the thumbs up?

kiokoman

i don't know if it's because unbound is chrooted anyway you are not supposed to launch unbound-host from the terminal,
as you can see it's unable to open /root.key for reading: No such file or directory .. i should look for why but i don't care as i'm not using unbound , in any case if you try with..

unbound-anchor
unbound-host www.nic.cz.
www.nic.cz. has address 217.31.205.50
www.nic.cz. has IPv6 address 2001:1488:0:3::2

or

[2.4.4-RELEASE][root@pfSense.localdomain]/var/unbound: cp root.key /
[2.4.4-RELEASE][root@pfSense.localdomain]/var/unbound: unbound-host -C /var/unbound/unbound.conf www.nic.cz.
[1568975549] libunbound[50915:0] notice: init module 0: validator
[1568975549] libunbound[50915:0] notice: init module 1: iterator
[1568975549] libunbound[50915:0] info: generate keytag query _ta-4f66. NULL IN
www.nic.cz. has address 217.31.205.50
www.nic.cz. has IPv6 address 2001:1488:0:3::2

johnpoz

Good follow through @kiokoman thanks.. There are many ways to validate that dnssec is actually working - looking for the ad when doing dig +dnssec is prob the easiest.. Or just doing query to a test fqdn that is set to fail..