How can I tell whether DNSSEC is working?

I would like to be certain that DNSSEC is enabled, and really is being used for name resolution. In the log messages I don’t see anything about DNSSEC. Would there be some notification if DNSSEC is turned off or the upstream DNS server does not support it?

Dnsmasq added DNSSEC support recently. Will Omnia continue to use Knot?

All i know is when you go to Foris–>DNS and then test connection. You will have the results there and you will see if it is working or not.

Go to this page: http://www.dnssec.cz/. /You can set language to ENG./. green key -> you are safe. :slight_smile:

Michal

P. S. It´s safe, this site is maintained by NIC.cz too (along with Knot resolver, all Turriss versions…).

2 Likes

The simplest solution is to try to resolver one of the domains that are deliberately DNSSEC-broken for testing. An example (192.168.2.254 is my Turris Omnia:

% dig @192.168.2.254 A servfail.nl

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> @192.168.2.254 A servfail.nl
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35638
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;servfail.nl.		IN A

;; Query time: 148 msec
;; SERVER: 192.168.2.254#53(192.168.2.254)
;; WHEN: Wed Dec 21 15:54:08 CET 2016
;; MSG SIZE  rcvd: 40

SERVFAIL is normal, the domain has been broken on purpose.

Ideally, you could run dig with the +cd option (Checking Disabled) and therefore see the data. Unfortunately, a bug in the Knot resolver prevents it :frowning: https://gitlab.labs.nic.cz/knot/resolver/issues/97

Also, when testing signed domains, you should see a AD (Authentic Data) flag. Another bug of the resolver prevents this simple test :frowning:

1 Like

Thanks! Firefox on Android phone gives RED key. Firefox on Win7 laptop gives GREEN key. Both using same Omnia wifi.

I think I understand now.

When “Use forwarding” is enabled, Knot doesn’t do DNSSEC validation. Then DNSSEC validation depends on the upstream DNS server. Knot could forward a request to either of the two upstream DNS servers specified on the Foris WAN page. Mine were 8.8.8.8 (which validates DNSSEC) and 4.2.2.6 (which does not). So DNSSEC validation occurred sometimes, depending on which upstream DNS server was used.

In forwarding mode, apparently there is no protection for the traffic between the Omnia and the upstream DNS servers.

When I turned forwarding off, Knot did the DNSSEC validation, no matter which upstream server was used.

Unfortunately, Knot seemed unable to resolve openwrt.org then. (openwrt.org has 3 name servers, and on that day 2 of them were unreachable - maybe Knot didn’t try them all?) To access openwrt.org I had to turn forwarding back on.

Even with forwarding on, three times Knot has gone stupid and failed all requests, and this was solved only by rebooting the Omnia. So I think I will turn off Knot and try Dnsmasq instead.

Knot was sensitive to some cases when a large fraction of servers for a name was down, especially when the nameservers for these names were “under” the names. It should be significantly improved now (in the following release).

I’ll try again after the next auto update.

Note: it might not be in the next TO update. I meant the next release of knot-resolver.

Problem still exists after auto update to version 4.4.39-80079e1c1e5f9ca7ad734044462a761a-3
With forwarding off, knot still doesn’t resolve wiki.openwrt.org

Yes, the yesterday’s update contained no knot-resolver fixes, except for configuration update to really forward to multiple servers instead of the first one.

Thanks for the domain that doesn’t work; such test cases help us to eradicate the bugs.