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

3rd
Aug 2018
Petr Špaček
@pspacek
Aug 03 2018 09:24
Hello. You could write your own module to do that if you need it. What is the use-case?
AFAIK no DNS resolver does this out of the box so I'm curious.
edoo
@ookangzheng
Aug 03 2018 09:26
Because unbound dns (client) —> Knot-resolver
failed
It said DNSSEC validation fail
But I tried to comment out auto-trust-anchors (Unbound conf), it works again
Petr Špaček
@pspacek
Aug 03 2018 09:27
We test this configuration literally every day so it is most likely a configuration problem either in Unbound or in Knot Resolver.
Oh yes, you probably need to manually configure trust anchors for your OpenNIC setup.
edoo
@ookangzheng
Aug 03 2018 09:29
Should I need to add IANA’s DNSkey in trust anchors?
I have OpenNIC trust anchors already
Petr Špaček
@pspacek
Aug 03 2018 09:30
I do not think so, OpenNIC should be enough. Anyway, this smells like configuration problem in Unbound so you might want to ask on unbound-users.
(their mailing list)
edoo
@ookangzheng
Aug 03 2018 09:31
So in my knot-resolver kresd.conf
trust_anchors.file = ‘/etc/knot-resolver/root.keys'
Only contains OpenNIC anchors is enough?
Knot-resolver will auto figure out ICANN key?
edoo
@ookangzheng
Aug 03 2018 10:29
@pspacek I tried do a dnssec request from my TLS server, it return BOGUS
image.png
While “UDP, TCP”, dnssec return “dnssec_status”: GETDNS_DNSSEC_SECURE
Why this happend
Petr Špaček
@pspacek
Aug 03 2018 10:45
I do not see why there should be a difference between UDP/TCP and TLS. These are handled in single process.
edoo
@ookangzheng
Aug 03 2018 10:45
I’m just curious
Petr Špaček
@pspacek
Aug 03 2018 10:46
In any case, the getdnsapi.net web is not going to work reliably with OpenNIC root - you would need to change trust anchor for the test tool and that's AFAIK not possible.
To you previous question about trust achor: Your root TA must match the root you decided to use. If you decided to use OpenNIC root then it must be the OpenNIC TA.
AFAIK OpenNIC imports ICANN TLDs and sign them with own TA so you should need ICANN TA.
edoo
@ookangzheng
Aug 03 2018 10:48
So I have to
curl -s https://www.internic.net/domain/root.zone | grep “^\.\s\+[0-9]\+\s\+IN\s\+DNSKEY"
Combine with current OpenNIC root
Then it should work?
Petr Špaček
@pspacek
Aug 03 2018 12:45
No, just use OpenNIC root. You cannot change anything in any of them becase both are signed.
edoo
@ookangzheng
Aug 03 2018 12:47
ok I see
One question
I don’t specified actual trust_anchor in kresd
So when the program started, it will auto get latest version from IANA
Problem here is I still can access to OpenNIC domains. I think the cache isn’t work
Petr Špaček
@pspacek
Aug 03 2018 12:49
That's default behavior if you do not specify your own. In your case just replace IANA TA with OpenNIC TA and it will work.
edoo
@ookangzheng
Aug 03 2018 12:50
I do add cache.clear() in kresd.conf
And delete the data.mdb file, and restart the services
The cache still there
Vladimír Čunát
@vcunat
Aug 03 2018 12:51
It's normal to exist. cache.clear() or removal just empties it.
Petr Špaček
@pspacek
Aug 03 2018 12:52
You had the same problem and according to your message it started to magically work after some time so I believe there is some misconfiguration somewhere but it is hard to tell where.
Vladimír Čunát
@vcunat
Aug 03 2018 12:52
If you don't specify path to the trust-anchors file, it depends on how knot-resolver was built. It may have a default specified from build via KEYFILE_DEFAULT or you may have no validation.
Petr Špaček
@pspacek
Aug 03 2018 12:52
I would recommend you going step by step, start with all IANA stuff and gradually add one component at time to find out where is the problem.
edoo
@ookangzheng
Aug 03 2018 12:53
ok
I use cache.max_ttl(300)
To force the cache after 300 seconds and refresh
For me OpenNIC TLD isn’t important anymore
Petr Špaček
@pspacek
Aug 03 2018 12:56
We did your best yesterday to find out why cache.clear() in config was not reflected. Given that it is impossible and nobody else has seen that problem I have to assume that it is problem somewhere in your system.
There must be some problem in system or its configuration but we have no way to help you with system broken in such way.
For this reason there is no way how to continue until you figuretively "diassemble" the setup to individual components, test each of them separately and then start assembling them tohether again.
For this reason there is no way how to continue until you figuretively "diassemble" the setup to individual components, test each of them separately and then start assembling them tohether again.
edoo
@ookangzheng
Aug 03 2018 13:00
Ya, that’s true
Just fun to play with this
I’m try to block domain with dnsmasq.
So client => udp/tls => knot-resolver => 127.0.0.1#54 => dnsmasq => cloud flare DNS
And try out DNSSEC still work or not
Petr Špaček
@pspacek
Aug 03 2018 13:02
You can use policies for blocking in kresd itlself: http://knot-resolver.readthedocs.io/en/latest/modules.html#policy-module
If it is for fun then go ahead :-)
edoo
@ookangzheng
Aug 03 2018 13:02
I use pi-hole
The system will generate out a huge blacklist
Maybe I can import those blacklist into kresd
edoo
@ookangzheng
Aug 03 2018 13:08
So will be nice to use policy.rpz or put blacklist domain into like daf.add ‘qname = hall.ma deny’
Petr Špaček
@pspacek
Aug 03 2018 13:08
Yes you can, kresd has optimization for huge suffix lists. See http://knot-resolver.readthedocs.io/en/latest/modules.html#filters and look for suffix filter. It accepts one Lua table and this table can be huge.
edoo
@ookangzheng
Aug 03 2018 13:11
okay
Petr Špaček
@pspacek
Aug 03 2018 13:11
It will probably be faster if you use policy.add(policy.suffix(policy.DENY, {todname('domain1.'), todname('domain2.')}))
Vladimír Čunát
@vcunat
Aug 03 2018 13:12
BTW, the adblock package for OpenWRT (or Turris Omnia) auto-updates blacklists and feeds them into knot-resolver.
edoo
@ookangzheng
Aug 03 2018 13:12
Is daf.add ‘qname = xxx.com deny’act the same like suffix
Petr Špaček
@pspacek
Aug 03 2018 15:08
Not really, you will not get the same speedup.
Petr Špaček
@pspacek
Aug 03 2018 15:21
BTW we just found out that cache.clear() from config file will not work without explicit cache configuration before the call. In any case, this does not explain why deleting data.mdb did not help ...
edoo
@ookangzheng
Aug 03 2018 16:46
Okay.
I'm working with RPZ😬 its cool