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

10th
Dec 2018
micah
@micah
Dec 10 2018 17:01
i'm trying to start knot-resolver, but I'm failing to bind to the privileged port because it drops user to the unprivileged user before binding
kresd[23911]: [system] bind to '10.0.1.175@53' Permission denied
i'm using the stretch-backports systemd enabled version of knot-resolver
Petr Špaček
@pspacek
Dec 10 2018 17:03
I would recommend you to read man kresd.systemd, it has some examples.
micah
@micah
Dec 10 2018 17:03
@pspacek thanks, I have read that... but I must be missing something
Petr Špaček
@pspacek
Dec 10 2018 17:03
Please note that systemd-enabled systems should not use net.listen() in config file and configure interfaces in kresd.socket files.
micah
@micah
Dec 10 2018 17:04
oh that must be the issue
Petr Špaček
@pspacek
Dec 10 2018 17:05
(In other words, sockets should be bound by systemd which has necessary privileges, and kresd never runs as root in this config.)
micah
@micah
Dec 10 2018 17:09
can I put more than one ListenDatagram/ListenStream line in the override for multiple IPs? or can I group them in one line?
Tomas Krizek
@tomaskrizek
Dec 10 2018 17:32
@micah Yes, ListenDatagram and ListenStream can be specified multiple times (see man systemd.socket for details)
micah
@micah
Dec 10 2018 17:43
it seems I'm failing to bootstrap the trust anchors
/usr/lib/knot-resolver/trust_anchors.lua:387: [ ta ] fetch of "https://data.iana.org/root-anchors/root-anchors.xml" failed: error loading CA locations (No such file or directory)
what is the CA locations?
Petr Špaček
@pspacek
Dec 10 2018 17:45
Hmm, this is probably one of quirks in Debian - AFAIK they do not ship files for bootstrap with assumption that users will take root key from distribution package.
BTW Debian is shipping insecure packages, I would recommend you to use repo from https://www.knot-resolver.cz/download/
edoo
@ookangzheng
Dec 10 2018 17:58
@micah on Debian run
apt install ca-certificates
micah
@micah
Dec 10 2018 18:08
I do already have ca-certificates installed
what do you mean 'insecure packages'?
Petr Špaček
@pspacek
Dec 10 2018 18:09
Version 2.3 contains known security problems.
Up-to-date version is 3.1.
The problem with CA certificate is most likely missing file /etc/knot-resolver/icann-ca.pem which was removed by a Debian packager.
Vladimír Čunát
@vcunat
Dec 10 2018 18:11
The default on Debian should be to use the dns-root-data package for trust anchors. I suspect we have fixed that in the meantime.
Petr Špaček
@pspacek
Dec 10 2018 18:11
@vcunat If I'm not mistaken they remove it on purpose because "RFC 5011 is evil".
Vladimír Čunát
@vcunat
Dec 10 2018 18:11
And, yes, it's that file which is missing for TA bootstrap.
micah
@micah
Dec 10 2018 18:12
i thought the package in stretch-backports had fixes for the security issues
Vladimír Čunát
@vcunat
Dec 10 2018 18:13
Yes, it's weird. They removed it from stretch but left an old version here.
micah
@micah
Dec 10 2018 18:13
i do have dns-root-data installed, but I guess I need to change my path to point to it
Petr Špaček
@pspacek
Dec 10 2018 18:13
The path is built-in by packager so you do not need to do anything and it should just work.
As far as I can see in the stretch-backports package they do not ship any security fixes, so no, it is certainly not secure.
The only patch customizes man page and that's all.
micah
@micah
Dec 10 2018 18:15
ok, but it seems things are not working
Petr Špaček
@pspacek
Dec 10 2018 18:15
Can you be more specific?
Vladimír Čunát
@vcunat
Dec 10 2018 18:17
I'd make sure not to pass any -k or -K parameter nor use the similar trust_anchors.* commands in config.
micah
@micah
Dec 10 2018 18:17
well, kresd is not running, and I'm not sure what systemd service I should be running to start it
but the socket services are in state 'failed'
Petr Špaček
@pspacek
Dec 10 2018 18:17
Okay. Get the sockets to start first.
micah
@micah
Dec 10 2018 18:18
ok, I just simply did a systemctl start kresd.socket and it seemed to run
but then when I try to do a resolution, I see in my journal failures
because of the missing root.keys
Petr Špaček
@pspacek
Dec 10 2018 18:18
Okay then, paste the journal entry here.
micah
@micah
Dec 10 2018 18:19
Dec 10 10:18:00 barn systemd[1]: Starting Knot DNS Resolver daemon...
Dec 10 10:18:00 barn kresd[12462]: /usr/lib/knot-resolver/trust_anchors.lua:387: [ ta ] fetch of "https://data.iana.org/root-anchors/root-anchors.xml" failed: error loading CA locations (No such file or directory)
Dec 10 10:18:00 barn kresd[12462]: [ ta ] Failed to bootstrap root trust anchors; see:
Dec 10 10:18:00 barn kresd[12462]: https://knot-resolver.readthedocs.io/en/latest/daemon.html#enabling-dnssec
Dec 10 10:18:00 barn kresd[12462]: [ ta ] keyfile 'root.keys': doesn't exist, bootstrapping
Dec 10 10:18:00 barn systemd[1]: kresd@1.service: Main process exited, code=exited, status=1/FAILURE
Dec 10 10:18:00 barn systemd[1]: Failed to start Knot DNS Resolver daemon.
Dec 10 10:18:00 barn systemd[1]: kresd@1.service: Unit entered failed state.
Dec 10 10:18:00 barn systemd[1]: kresd@1.service: Failed with result 'exit-code'.
Dec 10 10:18:00 barn systemd[1]: kresd@1.service: Service hold-off time over, scheduling restart.
it then repeats a few times, and disables itself due to too many failures
Petr Špaček
@pspacek
Dec 10 2018 18:20
Okay, what do you have in kresd config file?
micah
@micah
Dec 10 2018 18:21
its pretty simple, just these lines:

