CZ-NIC/knot-resolver

Knot Resolver: Resolve DNS names like it's 2022! https://www.knot-resolver.cz/support/

Vladimír Čunát

@vcunat

Knot-resolver can't filter based on client certificates. It can do so based on IP address (hard to spoof for TCP/TLS, I think).

Jörg Thalheim

@Mic92

@vcunat but should be easy to add, right? https://www.gnutls.org/manual/html_node/Client-Authentication.html

Vladimír Čunát

@vcunat

Yes, I expect so.

Vladimír Čunát

@vcunat

Related to this, Unbound has some *ratelimit* options (experimental?), which could limit at least some kinds of attacks.

Jörg Thalheim

@Mic92

or dnsdist

Vladimír Čunát

@vcunat

That's what Quad9 uses, reportedly.

Jörg Thalheim

@Mic92

@vcunat do you know, why knot decided to pin certificates instead of public keys? Public keys could remain stable, while certificates are updated

Vladimír Čunát

@vcunat

@Mic92: I perhaps don't understand. Knot-resolver supports both pinning and certificates.

(Or is this about knot-dns?)

Jörg Thalheim

@Mic92

@vcunat It does? Then I have not seen this.

Vladimír Čunát

@vcunat

e.g. { '2620:fe::fe', hostname = 'dns.quad9.net', ca_file = '/etc/ssl/certs/ca-bundle.crt' }

Jörg Thalheim

@Mic92

@vcunat right, this is about pinning the ca. There is also pin_sha256 - I assume this is the certificate pin. I tried to compute the sha256 of the public key. echo | openssl s_client -connect '9.9.9.9:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

Vladimír Čunát

@vcunat

I'm myself not sure how the pin should be computed, but it's some standard thing.

Note that Quad9 have not announced a SPKI pinset.

Base 64 encoded form of SPKI pin(s) for TLS authentication (RFC7858)

Jörg Thalheim

@Mic92

On the long run I want to have my own server, shared with some other folks. But it would be good to have a working example, people can use, in the nixos example section

I tried pinning 9.9.9.9 to the letsencrypt root ca, but apparently I am missing something.

just using https://letsencrypt.org/certs/isrgrootx1.pem.txt is not enough

Jörg Thalheim

@Mic92

But at least knowing that pin_sha256 follows a standard, is helpful

Vladimír Čunát

@vcunat

Well, I had tested the above config with the bundle.

They use root x3

Ah, not root x3.

Well, I'm no expert on TLS. This is what I get

$ openssl s_client -connect dns.quad9.net:853
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = dns.quad9.net
verify return:1

So you probably want https://www.identrust.com/certificates/trustid/root-download-x3.html

Vladimír Čunát

@vcunat

It's possible knot-resolver has some issue when there are multiple trust paths "to choose from". By default, dns.quad9.net chooses to send this one, because this root is commonly trusted by browsers, and using it works in kresd https://www.identrust.com/certificates/trustid/root-download-x3.html (with added -- BEG/END CERT -- lines).

Vladimír Čunát

@vcunat

Opened https://gitlab.labs.nic.cz/knot/knot-resolver/issues/309

to track this.

Vladimír Čunát

@vcunat

@Mic92 see https://gitlab.labs.nic.cz/knot/knot-resolver/issues/309#note_69753

jrun

@257

Feb 21 11:39:50 asusp7p55lx kresd[27678]: /usr/lib/kdns_modules/hints.so: undefined symbol: engine_hint_root_file

i see that there was a discussion about this on the gitter when building and running on fedora but not sure if it's related here.

dunno if it's related but there is something unusual about building knot-resolver; PREFIX passed in compile phase is not honnered in install phase.

Vladimír Čunát

@vcunat

You need to pass the same PREFIX to both phases.

It's just makefiles, it doesn't save settings somewhere :-)

jrun

@257

as a work around i'm passing PREFIX twice although that doesn't solve the prblem with LIBDIR which unlike ETCDIR and MODULEDIR is not put to gether in the initial Makefile.

Vladimír Čunát

@vcunat

Assuming you have exactly same kresd and libkres version, what version gives this problem?

(the missing symbol)

jrun

@257

2.1.0

vcunat: not sure about the libkres actually. is that from knot?

let me check

Vladimír Čunát

@vcunat

No, from knot-resolver itself.

jrun

@257

2.6.4

2.6.4 is the knot version, nvm.

Vladimír Čunát

@vcunat

But this is actually about hints.so and kresd. These problems should be gone on 2.1.0, if both are from this version.

jrun

@257

vcunat: they are from the same version. would building off the git help? i guess i have to anyway for any possible fix, i'm assuming it's a bug...

Vladimír Čunát

@vcunat

We had this exact bug in 1.5.2 and 2.0.0, but resolved it in 1.5.3 and 2.1.0 (couldn't reproduce it anymore).

What's your system? Do you pass any CFLAGS, LDFLAGS, etc?

jrun

@257

gentoo, wait for the ebuild post which should be easy to read (shell like) and i will be here to explain if there is any need for it.

i'm just rewritten to build off the tags on github.

Vladimír Čunát

@vcunat

OK, I think I can still read ebuilds.

You can test the presence of the symbol even without running, via

$ nm -D path/to/kresd | grep engine_hint_root_file
000000000000a980 T engine_hint_root_file

Where communities thrive

People

Repo info

Activity