All "Internal" zones (RFC 6303) disappear after upgrading from v15.2 to v15.3

[Rafpren]

Environment

• Technitium DNS Server version before upgrade: v15.2
• Technitium DNS Server version after upgrade: v15.3
• OS: Linux (LXC container)
• Deployment: Cluster, 2 nodes (dns-server / NS1 and rp-zdws0 / NS2)
• Upgrade method: official install script, run individually on each node:

  curl -sSL https://download.technitium.com/dns/install.sh | bash

  This is the standard in-place update path (detects existing install, updates ASP.NET Core Runtime + DNS Server binaries, restarts the systemd service). A config backup was exported via the web UI (Settings → Backup/Restore) before updating.

Summary

After upgrading a Technitium cluster node from v15.2 to v15.3, all zones of type Internal (the RFC 6303 built-in zones that Technitium auto-creates: 0.in-addr.arpa, 127.in-addr.arpa, 255.in-addr.arpa, the IPv6 loopback reverse zone, and localhost) are missing from the zone list. No manual deletion was performed.

Zones of type Primary and Catalog created by the user were preserved without any issue across the same upgrade — only the auto-generated Internal zone type was affected.

Zone list before upgrade (v15.2) — 9 zones

Zone	Type
0.168.192.in-addr.arpa	Primary
0.in-addr.arpa	Internal
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa	Internal
127.in-addr.arpa	Internal
255.in-addr.arpa	Internal
cluster-catalog.cluster.home.0n1.lab	Catalog
cluster.home.0n1.lab	Primary (DNSSEC)
home.0n1.lab	Primary
localhost	Internal

Zone list after upgrade (v15.3) — 5 zones

Zone	Type
0.0.0.0.5.2.e.1.b.3.c.b.9.5.d.f.ip6.arpa	Primary (unrelated, pre-existing user zone)
0.168.192.in-addr.arpa	Primary
cluster-catalog.cluster.home.0n1.lab	Catalog
cluster.home.0n1.lab	Primary (DNSSEC)
home.0n1.lab	Primary

All 5 Internal zones (0.in-addr.arpa, 127.in-addr.arpa, 255.in-addr.arpa, the ip6.arpa loopback reverse zone, localhost) are gone. All Primary/Catalog zones survived.

Steps to reproduce

1. Run Technitium v15.2 with the default built-in Internal zones present (fresh installs create these automatically).
2. Upgrade to v15.3 using the standard upgrade procedure.
3. Check the Zones list after the upgrade completes.

Expected behavior

The built-in Internal zones (RFC 6303) should still be present and enabled after the upgrade, exactly as they were on v15.2.

Actual behavior

All Internal zones are absent from the zone list post-upgrade. This means queries for localhost, loopback PTR (::1, 127.0.0.1), and the RFC 6303 special-use reverse zones are no longer answered locally and will instead be forwarded/resolved recursively (or leak to upstream forwarders), which is both a functional regression and a minor privacy/security concern.

Additional context

• No manual deletion was performed by any administrator on any node.
• Both cluster nodes were checked and show the exact same result: the secondary node (rp-zdws0 / NS2) is missing the same 5 Internal zones as the primary. This confirms the loss is cluster-wide, not a single-node desync.

before :

After :

Question for maintainers

Is there a known change in v15.3 that stops re-creating or migrating the built-in "Internal" zone type during an upgrade? Is a manual workaround needed (e.g. re-adding these zones manually), and if so, will they be correctly flagged as "Internal" type again or do they need to be created as regular Primary zones?

[Hemsby]

You didn't fancy reading the changelog then?

[Rafpren]

You're right, and I apologize for the noise, the change was documented in the CHANGELOG under v15.3 (RFC 6303 / RFC 6761 support via "Locally Served DNS Zones"). I should have checked there before opening this issue.
Confirmed on my end: Settings > Recursion > Locally Served DNS Zones is enabled by default, and resolution for localhost, loopback, etc. still works correctly. No actual regression, just an unfamiliarity with the new zone management model replacing the old visible Internal zone entries. Sorry again for the wasted time, and thanks for the quick pointer.
Closing this issue.

