3.8 - forwarded DNS resolution not working - even though dig against ISP's DNS servers works fine

dcam · September 14, 2017, 6:50pm

Hi,

I find that DNS is now not working via forward.

The router DNS configuration is pretty much stock standard.

My DNS configuration is:

“use forwarding” is ticked in the foris configuration
“Disable DNSSEC” is not ticked in the foris configuration
“Enable DHCP clients in DNS” is not ticked in the foris configuration

If I untick “use forwarding” then DNS resolution works again, locally.

OpenWrt omnia 15.05 r47055 / LuCI 49c3edd5861fd032fa8379ceda525c27a908a114 branch (git-17.212.24321-49c3edd)

root@turris:/tmp/etc# uname -a
Linux turris 4.4.87-cb5e816fa6b1a6b5342df69755869d71-2 #1 SMP Wed Sep 13 18:51:42 CEST 2017 armv7l n

root@turris:~# ping -c 1 8.8.8.8 | grep “bytes from”
64 bytes from 8.8.8.8: seq=0 ttl=55 time=21.306 ms

root@turris:/tmp/etc# dig www.google.com

; <<>> DiG 9.10.5-P3 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12323
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com. IN A

;; Query time: 66 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 15 05:04:47 AEST 2017
;; MSG SIZE rcvd: 32

root@turris:~# nslookup www.google.com
nslookup: can’t resolve ‘(null)’: Name does not resolve

nslookup: can’t resolve ‘www.google.com’: Try again

root@turris:~# cat /etc/resolv.conf
search lan
nameserver 127.0.0.1

root@turris:/tmp/etc# ps ww | grep dnsmasq
3211 nobody 892 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid
3214 root 888 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid
17309 root 1088 R grep dnsmasq

root@turris:/tmp/etc# cat /tmp/resolv.conf.auto
# Interface wan
nameserver 61.9.211.33
nameserver 61.9.211.1
search telstra.com.au

root@turris:/tmp/etc# dig www.google.com @61.9.211.33

; <<>> DiG 9.10.5-P3 <<>> www.google.com @61.9.211.33
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27915
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.google.com. IN A

;; ANSWER SECTION:
www.google.com. 173 IN A 216.58.199.36

;; Query time: 8 msec
;; SERVER: 61.9.211.33#53(61.9.211.33)
;; WHEN: Fri Sep 15 04:56:35 AEST 2017
;; MSG SIZE rcvd: 59

root@turris:/tmp/etc# dig www.google.com @61.9.211.1

; <<>> DiG 9.10.5-P3 <<>> www.google.com @61.9.211.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4259
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.google.com. IN A

;; ANSWER SECTION:
www.google.com. 145 IN A 216.58.203.100

;; Query time: 12 msec
;; SERVER: 61.9.211.1#53(61.9.211.1)
;; WHEN: Fri Sep 15 04:59:55 AEST 2017
;; MSG SIZE rcvd: 59

The nslookup commands below fail when “use forwarding” is configured:

root@turris:/tmp/etc# nslookup www.google.com 61.9.211.33
Server: 61.9.211.33
Address 1: 61.9.211.33

nslookup: can’t resolve ‘www.google.com’: Try again
root@turris:/tmp/etc# nslookup www.google.com 61.9.211.1
Server: 61.9.211.1
Address 1: 61.9.211.1

nslookup: can’t resolve ‘www.google.com’: Try again

Nslookup on windows on the same network it works fine with explicit server configuration:

C:> nslookup
Default Server: UnKnown
Address: fda5:7a90:47f9::1

server 61.9.211.33
Default Server: [61.9.211.33]
Address: 61.9.211.33

www.google.com
Non-authoritative answer:
Server: [61.9.211.33]
Address: 61.9.211.33

Name: www.google.com
Addresses: 2404:6800:4006:803::2004
216.58.220.100

server 61.9.211.1
Default Server: dns-cust.woo.bigpond.net.au
Address: 61.9.211.1

www.google.com
Non-authoritative answer:
Server: dns-cust.woo.bigpond.net.au
Address: 61.9.211.1

Name: www.google.com
Addresses: 2404:6800:4006:809::2004
216.58.203.100

till · September 14, 2017, 7:24pm

Thank you for the hint with disabling forwarding. It helped here as well after DNS just broke. According to /usr/share/updater/updater-log a lot of updates happened earlier today on my system. I suspect that something is broken with kresd as after disabling forwarding /tmp/kreds.config changed to not included the forwarders anymore and now it is working…

vcunat · September 14, 2017, 8:25pm

The change in 3.8 (corresponding to kresd 1.3.x) is that forwarding now does validate DNSSEC by default. I expect that in your case the servers you forward to obstruct obtaining the necessary records in some way, though it’s hard to be really certain based on the posted information alone.

doctorjames · September 14, 2017, 9:42pm

I’ve just been hit by this too. In the past @vcunat has helped myself and others forward local queries to dnsmasq running on port 5353 via a kresd.custom.conf file. E.g. in the thread: DNS forwarding to a different DNS for the internal lan

From a quick scan of the new documentation, the only change I needed to make was switching from:

