Technitium DNS Server NOT using local custom A NAMES

[moore8705]

Technitium DNS Server Version 13.6 is ignoring custom domain A NAMES pointing to like:

blah.mydomain.com

I have a zone of mydomain.com configured and then have added about a dozen subdomain A names pointing to specific local custom IP addresses but the client cannot resolve any of these subdomains (ping).

Is there a security setting like using a DNS-over-HTTPS forwarder that could interfere OR perhaps a PTR created reverse record setting I didn't include that is required?

I have Technitium configured as the only DNS server for a win11 client for my tests here. Technitium is not the DHCP server. Technitium is setup as a Proxmox LXC.

[ShreyasZare]

Thanks for the post. I would suggest that you test the domain name using the DNS Client tool on the admin panel to confirm if the domain name resolves. If its resolving there, test the resolution using nslookup command from one of the client instead of using ping command.Share the output from DNS Client and nslookup here.

[moore8705]

Thanks for the reply

nslookup via Win11 client

Server UnKnown

The DNS Client tab search for one of the subdomains like blah.mydomain.com

[ShreyasZare]

Thanks for the details. From the DNS Client output it looks like the domain is resolving well. It seems that the issue is due to win11 client configured with different dns server causing it to fail to resolve the domain.You can test with "nslookup blah.mydomain.com <dns-server-ip>" command from win11 client to test if the DNS server can be reached.

[moore8705]

DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.5.11

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

That's all network adapters disabled even on the Win11 client for testing and only a single DNS server entry for Technitium.

[moore8705]

The network router has working static DNS FQDN IP address entries for subdomains and would normally be the secondary DNS server. Technitium is intended to be the primary DNS server on the network (DHCP). I changed that for the test client after realizing the A NAMES are not working.

[moore8705]

Thank you for your time with that.

This seems like a real issue that is still ongoing. I will continue to test as you stated with the DNS Client Tools and nslookup but so far every subdomain I've tried to resolve has failed. I cleared the DNS cache on the client and server and tried again and still can't resolve any of my A NAME subdomains.

This being a Proxmox LXC after not immediately being able to resolve the issue I backed the Technitium DNS server settings, destroyed the container, made a new one and restored the settings to find this is still happening.

[moore8705]

So the zone type, if it matters, while creating my subdomains was Primary Zone (default). I experienced the issue again and so blew out the Technitium DNS server's LXC on Proxmox once again. The problem persists even starting from scratch NOT restoring my Technitium settings backup.

My Windows 11 test client is still not able to resolve A NAMES subdomains created in Technitium.

[ShreyasZare]

Thanks for the details. Since the subdomain names are resolving with DNS Client, the zone setup is correct.When you try with nslookup, you are seeing timeout issues which indicates that either the DNS request is not reaching the DNS server or that the response from the DNS server is getting routed to a different network than expected. This nslookup test does not depend on any DHCP config or DNS cache on the client.Do you have multiple network interfaces on the container? If yes then that might be the reason since responses get router out of the interface which has a default route. In such case, you need to configure the interface IP as the DNS Server Local End Point in Settings. 

[moore8705]

The Proxmox server has been made VLAN Aware but this LXC is not using it and had been seemingly working until I noticed it was no longer resolving custom A NAMES for subdomains and so I took it offline just by altering the DHCP server's DNS config to serve different DNS servers for the time being.

In addition to your suggested nslookup and DNS Client Tools I am using ping and verified I can ping the IP address of the Technitium DNS Server. The same ping to the FQDN fails with the Windows 11 test client I mentioned.

I think the first red flag for the error was a subdomain SSL URL failing in a web browser since it no longer was able to resolve the A NAME.

[moore8705]

Do you have multiple network interfaces on the container? If yes then that might be the reason since responses get router out of the interface which has a default route. In such case, you need to configure the interface IP as the DNS Server Local End Point in Settings.

The Proxmox LXC only has one network interface. A static IP address and gateway given via Proxmox. The container's DNS is defaulting to use host settings. Normally those would point to a secondary DNS on the router and two external DNS addresses. For testing I've changed it to only three external since the router's static DNS routes, mirroring the A NAME info from Technitium, could cause interference in my test.

[moore8705]

As a DNS server and forwarder itself I doubt Technitium DNS server would be configured to even use the Proxmox DNS servers. I would think it would ignore that and use its own Upsteam DNS forwarders. I had set that using HTTPS options but for the testing I've changed it to UDP. -- I am still using the only minimally configured new container of Technitium.

So it is using the default endpoints:
DNS Server Local End Points
0.0.0.0:53
[::]:53

[ShreyasZare]

Thanks for the details. Since you have only one network interface on the container and that the DNS Client tool is able to resolve the domain name. It looks like some network issue probably firewall causing timeout when you use nslookup to directly query the DNS server. The other config related to DHCP does not matter for nslookup test since nslookup directly queries to the DNS server IP address. Still, since you wish to use local domain names, its required that you configure only one DNS server IP address for all local clients via DHCP. Having a secondary DNS server IP address will cause issues resolving your local domain names.

[moore8705]

The A NAMES are normally a mix of local and real domains. A real one having a local IP address to resolve internally for instance. For the time being, I only have two A NAMES in my new test container of Technitium. Both A NAMES are real domains (meaning in local A NAMES and a external DNS provider) but the test client being using only has Technitium as the sole DNS server.

This is no longer deployed for the test but the original config was:
The secondary DHCP DNS config, albeit a router in this case, mirrors the DNS data from Technitium precisely and it did work and the router used a external secondary DNS itself.

[ShreyasZare]

There are too many parameters here in your config so its difficult to find out the issue. You will need to debug this step by step to find a solution. 

[moore8705]

I'm going to stop the Technitium container and test deploy a rival DNS server container via Proxmox LXC to sub in for Technitium. It was Technitium's to lose :)