[bcookatpcsd]

To tag along onto this..

Could there be an:

Allow TXT Blocking Report
Specifies if the DNS Server should respond with TXT records containing a blocked domain report for TXT type requests. This option also enables Extended DNS Error blocked domain report in response for requests that support EDNS.

Response to show that this is happening.. Something about rfc 6761..

I have to admit to losing a few hours of life not understanding this change as well..

My 0.02

Thank you in advance either way

[Apachez-]

Similar to these options in Bind:

        empty-zones-enable yes;
#       disable-empty-zone "";

Also not physically visible on the storage unless you disable this and create the zones (for localhost and 127.in-addr.arpa etc) yourself.

[Hemsby]

To tag along onto this..

Could there be an:

Allow TXT Blocking Report Specifies if the DNS Server should respond with TXT records containing a blocked domain report for TXT type requests. This option also enables Extended DNS Error blocked domain report in response for requests that support EDNS.

Response to show that this is happening.. Something about rfc 6761..

I have to admit to losing a few hours of life not understanding this change as well..

My 0.02

Thank you in advance either way

You can already see if its happening or not. Just query a blocked domain.

With it Enabled:

dig blocktest.dns

; <<>> DiG 9.20.23-1~deb13u1-Debian <<>> blocktest.dns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17951
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; EDE: 15 (Blocked): (source=blocked-zone; domain=blocktest.dns)
;; QUESTION SECTION:
;blocktest.dns. IN A

;; ANSWER SECTION:
blocktest.dns. 30 IN A 10.0.0.4

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2) (UDP)
;; WHEN: Thu Jul 09 07:37:29 CEST 2026
;; MSG SIZE rcvd: 105

With it Disabled:

dig blocktest.dns

; <<>> DiG 9.20.23-1~deb13u1-Debian <<>> blocktest.dns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63111
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;blocktest.dns. IN A

;; ANSWER SECTION:
blocktest.dns. 30 IN A 10.0.0.4

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2) (UDP)
;; WHEN: Thu Jul 09 07:37:47 CEST 2026
;; MSG SIZE rcvd: 58

[ShreyasZare]

@Rafpren thanks for the post. Good to know that the issue is resolved now that you read the change log. This new implementation is now RFC compliant and covers all required zones.

@bcookatpcsd That looks interesting idea will think more on it.

[Apachez-]

I hope EDE remains by default disabled otherwise this will become another nightmare of DNS amplification attacks.

Looking through the settings in 15.3 - where is the enable/disable EDE actually located?

Edit: I assume its Settings -> Blocking: Blocking-Allow TXT Block Report ?

[ShreyasZare]

I hope EDE remains by default disabled otherwise this will become another nightmare of DNS amplification attacks.

Looking through the settings in 15.3 - where is the enable/disable EDE actually located?

Edit: I assume its Settings -> Blocking: Blocking-Allow TXT Block Report ?

Yes, its under Setting > Blocking section. Its not to big to cause issue with amplification attacks.

[Rafpren]

To tag along onto this..

Could there be an:

Allow TXT Blocking Report Specifies if the DNS Server should respond with TXT records containing a blocked domain report for TXT type requests. This option also enables Extended DNS Error blocked domain report in response for requests that support EDNS.

Response to show that this is happening.. Something about rfc 6761..

I have to admit to losing a few hours of life not understanding this change as well..

My 0.02

Thank you in advance either way+1, would've saved me the confusion in this thread. An EDE-style indicator for RFC 6303/6761 hits (similar to the blocking report) would make this new implementation much easier to reason about.

[Rafpren]

@Rafpren thanks for the post. Good to know that the issue is resolved now that you read the change log. This new implementation is now RFC compliant and covers all required zones.

That looks interesting idea will think more on it.

Thanks for confirming, and for the quick clarification on both points. Appreciate you taking the time despite this turning out to be a documented change I should have caught in the changelog first.
Technitium has been rock solid in my homelab for a long time now, thanks for all the work you put into it. Closing this issue.