mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-26 03:35:52 +03:00
[GH-ISSUE #209] [Server] DNSSEC doesn't want to work #95
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#95
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Darkspirit on GitHub (Sep 26, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/209
compiled with:
/home/trustdns/config.toml
/home/trustdns/ikenmeyer.com.zone
first run
second run
dnsviz scanned the zone in the second run and it isn't signed: http://dnsviz.net/d/ikenmeyer.com/e/178688396/dnssec/
This order seems wrong to me:
Regarding
@bluejekyll commented on GitHub (Sep 26, 2017):
EDIT: I misread those logs. The output from the reload of the journal file is just mentioning the that the SOA doesn't exist up until that is read from the journal, then it goes away.
We might want to add a flag to force load from the zone file, as that only happens on first load. That WARN about the key is suspicious... There might be an issue here with some of the options you're passing. Could you try tls with openssl for now and see if that works? (I think this would just mean running with default features). What I don't see is a message that the zone is being resigned, so we need to figure out why that isn't happening.
I don't think I have any tests right now that guarantee the Server works with ring enabled...
(btw, I'm still not quite at a point where I would recommend running the Server as a publicly available authority).
@bluejekyll commented on GitHub (Sep 26, 2017):
Also, I see you want to use TLS, This needs to be enabled with this config line:
see this for reference: https://github.com/bluejekyll/trust-dns/blob/master/server/tests/named_test_configs/dns_over_tls.toml
This might be a big ask, but I haven't had a lot of people reach out on issues with this. If you wouldn't mind capturing your setup, we could start some documentation on how to run the Server.
@Darkspirit commented on GitHub (Sep 26, 2017):
first and second run would look the same as above
Yes, it's my intention to help with alpha testing:
compiled without mentioning features
renamed this build to named-default and uploaded it to my server. (reason)
deleted old journal and key:
first run
second run
http://dnsviz.net/d/ikenmeyer.com/e/178688972/dnssec/
ring is relevant and cool, openssl not ;D
It's an unused domain with an IPv6-only trustdns server inside my LXC rust playground container where I want to run my hyper project in the near future. My registrar currently does not support IPv6-only glue records, so I have to wait for it. I don't want to pay for two addtional legacy IP addresses. This is why I currently have to type " @dev.h.terrax.net" (=trustdns) at the end of my dig commands.
I set DNS over TLS as build feature, but did not configure it yet. This can wait until everything else works and should ideally rely on rustls. I would never run a domain without dnssec again. Didn't look into it yet. Definitely want it! Thanks for the quote.
First a basic setup with dnssec, then I would try to find problems and open issues. I'm quite a rust newbie, so I am frightened to make a patch (for CAA, TLSA) possibly containing bugs.
As this is the most relevant rust dns server/client project, I am very interested in helping to make some tutorials. Storing everything in mysql like powerdns with a nice API would be great in the future.
(rust: mysql_async or rust-mysql-simple)
@bluejekyll commented on GitHub (Sep 26, 2017):
Awesome! Thank you!
Ok, I think this is our issue, as you already pointed out:
My guess is that there's an ordering problem in this scenario where the Journal is being loaded, I'm trying to resign, and then the key is being read. Give me a little bit, and I can track down why that's happening.
It most definitely is! I just haven't been spending as much time on the Server as I have on the client and resolver lately, so you're probably going to find some inconsistencies. This is why I was hoping that OpenSSL would just work.
One thing that won't work with ring right now is key generation. So If that's being used, OpenSSL at least needs to be enabled for that. There are a bunch of code paths that need to be validated for that.
Cool.
@bluejekyll commented on GitHub (Sep 26, 2017):
So the journal is recovered here:
https://github.com/bluejekyll/trust-dns/blob/master/server/src/named.rs#L127
here's the attempted zone signing:
https://github.com/bluejekyll/trust-dns/blob/master/server/src/authority/authority.rs#L139
then the key is associated here:
https://github.com/bluejekyll/trust-dns/blob/master/server/src/named.rs#L223
After 223, we should actually try to resign the zone, that logic could go here:
https://github.com/bluejekyll/trust-dns/blob/master/server/src/authority/authority.rs#L106.
I clearly don't have a good test case for this case. This might be the best place for a call to Authority::secure_zone(), here:
https://github.com/bluejekyll/trust-dns/blob/master/server/src/named.rs#L229
and that would resolve all of this. We should also cleanup the signing at the end of a Journal load. For now, the work around (lame I know) would be to do a dynamic update, which is currently the only thing that appears to trigger the zone signing here:
https://github.com/bluejekyll/trust-dns/blob/master/server/src/authority/authority.rs#L809
And that is definitely tested...
Sorry for this! It's a major gap in the testing that I didn't notice! I'll work on a patch tonight.
@bluejekyll commented on GitHub (Sep 27, 2017):
@TerraX-net please let me know if this fixes your issue. I've opened another issue for creating an integration test for this particular case.
@Darkspirit commented on GitHub (Sep 27, 2017):
Overview
It seems that only RSASHA256 is working now (or I do something wrong).
I am primarily interested in ECDSA P384 and EdDSA.
Compiled on my Debian Testing desktop (rust stable) and running inside a Debian Testing LXC container (rust stable).
only CSK (RSA/EC=pem or ED=pk8) tested.
jrnl + pem/pk8 deleted for each table cell.
*)
2017-09-27T17:32:46.152411591+00:00 ERROR named:507 could not load zone ikenmeyer.com.: failed to load key: "ikenmeyer.com.zone.csk.pem" msg: could not generate key: unsupported Algorithm, enable openssl or ring feature: ED25519
**)
openssl genpkey -algorithm X25519 | openssl pkcs8 -nocrypt -outform der > ikenmeyer.com.zone.csk.pk8
# maybe this openssl command was just wrong to manually create a X25519 keypair as pk8.
2017-09-27T17:41:17.662520044+00:00 ERROR named:507 could not load zone ikenmeyer.com.: failed to load key: "ikenmeyer.com.zone.csk.pk8" msg: could not decode key: unsupported key format with ED25519 (only Pkcs8 supported): Pkcs8
***)
Although dnsviz does not support ed25519 it can display it partially: ed25519.nl
My first tests:
compiled with:
then uploaded it to my server (reason).
first run
second run:
second build (without "features"):
renamed it to named-default and uploaded it. removed .pem and .jrnl
first run:
second run:
rm *.pem && rm *.jrnl
changed algorithm from ECDSAP384SHA384 to RSASHA256
first run:
removed pem, jrnl
changed RSASHA256 to RSASHA512
used the first build (features=tls,ring)