[GH-ISSUE #219] Run deckard test suite #100

New issue

Open

opened 2026-03-07 22:18:52 +03:00 by kerem · 3 comments

kerem commented

2026-03-07 22:18:52 +03:00

Owner

Originally created by @briansmith on GitHub (Oct 2, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/219

deckard is basically a set of scripted tests for DNS implementations, designed to be portable across implementations. If TRust-DNS implements an interpreter for the scripts, then it can reuse these tests. See these links for more info:

Originally created by @briansmith on GitHub (Oct 2, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/219 deckard is basically a set of scripted tests for DNS implementations, designed to be portable across implementations. If TRust-DNS implements an interpreter for the scripts, then it can reuse these tests. See these links for more info: * https://storify.com/KnotDNS/deckard-a-dns-software-test-harness * https://github.com/CZ-NIC/deckard * https://unbound.nlnetlabs.nl/pipermail/unbound-users/2017-March/004699.html * https://gitlab.labs.nic.cz/knot/deckard/blob/master/doc/scenario_guide.rst

kerem added the

trust

tools

labels

2026-03-07 22:18:52 +03:00

kerem commented

2026-03-07 22:18:52 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 2, 2017):

This would be great. The compatibility crate/library in TRust-DNS would be a great place to run that. There are already a couple test harnesses there, I've intended to beef it up over time.

@bluejekyll commented on GitHub (Oct 2, 2017): This would be great. The `compatibility` crate/library in TRust-DNS would be a great place to run that. There are already a couple test harnesses there, I've intended to beef it up over time.

kerem commented

2026-03-07 22:18:53 +03:00

Author

Owner

@balaziks commented on GitHub (Oct 9, 2020):

Hi,
one of Deckard's developers here, I stumbled over this issue by chance. :)

There is no need to write interpreter for those files (and I wouldn't recommend it because the RPL format is quite gory to parse). You could just write a config file to run Trust-DNS in Deckard (I can assist with that). Unless you want to write a Rust implementation of Deckard for the sake of it being written in Rust, which might be interesting as well…

Note that the test suite is very resolver-centric nowadays and there is not much development in regards to authoritative server scenarios. Also note that it's quite hard to write a resolver-agnostic scenario because different implementations take different routes through the DNS tree.

Anyways, I am open to help you with anything Deckard-related.

@balaziks commented on GitHub (Oct 9, 2020): Hi, one of Deckard's developers here, I stumbled over this issue by chance. :) There is no need to write interpreter for those files (and I wouldn't recommend it because the RPL format is quite gory to parse). You could just write a config file to run Trust-DNS in Deckard (I can assist with that). Unless you want to write a Rust implementation of Deckard for the sake of it being written in Rust, which might be interesting as well… Note that the test suite is very resolver-centric nowadays and there is not much development in regards to authoritative server scenarios. Also note that it's quite hard to write a resolver-agnostic scenario because different implementations take different routes through the DNS tree. Anyways, I am open to help you with anything Deckard-related.

kerem commented

2026-03-07 22:18:53 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 9, 2020):

@balaziks, Thanks for reaching out! We definitely might be interested.

We have a lot of test coverage in the libraries, but not a lot of tests to evaluate the software against standard DNS software. I'm not sure when I or someone else will have time for that, but your suggestion for an approach is very much appreciated.

@bluejekyll commented on GitHub (Oct 9, 2020): @balaziks, Thanks for reaching out! We definitely might be interested. We have a lot of test coverage in the libraries, but not a lot of tests to evaluate the software against standard DNS software. I'm not sure when I or someone else will have time for that, but your suggestion for an approach is very much appreciated.

kerem referenced this issue

2026-03-07 22:24:38 +03:00

[GH-ISSUE #278] Use mTLS for Client authz/n for dynamic update in Server #134

kerem referenced this issue

2026-03-15 22:05:00 +03:00

[GH-ISSUE #100] Fix mtls, client auth feature #348

kerem referenced this issue

2026-03-15 22:27:49 +03:00

[GH-ISSUE #278] Use mTLS for Client authz/n for dynamic update in Server #431