Any way to create a "fake root" that replies the same record for *any* queried domain?

[teward]

We have a special use case where we need to have a 'fake root' zone. That is, for any query made to the DNS server, it needs to be able to return a designated static set of records for any requested domain.

This is easily doable in bind9 / named, but apparently not in Technitium DNS.

I've tried a zone that has the records I am looking for as A and NS records including with a wildcard to match 'anything' but it's not working. I've also tried using Split Horizon app to do the same without any success.

Is it even possible to make a 'catch all' responder in Technitium DNS?

[Hemsby]

Did you try adding a new primary zone with . as its name? Then create a * record with the value you want. I just did this quickly to test and it answers correctly for all Auth zones, and anything else I get the value I set in the * record.

[Hemsby]

[teward]

Yes, I have done this, but it doesn't seem to work.

Case in point, running dig @technitium-ip nope.net will return an 8.8.8.8 value in my test setup.

However, using the same query for google.com results in an NXDOMAIN. There doesn't seem to be any clear pattern to what is or is not actually resolving to this 'fake root'. And it's sporadic.

I would expect instead of NXDOMAIN that if the root zone has * as a record with a specific IP address, it would return that for everything instead of NXDOMAIN.

The main problem is I can't set it to work for anything.example.com given the volume and intention of this environment - the amount of domains and subdomains being caught here makes it non-feasible to add every record we want to catch. We literally want it to return the same record for any query regardless of what the requested domain is. We don't want to have to define every single TLD that it matches.

[Hemsby]

Not sure why its not working for you.

root@ns1:~# dig @10.0.7.1 google.com

; <<>> DiG 9.20.26-1~deb13u1-Debian <<>> @10.0.7.1 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8679
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 0 IN A 1.2.3.4

;; Query time: 2 msec
;; SERVER: 10.0.7.1#53(10.0.7.1) (UDP)
;; WHEN: Tue Sep 15 18:06:50 CEST 2026
;; MSG SIZE rcvd: 55

root@ns1:~# dig @10.0.7.1 amazon.com

; <<>> DiG 9.20.26-1~deb13u1-Debian <<>> @10.0.7.1 amazon.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23542
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;amazon.com. IN A

;; ANSWER SECTION:
amazon.com. 0 IN A 1.2.3.4

;; Query time: 1 msec
;; SERVER: 10.0.7.1#53(10.0.7.1) (UDP)
;; WHEN: Tue Sep 15 18:07:08 CEST 2026
;; MSG SIZE rcvd: 55

[teward]

So, there's some interesting behavior here that I noticed.

I only got this to work when I used the NS as . which points to the 'root zone' inside Technitium.

I discovered this as well during the deep dive of the same on a newer BIND9 to see if I could replicate this. Turns out, things got different with how zones and NS records are handled. Not sure why this changed in dig and such, but with any NS record other than the 'root' zone itself (or no NS entries which isn't compliant), it doesn't work.

Ultimately I had to do something like this:

This works but it's... a little tricky/annoying. This might be something I write up for the future...

[ShreyasZare]

Good to know that you have it working now. However, setting . as the NS record's name server domain name is not needed and its just a co-incidence that it worked. You can see the screenshot that @Hemsby shared with the NS record having the default name server domain and its working there without issues.

I will also recommend that you do these tests with the built-in DNS Client available on the admin panel. This helps debugging such issues much better than using dig in many cases.