by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Robert Šefr
@robcza
Can I expect any issues with DNSSEC validation using the policy action FORWARD? Compared to recursive resolution I mean. I'm sure I have read about such issues in the past, but can not find the source at the moment.
By the way, hats off to the developer who prepared the new Dockerfile. Way better than the previous alpine based one.
Vladimír Čunát
@vcunat
If the target behaves OK, it shouldn't be a problem. Ancient resolvers with DNSSEC bugs will be a problem.
And you may be getting relatively lots of RTTs between the two when cache is cold, so it can be either faster or slower than iteration, depending on various stuff.
Turris Omnia defaults ship with kresd FORWARD to ISP server and validation, so it shouldn't be too bad.
Robert Šefr
@robcza
@vcunat that is a good point, thank you
we have seen some issues on Active directory domain controllers, but it was some time ago (more than a year) and the servers were probably quite old
Vladimír Čunát
@vcunat
Some larger Czech ISPs are still a problem today IIRC, probably using very old BIND versions or something.
edoo
@ookangzheng
1 question here…
How does 1.1.1.1 or 9.9.9.9 or 8.8.8.8 detect the changes of domain names so fast.
Example, I switch off cloudflare CDN, wait for 5 ~ 8 secs, dig xx.com resolution return latest result. On knot-resolver, I dig before xx.com so it cached like 300 ms, so how 1.1.1.1 or 9.9.9.9 do that? They igonre the cache?
Vladimír Čunát
@vcunat
CloudFlare has special code for this in case of 1.1.1.1 and their authoritatives.
I.e. when you change auth data, they invalidate the corresponding parts of cache in all 1.1.1.1. Reportedly; details aren't public AFAIK.
edoo
@ookangzheng
So solution on self-host knot resolver either wait it time out, or manually restart service to get latest change
Vladimír Čunát
@vcunat
Actually CF claims their main "business motivation" for 1.1.1.1 is that it makes their DNS/content faster.
edoo
@ookangzheng
I tested on Quad9 DNS also, they react very fast too
Vladimír Čunát
@vcunat
@ookangzheng: you can use cache.clear('domain.name') just as CloudFlare does.
edoo
@ookangzheng
Ah, cool.
Vladimír Čunát
@vcunat
I have no Quad9 information about that. They use dnsdist + a mix of unbound and powerdns-recursor AFAIK.
Restarting knot-resolver will typically keep the cache.
Fred
@Fred81_gitlab
I have domain listed in an RPZ file , but knot-resolver still resolves it. What could be wrong?
Vladimír Čunát
@vcunat
How did you configure kresd to use that RPZ file?
Fred
@Fred81_gitlab
policy.add(policy.rpz(policy.DENY, '/etc/knot-resolver/abuse.ch.rpz',true))
Vladimír Čunát
@vcunat
That seems good.

It's possible that some preceding rule matches the request and does something different. In any case, I'd like to reproduce some kind of this problem locally.

So some requests do get blocked and some don't? If so, can you at least post that query name and RPZ line?

Fred
@Fred81_gitlab

I'm using the RPZ file from https://urlhaus.abuse.ch/downloads/rpz/ . It contains:

tuinaanlegprovoost.be CNAME . ; Malware download (2019-03-01), see https://urlhaus.abuse.ch/host/tuinaanlegprovoost.be/
$ kdig tuinaanlegprovoost.be

returns the IP address.

Fred
@Fred81_gitlab
it seems it does not work for any entry in the RPZ file. This is my config file:
user('knot-resolver','knot-resolver')
verbose(true)
cache.size = 512*MB
modules = {
  'policy',
  'view',
  'hints',
  'serve_stale < cache',
  'workarounds < iterate',
  'stats',
  'predict'
}
view:addr('127.0.0.1/8', function (req, qry) return policy.PASS end)
view:addr('[::1]/128', function (req, qry) return policy.PASS end)
view:addr('0.0.0.0/0', function (req, qry) return policy.DROP end)
policy.add(policy.rpz(policy.DENY, '/etc/knot-resolver/abuse.ch.rpz',true))
predict.config(20, 72)
Vladimír Čunát
@vcunat
@Fred81_gitlab: thanks! Workaround for now: delete the first three lines of the RPZ; ticket link.
BTW, predict.config(20, 72) isn't a valid config line, for me at least, but that seems clearly unrelated.
Fred
@Fred81_gitlab
@vcunat : Thank you, this is very helpful!
Vladimír Čunát
@vcunat
:-)
Elctro
@Elctro
Hello, how may I know inside knot module, possibly in finish layer, whether answer is cached or not.
Vladimír Čunát
@vcunat
@Elctro: this is how stats module's finish phase does it: https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/modules/stats/stats.c#L225
Hmm, it only looks a the last step, so e.g. if there was a CNAME chain where only the last step went from cache, it would also be counted as cached. That's probably not exactly what people typically imagine as "cached".
Elctro
@Elctro
Roger that, that actually works for my needs anyways. Thanks!
Vladimír Čunát
@vcunat
:-)
Georg
@teadur
anyone seen that kresd takes all the memory ?
if it happens again how could i produce somekind of useful debug data for you guys ?
Petr Špaček
@pspacek
In what sense? In output from command top vs. OOM killer?
Georg
@teadur
didnot wait long enough for oom, but the box was in state that running any command in system ended in fork failure
or maybe oom failed i didnot have much time to investiage before i was unable to run any command in system
and had to reboot the box
Vladimír Čunát
@vcunat
I haven't heard of that.
Petr Špaček
@pspacek
That's interesting because we have bunch of automated tests for memory leaks.
... is there anything else running on the on box, or, do you have a custom modules?
Vladimír Čunát
@vcunat
I've heard of suspiciously large memory usage when running for many days, but it was rare among users and not with any recent version anyway.
Georg
@teadur
running on 3.2.1
it had been running for some time for sure
but will see tomorrow they will go under real load
so if i could produce any useful debut output i would for sure
s/debut/debug
Vladimír Čunát
@vcunat
System log doesn't show anything? (If preserved on reboots.)