user('knot-resolver', 'knot-resolver')
trust_anchors.file = 'root.keys'
cache.size = 4 * GB

-- Load Useful modules
modules = {
'policy', -- Block queries to local zones/bad sites
'view', -- Views for certain clients
'hints', -- Load /etc/hosts and allow custom root hints
'stats', -- Track internal statistics
}

Petr Špaček
@pspacek
Dec 10 2018 18:22

Fine. Just delete lines

user('knot-resolver', 'knot-resolver')
trust_anchors.file = 'root.keys'

and it will most likely work.

micah
@micah
Dec 10 2018 18:22
how do I properly format that here, so it is more readable?
Petr Špaček
@pspacek
Dec 10 2018 18:22
Use three ```
micah
@micah
Dec 10 2018 18:23
thanks
I dropped the trust_anchors.file line, and it does work... but will it automaintain that still?
Petr Špaček
@pspacek
Dec 10 2018 18:23
user() is handled by systemd.
In Debian, trust_anchors.file by default points to distribution package so you have to rely on Debian to provide correct package.
micah
@micah
Dec 10 2018 18:25
so that is compiled in?
Vladimír Čunát
@vcunat
Dec 10 2018 18:25
No, path to the file is compiled in.
Petr Špaček
@pspacek
Dec 10 2018 18:25
Path to file is compiled in, keys themselves are in separate package dns-root-data.
Vladimír Čunát
@vcunat
Dec 10 2018 18:25
You'll need to restart kresd when it changes, but so far the keys have only changed once in history.
Petr Špaček
@pspacek
Dec 10 2018 18:26
In any case, you should update your software otherwise the file will be maintained by attacker and not you :-D
micah
@micah
Dec 10 2018 18:26
yeah, that is the next step...
is it CVE-2018-1110, CVE-2018-10920, and CVE-2018-1000002?
Petr Špaček
@pspacek
Dec 10 2018 18:28
Possibly, I do not know from top of my head.
In any case 3.1 does not have known exploitable issues so you might want to just update to 3.1, or wait few days before 3.2 is released.
micah
@micah
Dec 10 2018 18:30
what is the right way to restart kresd when using systemd?
Petr Špaček
@pspacek
Dec 10 2018 18:32
It depends on how you configured it/how many instances you have. All the details are in man kresd.systemd, but in general single-instance systems should be fine with systemctl restart kresd@1
micah
@micah
Dec 10 2018 18:32
i just have one instance right now, so I'll go with the systemcl restart kresd@1
Petr Špaček
@pspacek
Dec 10 2018 18:36
I have to run, feel free to ask https://www.knot-resolver.cz/support/
micah
@micah
Dec 10 2018 18:56
thanks @pspacek !
micah
@micah
Dec 10 2018 19:16
I was expecting to see the 'ad' flag in response to dig pir.org +dnssec +multi -- but I don't see it, maybe my DNSSEC anchors are also broken in this package?
Tomas Krizek
@tomaskrizek
Dec 10 2018 19:25
A quick test if DNSSEC is turned on would be to query dig dnssec-failed.org, which should result in SERVFAIL, and then try with dig dnssec-failed.org +cd which should result with NOERROR.
micah
@micah
Dec 10 2018 19:25
ok, dig dnssec-failed.org is not failing
I'm getting NOERROR for that
i also get NOERROR for dig dnssec-failed.org +cd too
Tomas Krizek
@tomaskrizek
Dec 10 2018 19:28
Please use the official upstream packages from https://www.knot-resolver.cz/download/ . They are configured to do DNSSEC validation by default and you'll also get the latest updates there.
(Also, when running the commands mentioned above, make sure you're actually testing the intended resolver, e.g. dig @127.0.0.1 -p 53 dnssec-failed.org)
micah
@micah
Dec 10 2018 19:30
ah, that was the problem -- I did not specify @127.0.0.1
but yes, I'll update to the official upstream packages now, before I run into more bugs in older unsupported versions