I’m pulling my hair out over this. I’ve got a proxmox homelab, an LXC running technitium installed from TTeck’s script.
The DNS server is also doing DHCP for my network. I have an authoritative zone for ‘.lan’
I can get NS, SOA, TXT records from the DNS server, but no A records! The DNS query logs show that it gives an answer, and if I am on the DNS server itself I get an answer, but no other machines on the network hear the reply.
I think this means the DNS server is working properly. There are no FWs in the way as I can resolve other types.
Where else can I look, or how can I diagnose this? I am completely at a loss.
Here is how I would diagnose (I’m assuming you have Linux / WSL on a client)
- Check the DNS record is actually set (yes do it again)
- Do these steps on the client:
dig $domain
check which server answereddig a $domain
should give a recorddig a $domain @server
to make sure you’re querying the right server
If none work, probably network issue (DNS boind to wrong IP, firewall, etc)
If 3 and 5 work but 4 doesn’t, your DNS isn’t authorative.
If only 5 works DNS settings on the client is wrong.
Thanks for giving it some thought!
I have been testing using
dig @192.168.0.249 study.lan
3, 4, and 5 work for TXT, NS and SOA but doesn’t work for A records. I think this rules out a simple network issue?
How exactly are you testing this from your client, with ping? What are you using to query the DNS?
If you run nslookup from the client
- Does the ‘server’ command return the correct DNS server?
- Does <A-record>.lan return the expected record?
I’m assuming you’ve run ifconfig to verify your client’s NIC has been assigned the correct DNS via DHCP?
Thanks for replying, I appreciate the response.
I’m running
dig @192.168.0.249 study.lan
from my client (a MacBook).If I run ‘dig @192.168.0.249 study.lan TXT’ I get a correct response (I have added a txt record)
If I run ‘dig @192.168.0.249 lan SOA’ or ‘NS’ I correctly get the records for the zone.
I think this eliminates the possibility of it being a routing error?
Run Wireshark on the client to see if you actually got the reply.
Thanks for the suggestion, I’ll grab a cap to check.
I’m running
tcpdump -i any port 53
. I can see the outbound request but not the reply. Will the cap show me anything more?