summaryrefslogtreecommitdiffstats
path: root/test/knot-data (follow)
Commit message (Collapse)AuthorAgeFilesLines
* resolve: provide service resolve over varlinkVishal Chillara Srinivas2024-02-161-0/+1
| | | | | ported the d-bus implementation of service resolve to varlink extended TEST-75-RESOLVED to cover this use-case
* test: explicitly set nsec3-iterations to 0Frantisek Sumsal2024-01-301-0/+1
| | | | | | | | | | | | | | | | | | knot v3.2 and later does this by default. knot v3.1 still has the default set to 10, but it also introduced a warning that the default will be changed to 0 in later versions, so it effectively complains about its own default, which then fails the config check. Let's just set the value explicitly to zero to avoid that. ~# knotc --version knotc (Knot DNS), version 3.1.6 ~# grep nsec3-iterations test/knot-data/knot.conf || echo nope nope ~# knotc -c /build/test/knot-data/knot.conf conf-check warning: config, policy[auto_rollover_nsec3].nsec3-iterations defaults to 10, since version 3.2 the default becomes 0 Configuration is valid Follow-up to 0652cf8e7b.
* test: use the default nsec3-iterations valueFrantisek Sumsal2024-01-241-1/+0
| | | | | | In Knot 3.2 the nsec3-iterations default was changed to 0 and Knot now issues a warning if the value is > 0. Let's just use the default value, since it's not something that's important for our tests.
* Merge pull request #30661 from rpigott/resolved-https-recordLuca Boccassi2024-01-171-0/+3
|\ | | | | resolved: support RFC 9460 SVCB and HTTPS records
| * test-resolve: add basic test for SVCB/HTTPS RRsRonan Pigott2024-01-161-0/+3
| |
* | test: introduce a dummy DNS test serverFrantisek Sumsal2024-01-101-0/+17
| | | | | | | | | | | | | | | | | | | | Introduce a _very_ simple DNS server using our internal DNS-related code, that responds to queries with specifically crafted packets, to cover scenarios that are difficult to reproduce with well-behaving DNS servers. Also, hide the test DNS server behind Knot using the dnsproxy module, so we don't have to switch DNS servers during tests.
* | test: check how systemd-resolved deals with zone transfersFrantisek Sumsal2024-01-071-1/+7
| | | | | | | | | | | | | | Even though systemd-resolved doesn't support zone transfers (AXFR/IXFR), it should still just refuse such requests without choking on them. See: https://github.com/systemd/systemd/pull/30809#issuecomment-1880102804
* | test: merge config sectionsFrantisek Sumsal2024-01-071-10/+6
|/
* resolved: added serve stale feature implementation of RFC 8767Kiran Vemula2023-06-161-0/+1
| | | | | | | serve stale feature to keep the DNS resource records beyond TTL to return them as stale records in case of upstream server is not reachable or returns negative response. SD_RESOLVED_NO_STALE flag has been added to disable serving stale records via dbus. added serve stale test cases to TEST-75-RESOLVED Fixes: #21815
* test: add a test for the OPENPGPKEY RRFrantisek Sumsal2023-01-271-0/+14
|
* test: add a couple of SRV records to check service resolutionFrantisek Sumsal2023-01-272-0/+12
|
* test: cover IPv6 in the resolved test suiteFrantisek Sumsal2023-01-277-30/+54
|
* tree-wide: replace "plural(s)" by "plurals"Zbigniew Jędrzejewski-Szmek2022-10-171-1/+1
| | | | | | | | (s) is just ugly with a vibe of DOS. In most cases just using the normal plural form is more natural and gramatically correct. There are some log_debug() statements left, and texts in foreign licenses or headers. Those are not touched on purpose.
* Implement DNS notifications from resolved via varlinkSuraj Krishnan2022-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | * The new varlink interface exposes a method to subscribe to DNS resolutions on the system. The socket permissions are open for owner and group only. * Notifications are sent to subscriber(s), if any, after successful resolution of A and AAAA records. This feature could be used by applications for auditing/logging services downstream of the resolver. It could also be used to asynchronously update the firewall. For example, a system that has a tightly configured firewall could open up connections selectively to known good hosts based on a known allow-list of hostnames. Of course, updating the firewall asynchronously will require other design considerations (such as queueing packets in the user space while a verdict is made). See also: https://lists.freedesktop.org/archives/systemd-devel/2022-August/048202.html https://lists.freedesktop.org/archives/systemd-devel/2022-February/047441.html
* test: Introduce systemd-resolved test suiteFrantisek Sumsal2022-07-047-0/+253
Resolves: #19599
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 04:27:21 +0100