Kresd rules weirdness

Software SW help
1

Hi,

I have DNS setup in kresd setup to forward to external DNS servers but those are somewhat buggy especially for CNAME subdomains (IP is not resolved, just cname which leads to errors). To work around this problem I tried to send them to Googles public server but no matter what I try in terms of rules in /etc/kresd/custom-forwarding it doesn’t work.

The most important subdomain for me is actually my own named “shadowsrealm.ch” which has about 6 cnames on it.

so I tried making a rule to send all requests to google for shadowsrealm.ch and its subdomains. Actually there were 2 attempts. one with just using suffix and now I tried with pattern with the only effect that with suffix the dns was still forwarded and with pattern I now get a timeout for all of this domain names so obviously pattern is doing somewhat but not really returning DNS data (tried with STUB and FORWARD), here’s the current rule in the kresd config.

local subdomain_role = policy.add(policy.pattern(policy.STUB('8.8.8.8'), 'shadowsrealm\2ch'))
policy.del(subdomain_role.id)
table.insert(policy.rules, 1, subdomain_rule)

but I also tried

local subdomain_role = policy.add(policy.suffix(policy.STUB('8.8.8.8'), policy.todnames({'shadowsrealm.ch'})))
policy.del(subdomain_role.id)
table.insert(policy.rules, 1, subdomain_role )

I also can see that it shows up in /tmp/kresd.config at the bottom so the /etc/kresd/custom-forwarding is included but as I said I don’t know why suffix seems to have no effect and pattern leads to timeout.

Any help here would be greatly appreciated cause I’m really out of ideas on this.

2

Originally posted on upstream gitter, but let me continue here, as the post has more details and we have better topic-threading.

I don’t know… both approaches seem to work fine on my Turris.

Generally I recommend suffix over pattern and FORWARD over STUB, and for quite some time policy.rules is empty by default even when setting up forwarding on Turris (in usual ways, e.g. clicking in Foris), so I see no point in the insert-del dance (but it works for me with that as well).

I suppose verbose logs will be the best way how to find what’s happening.

3

Actually, when you modify config already, you might find it easier to add a verbose(true) line to start generating the log :man_shrugging:

4

Hi @vcunat,

Sorry for the late reply, but with corona and everything the issues lost a bit of attention. Nevertheless I still have problems but maybe my solution is just wrong.

As to your suggestion I have removed the del, add, insert stuff and now my config has 3 lines like this:

policy:add(policy.suffix(policy.STUB(‘192.168.10.50’), policy.todnames({‘ad.shadowsrealm.ch’})))
policy:add(policy.suffix(policy.STUB(‘8.8.8.8’), policy.todnames({‘dyndns.org’})))
policy:add(policy.pattern(policy.STUB(‘8.8.8.8’), ‘shadowsrealm\2ch’))

Much cleaner I have to agree. And what works perfectly is first and last line. So for example resolving AD1.ad.shadowsrealm.ch returns 192.168.10.50 (yes the hostname is the same as the machine running the DNS). What also works is anything ending in shadowsrealm.ch for example freepbx.shadowsrealm.ch, or imap.shadowsrealm.ch, etc. here’s an example:

$ nslookup freepbx.shadowsrealm.ch
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: freepbx.shadowsrealm.ch
freepbx.shadowsrealm.ch canonical name = shadowsrealm.ch
Name: shadowsrealm.ch
Address 1: 178.82.30.225
freepbx.shadowsrealm.ch canonical name = shadowsrealm.ch

However what doesn’t work is resolving subdomains of dyndns.org, here’s the example output this time of “dig” because it shows more info.

; <<>> DiG 9.12.4-P2 <<>> members.dyndns.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38981
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;members.dyndns.org. IN A

;; ANSWER SECTION:
members.dyndns.org. 72215 IN CNAME vip.web1-05-ussnn1.prod.dc.dyndns.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Apr 28 08:10:09 CEST 2020
;; MSG SIZE rcvd: 98

And this CNAME itself is not valid IP and anything concerning this hostname just cannot resolve it, for example trying to ping it results in “ping: bad address ‘members.dyndns.org’”. I know that the dns server I have to use actually have some problems like this so I try to just direct everything that’s problematic to google’s dns resolvers like with the 2nd rule. And actually if I do a "dig members.dyndns.oirg 8.8.8.8 I get a much more detailed output and also an IP.

dig members.dyndns.org 8.8.8.8

; <<>> DiG 9.12.4-P2 <<>> members.dyndns.org 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20927
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;members.dyndns.org. IN A

;; ANSWER SECTION:
members.dyndns.org. 72119 IN CNAME vip.web1-05-ussnn1.prod.dc.dyndns.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Apr 28 08:11:45 CEST 2020
;; MSG SIZE rcvd: 98

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33153
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
. 72165 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020042702 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Apr 28 08:11:45 CEST 2020
;; MSG SIZE rcvd: 111

so this example shows that rule 2 for whatever reason is not working, otherwise it should have returned the correct answer from google.

But I have now enabled verbose logs and will send you the logs.

5

Thanks for the logs. I believe this is a bug for CNAME caching in STUB mode that I fixed recently, about to be in this week’s upstream release. What you can do now is to switch the 8.8.8.8 rules to FORWARD instead of STUB (though you won’t really benefit from DNSSEC validation in these subtrees anyway).

6

Hi @vcunat,

Thanks for your reply. I switched all rules that should forward to Googles DNS Server 8.8.8.8 from STUB to forward (of course the internal DNS has to stay as STUB) and that indeed solved the problems with canonincal names, they now correctly return the IP Address and dyndns plugin is now happy again because it can resolve members.dyndns.org and also the check host which is www.shadowsrealm.ch.

Both domains now resolve properly. Thank you for your help.

Any idea when your fix will be officially released and if it will become available also for Turris OS 3.x or only OS 4.x?

7

Release upstream should happen today, most likely. Turris OS 4.x won’t have this, but people should update to 5.x soon (HBT :turtle: has 5.x for some time already). For 3.x it sounds possible, perhaps surprisingly, but I certainly can’t promise at this point.

8

To close the loop: Knot Resolver 5.1.1 with the fix will be available in Turris OS 5.0. Currently in Testing branch. Should be released soon to Stable branches.