]> git.ipfire.org Git - thirdparty/unbound.git/commitdiff
For #1409: Changelog entry and more text.
authorW.C.A. Wijngaards <wouter@nlnetlabs.nl>
Fri, 27 Feb 2026 12:55:25 +0000 (13:55 +0100)
committerW.C.A. Wijngaards <wouter@nlnetlabs.nl>
Fri, 27 Feb 2026 12:55:25 +0000 (13:55 +0100)
doc/Changelog
doc/unbound.conf.rst

index cb7222c444acbca26747036ded259baeb2fef67a..4aac9feab025f3e1091bd3bfe224af0634dbecd3 100644 (file)
@@ -1,3 +1,6 @@
+27 February 2026: Wouter
+       - Merge #1409: Documentation CNAME in redirect-type local-zone.
+
 25 February 2026: Wouter
        - Fix validator to set unchecked when validation recursion
          requests are passed. The edns subnet module checks if validation
index eb79b47d2d2a66c469986b86eda9fc1be4180501..0d406f6890c666857286dc43771f971a3732e8e8 100644 (file)
@@ -2674,8 +2674,23 @@ These options are part of the ``server:`` section.
 
         In that case, the ``CNAME`` is resolved and the answer
         includes resolved target records as well.
+        The ``CNAME`` record has to be with the zone name of the local-zone,
+        and there can be one CNAME, not more.
+        The ``CNAME`` record has to be at the zone apex of the
+        ``redirect`` zone, then it is used for redirection.
+        The resolution proceeds with upstream DNS resolution, and
+        that does not include the lookup in local zones.
+        So the record is not able to point in local zones, but it
+        can point to upstream DNS answers.
+
         ``CNAME`` resolution is supported only in type ``redirect``
-        local-zone.
+        local-zone, and in type ``inform_redirect`` local-zone.
+
+        As different from ``CNAME`` records that are used elsewhere, in
+        the ``redirect`` type local-zone, it is supported that in the target
+        of the record a wildcard label gets expanded to the query name, with
+        for example: ``example.com. CNAME *.foo.net.`` gets expanded
+        to ``www.example.com. CNAME www.example.com.foo.net.``.
 
     @@UAHL@unbound.conf.local-zone.type@inform@@
         The query is answered normally, same as