[SOLVED] Slow DNS resolution (no forwarding) when WAN is not active

Software SW help
1

Hello,

I deployed Omnia at my home in default configuration and I immediately noticed that DNS lookups are substantially slower. When I visit a page for the first time, I can clearly see browser waiting for DNS resolution.

Sometimes I also experience that resolution fails when the host is apparently correctly spelled (and it is resolved by upstream server or 8.8.8.8). I tried to turn off DNSSEC, but with no help.

I am not using WAN interface at the moment, I use Omnia as DHCP/DNS/TFTP server and planning to connect fibre SFP later next year, but I don’t think this is relevant.

How do I fix this or remove Knot DNS from my Omnia?

2

You could try to turn off all other resolvers than dnsmasq, together with DNSSEC. Thats the standard situation in OpenWRT, and then compare, if slowness will be still there.

Thats also my plan to do, when I will setup Omnia, as I dont feel good about X resolvers there…

3

There are no X resolvers. There is only one, Knot DNS resolver. Dnsmasq works only as DHCPv4 server, its DNS functions are turned off.

4

I know, technically you are right. And maybe I was wrong, when I think that kresd and knot are two different resolvers. But I mean, unbound, kresd, dnsmasq, all are there if I am not wrong?

Personally I dont know if Izaps delay is only because DNSSEC, but considering my assumption above, I think its good to try it.

5

Knot DNS RESolver Daemon. There is no unbound, only ZUUL knot and dnsmasq (which works as DHCP)

6

Knot DNS is an authoritative DNS server, not resolver, those orthogonal functions are separated in different software projects (unlike say BIND, which combines both functions in one binary).

You are right that there is unbound installed as well, even though it’s not running in the default config. I guess it’s just a residue from the previous Turris generation.

To the slower resolution, I guess the reason is not the DNSSEC but doing the full recursion on the router. This could be fixed by configuring some upstream DNS servers and enabling DNS forwarding.

7

Thanks for explanation, I am learning something new whole life :slight_smile: I would propose then get rid of unbound to prevent such misleading thinking.

I would closelly follow this topic, as I am interesting on your guessing solution (in case I will face the same problem). If I understand you correctly, there are need some knot configuration to give him better performance, as dnsmasq would have, if it would be used for DNS resolving, correct?

8

How do I set upstream servers and enable DNS forwarding in knot please? I can’t find a good documentation on that topic, particularly in the OpenWRT environment.

9

Ok I found out, since my WAN was not activated, I had no resolv.conf.auto file which is the source for Knot to enable forwarding. Therefore I created and enabled little script that deploys the missing file:

root@turris:~# cat /etc/init.d/google-resolver
#!/bin/sh /etc/rc.common
# REMOVE ME once WAN is activated
 
START=59
STOP=15
start() {        
cat >/tmp/resolv.conf.auto <<EOF
domain home.lan
nameserver 8.8.8.8
nameserver 8.8.4.4
EOF
}                 
 
stop() {          
true
}

You should put your upstream DNS servers instead 8.8.8.8 and 8.8.4.4, just in case someone do not get this.

10

You can also add nameservers to any interface that it up. In your case, where such interface is lan, just add

config interface 'lan'
…
list dns '8.8.8.8'
list dns '8.8.4.4'

The resolv.conf.auto then should be generated on next ifup of the lan interface.

1 Like
11

Thanks, I edited the file, rebooted and “/tmp/resolv.conf.auto” is still empty. I see the entry in LuCI, tried to apply configuration without any success. What can be causing this?

12

Interesting. Is the list of "dns-servers" in the output of ifstatus lan also empty?

13

@lzap I would be definitely interested in seeing kresd logs when run with -v and the resolution is slow - if you have a tad bit time to help debug this issue, this would be much appreciated.

14

Reproduced! Was scratching my head when Knot was still forwarding to my upstream DNS until I realized the config is generated by the init script. Here is the session:

Two sites were opened:

  1. www.trump.com resolved quickly
  2. www.fifa.com was loading a bit slow, it was like a second of “Resolving host…” browser message until it finally appeared.

Hope it helps. Big fat warning - in my case my WAN interface is DOWN, I use Turris as a DNS/DHCP/TFTP server for now. Also my version is 2GB - No Wifi, if that makes any difference. Other than that, no special configuration at the moment AFAIK.

Edit: Oh one more thing, I have added “hint” from /tmp/hosts/dhcp where I have 5 entries (gw.home.lan, turris.home.lan and few others).

Edit 2: My provider does not have IPv6 AFAIK, so this does not get routed properly. My laptop is Fedora 24 and it received IPv6 address properly, well I can ping turris via IPv6 but that’s all I am capable doing at the moment. Shame on me, I am not IPv6 early adopter.

15

Hmm, this is a problem we though we already solved (the fast timeout on IPv6 addresses when IPv6 is available only locally), but it seems that your setup triggers it again.

Adding net.ipv6=false to the config file should make the resolution to not try IPv6 first.

1 Like
16

which config specifically?

1 Like
17

Yeah, I also don’t know which config you have on your mind. OpenWRT newbie here. :smiley:

18

@oerdnj certainly means the kresd config file, which is generated from /etc/config/resolver:

config resolver 'common'
   …
   option net_ipv6 '0'
   …
5 Likes
19

Can you please tell where you find the entry from extra DNS?
I added them to my wan settings, but they don’t work.

20

Have you looked under LuCI, Network Menu > DHCP and DNS
Under there is DNS Forwardings where you can add them.