Dns forwarding to a different DNS for the internal lan

Software SW bugs discussion
1

Hi *,

I thought it would be easy, but I’m struggling with this for a few days now without solving it.
I want my Turris Omnia to resolve everthing by itself besides addresses from my internal lan, for which it should ask an internal DNS server. This should work for clients in the internal lan asking the router and also for the router itself.
I tried lots of things I found in this forum and on the openwrt website, but it doesn’t work.

Am I overlooking something perhaps trivial?

TIA.

Bye.
Michael.

2

From http://knot-resolver.readthedocs.io/en/latest/modules.html, I think you can do (not tested):

/etc/config/resolver:

config resolver 'kresd'
        ...
        option include_config '/etc/kresd/custom.conf'

/etc/kresd/custom.conf:

policy.add(policy.suffix(policy.FORWARD('192.168.1.1'), {todname('myowndomain.lan')}))

(Module policy appears to be loaded by default)

3

Thx for this hint - looks good, it seems to do exactly what I need!
Is this possible for reverse lookup zones, too?

4

“Reverse” zones have nothing special: for a DNS resolver or authoritative server, they are just ordinary zones. So, it should work.

5

that’s what I thought, but it doesn’t seem to work:

policy.add(
  policy.suffix(
    policy.FORWARD(
      '192.168.1.8',
      '192.168.1.4'
    ), 
    { todname( '1.168.192.in-addr.arpa' ) }
  )  
)

Maybe it can’t work, because the DNS servers are in the same zone?

6

If you want to pass multiple servers to FORWARD, you need to make a list, i.e. wrap them with braces.
....FORWARD({'addr1', 'addr2'})...

but I think the main problem is that knot-resolver by default refuses any local adresses that come from upstream servers (e.g. 192.168.. records).

7

That rule can be removed by adding policy.del(0)

8

The curly braces lead to “;; connection timed out; no servers could be reached” - without them, everything works as expected - are you sure, I need them?

9

policy.del(0) does, what I want - thx a lot!

10

No, you were right - I need the curly braces - there was a sytnax error in some other line.
So at the moment everything regardings dns works for me as intended.

Thx a lot to you all!

Bye.
Michael.

11

I’ve got this set up and mostly working on my local domain: it is forwarding local reverse lookups to dnsmasq on the Turris Omnia OK. However reverse lookups forwarded by kresd have the local domain stripped from the result, whereas reverse lookups sent directly to dnsmasq do not.

How do I get kresd to return “myhost.mydomain.net” instead of “myhost.”?

In my case this is messing up kerberos as the host principals are currently fully qualified.

12

That must be because dnsmasq returns the reverse records that way. I can just guess that you can instruct DHCP to make all hosts (or particular hosts) part of a domain and that might make dnsmasq return what you want. It’s perhaps good even for the individual machines to know their full name (e.g. the domainname command on Linux systems).

13

I assumed that first, but I’ve verified that doesn’t appear to be the case. I have dnsmasq running on port 5353 and kresd on 53. The local domain and reverse lookups are forwarded by kresd to dnsmasq:

  • dnsmasq:
    root@turris:~# khost 192.168.100.1 localhost@5353
    1.100.168.192.in-addr.arpa. points to turris.mydomain.net.

  • kresd:

    root@turris:~# khost 192.168.100.1 localhost@53
    1.100.168.192.in-addr.arpa. points to turris.

The hosts do know their domainname via hostname -f and dnsdomainname (domainname relates to NIS), however GSSAPI uses a reverse lookup on the IP to select the kerberos principal for authentication, hence my issue.

Is kresd trying to be clever in some way?

14

There are multiple sources combined and fed to kresd via a temporary file /tmp/kresd/hints.tmp. I know mainly about kresd itself, not much yet about how it gets its configuration on Omnia.

15

I was just looking at that file simultaneously! And I think I’ve discovered the issue:

In my /etc/hosts I have:

192.168.100.1 turris.mydomain.net turris

And /etc/hosts gets copied verbatim into /tmp/kresd/hints.tmp

If I take the non-FQDN alias out:

192.168.100.1 turris.mydomain.net

… then the FQDN is correctly returned (so I’m guessing it’s actually not forwarding these known hosts to dnsmasq due to the hints being available?).

man 5 hosts

confirms the format of /etc/hosts is meant to be

IP_address canonical_hostname [aliases...]

So in the kresd hints file, when there are aliases, what happens? Is there a way to make the canonical_hostname take priority by modifying some lua? (If not then I think I can safely take out the non qualified aliases anyway.)

16

Ah, right, I “forgot” that it’s not done via forwarding but via transferring the list from dnsmasq to kresd (by a script).

There’s nothing clever in kresd about this; I believe the last one always wins (there might be the same name on multiple lines, too).

17

Thanks for your help getting to the bottom of things. I’ve fixed this for my network now.

It might be worth a note in the documentation for kresd that the hints file interpretation is not 100% the same as the definition of entries in /etc/hosts, and how it differs. Though in this case it was actually the unexpected copying of /etc/hosts to the hints file by the startup script that was more confusing.

Cheers,
James

18

Oh, I see now – man hosts documents the first name should be canonical and thus preferred. I consider that a bug in kresd. Thanks.

1 Like