15 Dub
2026
15 Dub
'26
12:08
Hi Bron,
Welcome aboard!
First of all, I have to say that the ALIAS record type (and similar alternatives) is
rather a workaround until
HTTPS/SVCB alias mode is widely supported. We added this type primarily for use with our
Redis backend
and we aren't philosophically ready to add processing of it to the server itself.
However, I believe we can find
a solution for your needs.
I think that your use case, where the target ALIAS zone is locally available, is not
common. Usually, a full DNS resolver
is necessary, which is the biggest issue. Our server is focused on high performance, so
performing the resolution
while responding to queries is not optimal. In your case it is not even necessary.
Possible options:
- Using our Redis backend in combination with
https://gitlab.nic.cz/knot/knot-dns/-/blob/master/scripts/redis_unalias.py
Sorry for the lack of documentation.
- If the dynamic records are uniform across the zones, cannot you use something like
(ignore the random zone names)?:
knotc> zone-begin --
OK
knotc> zone-set -- test A 192.168.1.1
OK
knotc> zone-diff --
[.] +test. 3600 A 192.168.1.1
[e92bd5f.4738fa5efafc1ebdc3.] +test.e92bd5f.4738fa5efafc1ebdc3. 3600 A 192.168.1.1
[63da60e39bb6cd76fa.] +test.63da60e39bb6cd76fa. 3600 A 192.168.1.1
[96e07.] +test.96e07. 3600 A 192.168.1.1
[aa.] +test.aa. 3600 A 192.168.1.1
[center.] +test.center. 3600 A 192.168.1.1
[collector.] +test.collector. 3600 A 192.168.1.1
[e6a69.] +test.e6a69. 3600 A 192.168.1.1
[ecbecfc1abcc.] +test.ecbecfc1abcc. 6536 A 192.168.1.1
[hawking.] +test.hawking. 16183 A 192.168.1.1
[noc3598.] +test.noc3598. 3600 A 192.168.1.1
[records.] +test.records. 3600 A 192.168.1.1
knotc> zone-commit --
OK
- If you insist on the dynamic ALIAS resolution, a new query module could be
implemented.
What do you think? Maybe more details about your deployment would help. Feel free to send
me relevant zone snippets.
Daniel
On 4/14/26 17:11, brong--- via knot-dns-users wrote:
Hi,
Fastmail has been running Knot for a few years now. Thank you for such excellent
software!
I'm new to this list, and new to the Knot codebase, but I'm an experienced C
developer and have been working on Cyrus IMAPd (a mostly C codebase) for many years.
We have hundreds of thousands of domains, and currently they all have the same set of
service IPs compiled into them. This has generally been fine - setting up a new server
takes an hour or so to build all the domains, but we just wait until it's done then
bring it into rotation.
Our current challenge -- we want to be able to transfer everything to a new IP range
quickly for datacenter failover. Rebuilding every zone is too expensive for this. I
looked at a few different issues and (along with Claude) figured that it wasn't much
work to extend the ALIAS type to follow the pointer to another zone inside the same server
and return the records from that. I have an initial pass at:
https://github.com/fastmail/knot-dns/tree/local-alias-synth
For now I've kept it as separate commits showing the evolution of the idea as
I've tested it more and thought through how I want it to interact (basically any ALIAS
get substituted with the contents of the name it points to, so you can mix and match them
all sorts of ways).
I'm very happy to engage on testing and modifying this code to match what the
upstream project wants; or revisit the approach if this doesn't match your vision. I
just need something that has these properties, and this seemed a good way to get there.
Thanks,
Bron.
--