storage: "/var/lib/knot" file: "/etc/knot/db.%s" zonefile-load: difference semantic-checks: on dnssec-signing: on dnssec-policy: default zonefile-sync: -1 serial-policy: increment journal-content: all journal-max-depth: 3
@lessless like any other record, just with a wildcard at the beginning, for example like this (be aware of the rules here: https://www.knot-dns.cz/docs/2.7/html/operation.html#reading-and-editing-zones):
knotc zone-begin example.com. knotc zone-set -- *.example.com. 3600 CNAME example.com. knotc zone-commit --
or where should the wildcard be?
; <<>> DiG 9.16.10 <<>> asd.test.example.dev ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2626 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;asd.test.rievo.dev. IN A ;; AUTHORITY SECTION: rievo.dev. 3600 IN SOA ns.example.ch. hostmaster.example.net. 2021010800 14400 3600 1209600 3600
This tries to suggest that each piece of data shall be restored to its "normal location" (individually).
If the Online backup was performed for all zones, it’s possible to restore the backed up data by simply copying them to their normal locations, since they’re simply copies. For example, the user can copy (overwrite) the backed up KASP database files to their configured location.