On 4/12/19 1:06 am, Vladim??r ??un??t wrote:
On 12/2/19 7:45 PM, Tomas Krizek wrote:
Are you asking how does Turris configure Knot
Resolver with the ISP's
DNS resolver as a forwarder? That, I don't know, but a proper place to
ask would probably be the Turris forum [2] or support.
I believe that's the default - in any case, you can switch off the
generated forwarding rules by ticking a checkbox in Foris GUI - in DNS tab.
If you uncheck those, you can add your own forwarding; Omnia-specific step:
https://doc.turris.cz/doc/en/public/dns_knot_misc#adding_custom_configurati…
With the policy rules it's e.g. possible to configure kresd to use
policy.PASS on everything in .lan and policy.FORWARD the rest
https://knot-resolver.readthedocs.io/en/stable/modules.html#policy-examples
... but I can't say if such a setup is optimal for you, and it doesn't
address things like reconfiguration when VPN (dis)connects.?? Generally
I'd say that DNS is best to take from the point where routing happens,
for example prefer local DNS server if the traffic goes without VPN by
default.?? Otherwise you might e.g. be prone to get sub-optimal
performance of some CDNs.
Thank you so so much for these useful pointers and links. It's looking
like with selective filters an foreknowledge of suffixes and given that
non-overlapping suffixes are used in a pattern like:
policy.add(policy.suffix(policy.FORWARD('...'), {todname('suffix on
LAN')}))
policy.add(policy.suffix(policy.FORWARD('...'), {todname('suffix on
VPN')}))
policy.add(policy.FORWARD('...'))
Alas it doesn't seem like kresd can do a FORWARD then act based on the
result. It would be so lovely if it could. That is if we could specify a
policy for each of three FOWARD results:
1) No response
2) Negative response
3) Resolved name
but it seems we can't as FORWARD in Non-chained.
Re: the strategy on VPN connect and disconnect I have no problem driving
my connections from custom scripts if I need to that doctor resolv.conf
or any other configs and do any resolver restarts needed just after
connecting and disconnecting. I certainly prefer my local DNS and would
love a strategy that resolves on the local DNS and if response is
negative tries the VPN DNS.
I can see on the Omnia a kresd.config file that contains:
--Automatically generated file; DO NOT EDIT
modules = {
?????? 'hints > iterate'
?? , 'policy'
?? , 'stats'
?? , predict = {
?????????????? window = 30 -- 30 minutes sampling window
?????????? , period = 24*(60/30) -- track last 24 hours
?? }
}
hints.config('/tmp/kresd/hints.tmp')
net.bufsize(4096)
net.ipv4=true
net.ipv6=true
cache.open(20*MB)
cache.clear()
policy.add(policy.all(policy.FORWARD({
?????? '203.12.160.35',
?????? '203.12.160.36',
})))
What I can't see from that is how kresd on the Omnia knows to resolve
.lan names which it does well in practice. The policy encoded there
forwards ALL requests.
Kind regards,
Bernd.