High-performance authoritative DNS server. Please support the development https://donations.nic.cz/donate/?project=knot-dns
$
before ORIGIN
:-D
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
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.
This tries to suggest that each piece of data shall be restored to its "normal location" (individually).