policy.add(policy.suffix(policy.FORWARD('127.0.0.1@5353'), policy.todnames( ...

to:

policy.add(policy.suffix(policy.STUB('127.0.0.1@5353'), policy.todnames( ...

Following this change, the setup described in that previous thread appears to be working again.

vcunat · September 14, 2017, 10:23pm

Right, if you specify policies manually, STUB is the old FORWARD, basically (it caches better now). STUB does no validation, so you probably don’t want it for all traffic, but it’s suitable for this use case…

anarcat · September 14, 2017, 10:24pm

aaawesome! i was just about to open a topic about this and noticed this solution. thanks so much! switching from FORWARD to STUB works for me as well.

waffle · September 14, 2017, 10:37pm

Initially, I had DNS issues with the update, due to my custom internal DNS. My issue seemed to stem from the resolver initscript being reenabled after the update, when I have had it disabled in the past to get my setup to work. For clarification, I run Pi-Hole in an LXC container and use that as my DNS for ad/tracker filtering.

This is what I’ve been doing to forward DNS to an internal server. I’d love to know if this is a bad way of doing it.

In LuCI under System -> Startup, ‘Disable’ and ‘Stop’ both the ‘resolver’ and ‘kresd’ initscripts.
Under Network -> Interfaces, click ‘Edit’ on WAN, then ‘Advanced Settings’. Uncheck ‘Use DNS servers advertised by peer’ and in the ‘Use custom DNS servers’ field that appears, enter the IP of the DNS server.
SSH into Omnia and inside /etc/config/dhcp change option port ‘0’ to option port ’53’.

With the update to 3.8, my DNS seemed to break. I think this is because the resolver script was reenabled with the update… that might have been my main issue. Once I disabled it again, confirmed all my settings, everything seems to be working normally again for me. On Foris, I reenabled “use forwarding,” which had been a bandage initially, and it’s still working.

radekpribyl · September 15, 2017, 5:10am

I have the same problem after 3.8 upgrade - basically the DNS is sometimes resolved sometimes isn’t - the same DNS server at ISP. So very difficult to find out what is really happening. I’ll try to disable DNS forwarding.

NYtimebomb · September 16, 2017, 12:42am

Ran into this issue today after the update, as suggested the quick fix is to disable DNS forwarding. I do wish there was finer control over the DHCP/DNS with the default setup, even in the LuCi interface it is quite lacking.

Does anyone have a suggestion for DNSSEC capable servers to forward to?

dcam · September 16, 2017, 4:48am

I manually configured my PC’s DNS to point to my ISPs DNS server IP, and ran the online resolver test at https://dnssec.vs.uni-due.de/

It says:
No, your DNS resolver does NOT validate DNSSEC signatures.

So now I’ve ticked:
Use Forwarding
and
Disable DNSSEC

cynerd · September 16, 2017, 7:20am

Please don’t disable both! That is just making your internet connection insecure. One option is to trust your ISP’s dns server then disable DNSSEC or if you don’t care about forwarding than just disable that but don’t disable DNSSEC!

dcam · September 16, 2017, 7:46am

Google has public servers that support DNSSEC at 8.8.8.8 and 8.8.4.4.

If I go into LUCI http://openwrt/cgi-bin/luci/admin/network/network/wan and then UNTICK “Use DNS servers advertised by peer” and enter 8.8.8.8 under “Use custom DNS servers”, and then click the little + next to it and also add 8.8.4.4, and save it, then I can turn forwarding on and leave “Disable DNSSEC” UNTICKED, and it works.

cynerd · September 16, 2017, 8:08am

Then luci configuration might not work. You have to disable dns forwarding if you don’t want to forward to your ISP’s dns server. But I am not imvestigating it now and I have no deep knowledge about exact configuration at the moment. Someone else from Turris team will give you more precise answer.

dcam · September 16, 2017, 8:10am

Sorry I edited my response above about the same time you replied… I got it working as above against the Google public servers that support DNSSEC.

phireph0x · September 18, 2017, 12:32am

My DNS resolution was broken as well with the upgrade to 3.8. Unchecking the ‘Use forwarding’ option seems to have resolved the issue. Is there a permanent fix in the works? Thanks!

vcunat · September 18, 2017, 7:18am

Resolution without forwarding should work anywhere, as long as the ISP isn’t doing anything really evil.

NYtimebomb · September 21, 2017, 12:52pm

Setting custom DNS servers and re-enabling forwarding/DNSSEC has returned my functionality back to normal. Mind you it took the Omnia a minute to figure it all out, as the initial ‘Test Connection’ in the DNS section failed, but subsequent ones passed. This maybe due to my dual-ISP configuration.

My ISP’s: Spectrum & Verizon
My specified DNS servers: 64.6.65.6 & 8.8.4.4

Public DNSSEC capable hosts:
8.8.8.8 & 8.8.4.4 - Google
64.6.64.6 & 64.6.65.6 - Verisign

While I appreciate Turris’ lean towards security, most ISPs name servers are not DNSSEC capable (that I’ve found).

vcunat · September 21, 2017, 1:49pm

This in-capability will be addressed by auto-switching to iteration: 3.8.1 in RC: better DNS work and new Nextcloud

DavidO · September 21, 2017, 9:31pm

I experienced probably the same problems as dcam. Turris Omnia autoupdated to 3.8.1 and I do not get some addresses resolved.
Did some quick experiments:
Originally, it was set to checked Use forwarding + unchecked Disable DNSSEC: Some addresses do not resolve, dig returns nothing, dig the same name to all my ISP’s servers and 8.8.8.8 works (I retrieved their IPs in luci status overview).
Unchecked Use forwarding + unchecked Disable DNSSEC: all seems to work,
Checked Use forwarding + checked Disable DNSSEC: all seems to work.

It might be possible that this behaviour is not new. Some time ago before turris Omnia autoupdated I did experience some addresses not resolving on one computer but did not investigate the problem as that computer needed reinstall. After reinstalling it seemed to work but it is possible Turris Omnia rebooted or reinstalled something too.