These are chat archives for CZ-NIC/knot-resolver

31st
Oct 2018
Vladimír Čunát
@vcunat
Oct 31 2018 12:06
@robcza: right, that's exactly the situation explained by my last comment. We'll probably need to carefully plan some "design changes" if we want to support these use cases reliably.
Currently the config options for this are imperative: if some conditions hold, we execute code that changes some attributes, e.g. sets to forward to some server. That's relatively flexible, but apparently it can't perfectly express some relatively common use cases. It might be nicer from multiple points of view to support (also) more declarative approaches, as it seems that people primarily want some simple transformations of the DNS tree.
Vladimír Čunát
@vcunat
Oct 31 2018 12:13
Petr Špaček
@pspacek
Oct 31 2018 12:20
@vcunat Would it help if there is negative trust anchor for given subdomain?
Vladimír Čunát
@vcunat
Oct 31 2018 12:28
Apparently it doesn't help, though it's possible it wouldn't be difficult to make it work.
(at least in most cases)
Petr Špaček
@pspacek
Oct 31 2018 12:29
We can look at that when we are done current tasks... Let's discuss in the evening.
Robert Šefr
@robcza
Oct 31 2018 12:49
I don't get it. Does it mean that the proof from root server is stored in the cache and is processed before we go to the STUB action?
Robert Šefr
@robcza
Oct 31 2018 12:55
If yes, it means the issue is, that something tried to resolve <something_else>.local and the resolvers caches .local does not exist and from that moment onwards it does not reach the policy rule:
  • would this help (after clearing the cache)? policy.add(policy.suffix(policy.STUB('10.10.20.1', '10.10.20.5'), {todname('local')}))
  • what about putting the policy module before the cache? is that an option?
Petr Špaček
@pspacek
Oct 31 2018 13:01
I would recommend you to experiment and report back, shuffling order of modules or clever cache.clear could help. For tracking purposes please open a new issue about it so we do not forget.
Unfortunatelly we cannot jump at it right away because we have hands full with requests from customers with formal support contract, sorry!
Robert Šefr
@robcza
Oct 31 2018 13:02
Ok, let me try and report back with the issue. Totally understood, thanks for the response anyway!
Andreas Oberritter
@mtdcr
Oct 31 2018 13:12
Hi! I tried setting up a suffix-based policy for DN42 (https://dn42.net/). I already have a few working suffix-based policies, but just this one doesn't work. DN42 uses 'dn42' as internal TLD. Is it possible that knot-resolver does not accept numbers in TLDs?
Petr Špaček
@pspacek
Oct 31 2018 13:14
Hi. Numbers are certainly not a problem, I expect conflict with DNSSEC validation. Please see discussion above, we were just discussing similar cases.
The general problem is that made-up TLDs like local/dns42 and similar are technically indistingushable from an attack on global DNS name space. DNSSEC validation is likely to detect and stops this attack.
Andreas Oberritter
@mtdcr
Oct 31 2018 13:15
I used policy.STUB, and actually there is another TLD in the same network ("hack"), which works. If I change STUB to FORWARD, .hack stops working. There's no difference for .dn42 however.
Petr Špaček
@pspacek
Oct 31 2018 13:16
My guess is that it depends on state of cache, at some point the resolver might get enough information in cache to "prove" that dns42 is not supposed to exist and blocks it from that point on.
I.e. it would not surprise me if hack stopped working later on, or dns42 started to work eventually (when proof expires from cache) etc.
We will think about ways we can improve handling of these "allowed fake" TLDs but it is harder than you might think ...
(BTW if you ever decide to setup a new network please do not use made-up TLD, it is just causing trouble with DNSSEC.)
Andreas Oberritter
@mtdcr
Oct 31 2018 13:23
OK, thank you!
Vladimír Čunát
@vcunat
Oct 31 2018 13:28
@robcza: rules are executed before cache, but even .STUB queries use cache. That should be possible to disable by additionally setting NO_CACHE flag via a .FLAGS action.
I guess that might be the preferred workaround for all three of you, especially if the forwarder is very close (low benefit from caching).
Andreas Oberritter
@mtdcr
Oct 31 2018 14:53
@vcunat: Thank you! Setting NO_CACHE makes it work, indeed.
Robert Šefr
@robcza
Oct 31 2018 15:41
@vcunat understood, so the policy could like this? Not sure about the FLAGS syntax
policy.add(policy.suffix(policy.FLAGS('NO_CACHE'), {todname('example.local')}))
policy.add(policy.suffix(policy.STUB('10.10.20.1', '10.10.20.5'), {todname('example.local')}))
Vladimír Čunát
@vcunat
Oct 31 2018 18:21
Yes, that's what I meant. (Not really tested yet.)